From shemant@cisco.com Tue May 1 04:30:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBA021F878B for ; Tue, 1 May 2012 04:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DssRAS6bnIQb for ; Tue, 1 May 2012 04:30:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BAC6921F877C for ; Tue, 1 May 2012 04:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2670; q=dns/txt; s=iport; t=1335871835; x=1337081435; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=pJW1UmAi/elplBjJjad++pjFbjQ23Xrx9sePiAIG0QM=; b=cPolal/sNRhshHwanKatk5WRM8uBFTkA6EdUxesNwTO7FZbdhYyLgQRR XZqZx/S4crb8i6UXO0NL5WKSKyJpiINpiaaI7bivPOpRs3Cgba90/QDlj zocIhY/xvYq8UbmWFjkODatTY23CR9IyTNcOYy91ZCQzTEgc5T/xDBIwq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscFAOrIn0+tJV2d/2dsb2JhbABEhWmpfoFygQ+BB4IJAQEBBAEBAQ8BEA0EOgsMBAIBCBEEAQEBAgIGBhcBAgICAQEfBh8JCAEBBAESCBqHXQMLC5oVjROIcQ2JTwSBL4hYhWo1YwSIZJhZgxqBaYMG X-IronPort-AV: E=Sophos;i="4.75,509,1330905600"; d="scan'208";a="79317858" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 01 May 2012 11:30:35 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q41BUZOY031967; Tue, 1 May 2012 11:30:35 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 06:30:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 1 May 2012 06:30:33 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3048C3B13@XMB-RCD-109.cisco.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A7F88@GAALPA1MSGUSR9N.ITServices.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] (S)NTP in 6204bis Thread-Index: Ac0myZUhauwjtOVfSFuWu+r+34uEagAA7AzgAAmr4IAAB6el4AAese2Q References: <2D09D61DDFA73D4C884805CC7865E6110A7F1D@GAALPA1MSGUSR9N.ITServices.sbc.com><5B6B2B64C9FE2A489045EEEADDAFF2C3048C36F0@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7F88@GAALPA1MSGUSR9N.ITServices.sbc.com> From: "Hemant Singh (shemant)" To: "STARK, BARBARA H" , "Hans Liu" X-OriginalArrivalTime: 01 May 2012 11:30:34.0959 (UTC) FILETIME=[D3203DF0:01CD278D] Cc: v6ops@ietf.org Subject: Re: [v6ops] (S)NTP in 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2012 11:30:36 -0000 VGhhbmtzLCBIYW5zLiAgSSBhbSBzb2xkLiAgUmZjNjIwNGJpcyBzaG91bGQgY2hhbmdlIGZyb20g UkZDIDQwNzUgdG8gUkZDIDU5MDggYmVjYXVzZSBSRkMgNTkwOCB1c2VzIGEgRlFETiBmb3IgdGhl IE5UUCBzZXJ2ZXIuICBJRVRGIHJlY29tbWVuZHMgdXNlIG9mIEZRRE4gaW5zdGVhZCBvZiBhbiBJ UHY2IGFkZHJlc3MgaW4gbWFueSBvdGhlciBwcm90b2NvbHMuICBUaGUgbmV4dCByZXZpc2lvbiBv ZiByZmM2MjA0YmlzIHdpbGwgbWFrZSB0aGUgY2hhbmdlLiANCg0KSGVtYW50DQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTVEFSSywgQkFSQkFSQSBIIFttYWlsdG86YnM3NjUy QGF0dC5jb21dIA0KU2VudDogTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiA5OjMwIEFNDQpUbzogSGFu cyBMaXU7IEhlbWFudCBTaW5naCAoc2hlbWFudCkNCkNjOiB2Nm9wc0BpZXRmLm9yZw0KU3ViamVj dDogUkU6IFt2Nm9wc10gKFMpTlRQIGluIDYyMDRiaXMNCg0KWWVzLCB0aGFua3MuIDU5MDguDQpC YXJiYXJhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGFucyBMaXUg W21haWx0bzpoYW5zbGl1QGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAzMCwgMjAx MiA5OjA5IEFNDQo+IFRvOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpDQo+IENjOiBTVEFSSywgQkFS QkFSQSBIOyB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSAoUylOVFAgaW4g NjIwNGJpcw0KPiANCj4gUkZDIDU5MDggIT8gIDopDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IEhh bnMNCj4gDQo+IE9uIE1vbiwgQXByIDMwLCAyMDEyIGF0IDg6MzMgUE0sIEhlbWFudCBTaW5naCAo c2hlbWFudCkNCj4gPHNoZW1hbnRAY2lzY28uY29tPiB3cm90ZToNCj4gPiBCYXJiYXJhLA0KPiA+ DQo+ID4gU2VjdGlvbiA3IG9mIFJGQyA1MDk4IGlzIHRoZSBBY2tub3dsZWRnZW1lbnRzIHNlY3Rp b24uIMKgSXMgUkZDIDUwOTgNCj4gPiB0aGUgY29ycmVjdCBSRkM/DQo+ID4NCj4gPiBUaGFua3Ms DQo+ID4NCj4gPiBIZW1hbnQNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogdjZvcHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZg0KPiA+IE9mIFNUQVJLLCBCQVJCQVJBIEgNCj4gPiBTZW50OiBNb25k YXksIEFwcmlsIDMwLCAyMDEyIDg6MDYgQU0NCj4gPiBUbzogdjZvcHNAaWV0Zi5vcmcNCj4gPiBT dWJqZWN0OiBbdjZvcHNdIChTKU5UUCBpbiA2MjA0YmlzDQo+ID4NCj4gPiBBIGNvbGxlYWd1ZSBv ZiBtaW5lIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQgNjIwNCBhbmQgNjIwNGJpcyByZWZlcmVuY2UN Cj4gPiBSRkMgNDA3NSBmb3IgdGhlIERIQ1B2NiBTTlRQIHNlcnZlciBvcHRpb24sIGFuZCB0aGF0 IFJGQyA1MDk4IGNsYWltcw0KPiA+IGluIHRoZSBib2R5IG9mIGl0cyB0ZXh0IChzZWN0aW9uIDcp IHRvIGRlcHJlY2F0ZSA0MDc1LiBTaG91bGQgd2UgYmUNCj4gPiByZWNvbW1lbmRpbmcgdXNlIG9m IDQwNzUgb3IgNTA5OCBpbiA2MjA0KGJpcyk/DQo+ID4gQmFyYmFyYQ0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBs aXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiB2Nm9wc0BpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gDQo+IA0K PiANCj4gLS0NCj4gSW5zdGVhZCBvZiBmb2xsb3dpbmcgdGhlIGZhc2hpb24sIHdlIGxlYWQgaXQg dGhyb3VnaC4NCg== From mark@townsley.net Wed May 2 23:17:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0595A21F85AF for ; Wed, 2 May 2012 23:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=-0.421, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsHXyntmbt3f for ; Wed, 2 May 2012 23:17:58 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B56C221F85AE for ; Wed, 2 May 2012 23:17:57 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so941406wgb.13 for ; Wed, 02 May 2012 23:17:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=4WdQFalRv6cJps9jDmuNoakQRGBVY3IHoAeMoLprp1w=; b=pbpyseYFVkTVSOC54KZNM+a9NU1D3vjK5dSujhSDSwt2qGmAaibK04yaG56DmeA5TM UMqhodDrCv+3DyWjqUVHwEBSTU+1AtOUK1/R07nlOXYVCtE3hKkG0p2ubJ4p0I+Y0rL5 8EX/qsjeeM+jymohnHTLHgHq8LFRHLwBpDuoUDTkojwSNg8cvBBduGke2lCwlr8KNpQ4 hMLD/QRYXnfms/xFV7rGIKdozcIshKSZpJsyfzVkeeZJWNIeX0645OCOE7OCn3ZqvKMN jwViWxc96b0bPr6eDTsC+wzKX1HowS7WGDAkY0BF3yo+wvj6rMGWoUoIefvyjpr9DHTx Z3Fg== Received: by 10.180.107.104 with SMTP id hb8mr43364wib.8.1336025876870; Wed, 02 May 2012 23:17:56 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id h8sm193449wix.4.2012.05.02.23.17.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 23:17:56 -0700 (PDT) From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_F1B91460-D7F0-4A3E-8A73-5C9783CB503C" Date: Thu, 3 May 2012 08:17:51 +0200 In-Reply-To: To: IPv6 Operations References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com > <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> Message-Id: <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmUVlaqXeBTM9XudvvOZOTwVbwMk2Y4vUiIFM+8+dHt0EaucXqZ6u4CKNukJJJXIsBwdtIh Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 06:17:59 -0000 --Apple-Mail=_F1B91460-D7F0-4A3E-8A73-5C9783CB503C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks everyone for the comments.=20 After some additional word-smithing offline between Chris, Hemant, Wes, = and I, the four of us are _finally_ in agreement on the following text. = I think we'd all like to put this one to rest now, and at least as far = as the four of us are concerned, we can if this is what goes into the = next rev of the document.=20 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to be = active alone as well as simultaneously in order to support coexistence = of the two technologies during an incremental migration period from 6rd = to native IPv6.=20 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [Section 4.3 [RFC3704]]. 6RD-6: The CE router MUST allow different as well as identical delegated = prefixes to be configured via each (6rd or native) WAN interface. =20 6RD-7: In the event that forwarding rules produce a tie between 6rd and = native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. Thank you, - Mark On May 1, 2012, at 12:27 AM, Hans Liu wrote: > It looks like a lot of discussions were going on last week during my = absence. > I'm good with the idea in general while I believe Mark and Chris are > working on the text. > If a operator chooses to provision both 6rd and native IPv6, a CE > router needs to have the capability to support them simultaneously. In > terms, CPE has the capability while operators have the privilege > whether they would like to do that in their networks. And I will > implement the requirements in boxes of my company. >=20 > Cheers, > Hans >=20 > and I will have it implemented in products of my company. >=20 > On Tue, May 1, 2012 at 5:28 AM, Mark Townsley = wrote: >>=20 >> On Apr 27, 2012, at 6:37 PM, STARK, BARBARA H wrote: >>=20 >>>>>> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN >>>>>> interfaces to be active simultaneously in order to support >>>>>> coexistence of the two technologies during an incremental = migration >>>>>> period from 6rd to native IPv6 or vice versa. >>>>> I can't really see anyone who has a native IPv6 network migrate to >>>>> 6rd, but that might be a limit of my imagination :-) >>>>=20 >>>> didn't you know that corner cases allow us to complicate things, = which makes >>>> us more famous and gets more brownie points? >>>=20 >>> It's been suggested that a provider might find themselves needing to = back out of a migration from 6rd to native IPv6, if the native = deployment starts running into problems. In effect, this would look like = a migration from native IPv6 (back) to 6rd. >>=20 >> The nifty thing is that by making the 6rd and native interfaces = operate independently as we do here, you could do this in reverse and it = would "just work". The CPE operates as a slave to whatever the ISP wants = to send configuration for, in whatever timeline and order it likes. >>=20 >> - Mark >>=20 >>> Barbara >>> _______________________________________________ >>> 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 > --=20 > Instead of following the fashion, we lead it through. --Apple-Mail=_F1B91460-D7F0-4A3E-8A73-5C9783CB503C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 6RD-4:  A CE = router MUST allow 6rd and native IPv6 WAN interfaces to be active alone = as well as simultaneously in order to support coexistence of the two = technologies during an incremental migration period from 6rd to = native IPv6. 

6RD-5:  Each packet sent on a 6rd or = native WAN interface MUST be directed such that its source IP address is = derived from the delegated prefix associated with the upstream network = the WAN interface is connected to [Section 4.3 = [RFC3704]].

6RD-6: The CE router MUST allow different as well as = identical delegated prefixes to be configured via each (6rd or native) = WAN interface.  

6RD-7:  In the event that forwarding = rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE = Router MUST prefer native IPv6.

Thank = you,

- = Mark


On May 1, 2012, at 12:27 AM, = Hans Liu wrote:

It looks like a lot of discussions were going on last = week during my absence.
I'm good with the idea in general while I = believe Mark and Chris are
working on the text.
If a operator = chooses to provision both 6rd and native IPv6, a CE
router needs to = have the capability to support them simultaneously. In
terms, CPE has = the capability while operators have the privilege
whether they would = like to do that in their networks. And I will
implement the = requirements in boxes of my company.

Cheers,
Hans

and I = will have it implemented in products of my company.

On Tue, May = 1, 2012 at 5:28 AM, Mark Townsley <mark@townsley.net> = wrote:

On Apr 27, 2012, at 6:37 PM, STARK, BARBARA H = wrote:

6RD-4: A CE router MUST allow = 6rd virtual and IPv6 native = WAN
interfaces to be active simultaneously in order to = support
coexistence of the two technologies during an incremental = migration
period = from 6rd to native IPv6 or vice = versa.
I can't really see anyone who = has a native IPv6 network migrate = to
6rd, but that might be a limit = of my imagination = :-)

didn't = you know that corner cases allow us to complicate things, which = makes
us = more famous and gets more brownie = points?

It's been suggested that a = provider might find themselves needing to back out of a migration from = 6rd to native IPv6, if the native deployment starts running into = problems. In effect, this would look like a migration from native IPv6 = (back) to 6rd.

The nifty thing = is that by making the 6rd and native interfaces operate independently as = we do here, you could do this in reverse and it would "just work". The = CPE operates as a slave to whatever the ISP wants to send configuration = for, in whatever timeline and order it = likes.

- = Mark

Barbara
_______________________________________________
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



--
Instead of = following the fashion, we lead it = through.

= --Apple-Mail=_F1B91460-D7F0-4A3E-8A73-5C9783CB503C-- From gert@space.net Wed May 2 23:50:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9CE21F85AD for ; Wed, 2 May 2012 23:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYye7zI33ag6 for ; Wed, 2 May 2012 23:50:48 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C42B21F85A2 for ; Wed, 2 May 2012 23:50:47 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 37F34F8AD2 for ; Thu, 3 May 2012 08:50:46 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2E70CF8AB0 for ; Thu, 3 May 2012 08:50:46 +0200 (CEST) Received: (qmail 17630 invoked by uid 1007); 3 May 2012 08:50:46 +0200 Date: Thu, 3 May 2012 08:50:46 +0200 From: Gert Doering To: Mark Townsley Message-ID: <20120503065046.GJ84425@Space.Net> References: <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 06:50:49 -0000 Hi, On Thu, May 03, 2012 at 08:17:51AM +0200, Mark Townsley wrote: > Thanks everyone for the comments. > > After some additional word-smithing offline between Chris, Hemant, Wes, and I, the four of us are _finally_ in agreement on the following text. I think we'd all like to put this one to rest now, and at least as far as the four of us are concerned, we can if this is what goes into the next rev of the document. > > 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6. ACK. > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the upstream network the WAN interface is connected to [Section 4.3 [RFC3704]]. I still disagree with the wording "the WAN interface is connected to" - in the first half of the sentence, you have "the 6rd" and "the WAN" interface, while the second half only talks about "the WAN". So which addresses is the 6rd interface to forward? Why is the 6rd interface tied to "the upstream network the WAN interface is connected to"? My suggestion: "... the delegated prefix associated with this particular interface [Section 4.3 [RFC3704]]". shorter, not tied to "WAN", and the reference to "upstream network" is not needed anyway. > 6RD-6: The CE router MUST allow different as well as identical delegated prefixes to be configured via each (6rd or native) WAN interface. > > 6RD-7: In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. ACK. 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 ichiroumakino@gmail.com Thu May 3 00:15:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105E521F8601 for ; Thu, 3 May 2012 00:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_00=-2.599, MANGLED_MARKET=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi9Q-4AkL2PG for ; Thu, 3 May 2012 00:15:18 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFD921F8600 for ; Thu, 3 May 2012 00:15:18 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so40437wib.13 for ; Thu, 03 May 2012 00:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=g7LshgHRWdicCY2qdXKvNg4OF+bEwEWyO4qCz8+7rkM=; b=riTIUSVjQgqkTaP0GhgjHeBcsNTrAGzKxXsM8jFcZZkQvo9k/9e16nYuZwUkF/gZ3/ j7uefLddaStS0dAD//IP0uNPwHLiDkvtObLi4icvkeYi3/ALuUfU+Vk+hwJr0tODlpPc hoEzuhbIjW7s7qDEqmL+giTrl6OLXXrMdU/UJpOg2tqXNr8MRCgXnRR2Y1W/6X6tyCQx FwcKJuQE+SXkBWgGnVjqiU7HkjznfgOfGVegvIKFuoQeezjwcTmpvLervnS7uWyZHKIN caI7Cv5AKaCPEEAn5+H+9WxH6lIgVtzP0YZvF++5wr4Xq476TZWZbLvJ+mv+cJPrmOuq xCSg== Received: by 10.180.90.102 with SMTP id bv6mr452635wib.6.1336029317459; Thu, 03 May 2012 00:15:17 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-95.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fl2sm716080wib.2.2012.05.03.00.15.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 00:15:16 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> Date: Thu, 3 May 2012 09:15:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com > <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 07:15:19 -0000 Mark, et, al, [...] > 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to = be active alone as well as simultaneously in order to support = coexistence of the two technologies during an incremental migration = period from 6rd to native IPv6.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [Section 4.3 [RFC3704]]. >=20 > 6RD-6: The CE router MUST allow different as well as identical = delegated prefixes to be configured via each (6rd or native) WAN = interface. =20 >=20 > 6RD-7: In the event that forwarding rules produce a tie between 6rd = and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. I have a few nitpicks with the language above. e.g. the use of = "derived". I'll send those privately. generally I'm OK with the above. I think adding these paragraphs in the section introduction, would set = the context for these requirements better: =20 A multihomed, multiprefix, IPv6 CE router has multiple WAN interfaces connecting it to one or more Service Providers. The interfaces may be "real" or "virtual" in the case of tunneling technology such as 6rd [RFC5969]. The CE router receives one or more delegated prefixes, each associated with one or more WAN interfaces. WAN interfaces are used to send Ingress traffic from the Internet to the End-User, and Egress traffic from the End-User network to the Internet. Ingress traffic may be received on any active interface at any time. Egress traffic follows a set of rules within the CE in order to choose the proper WAN interface. This is important not only in order to choose the best path, but also because the networks that the CE are connected to typically employ source address verification mechanisms. Packets arriving at the CE have an IPv6 source address chosen by the host [RFC3484]. The CE router performs source address dependent = routing (SAD), such that the egress WAN interface is chosen based on the packet's = source address matching the delegated prefix associate with the egress WAN interface. cheers, Ole From gert@space.net Thu May 3 00:19:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EC121F8625 for ; Thu, 3 May 2012 00:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liK0RBFoHg7v for ; Thu, 3 May 2012 00:19:57 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 56C1921F8627 for ; Thu, 3 May 2012 00:19:57 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7D6C9F8AD6 for ; Thu, 3 May 2012 09:19:56 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 72D64F8AD2 for ; Thu, 3 May 2012 09:19:56 +0200 (CEST) Received: (qmail 25425 invoked by uid 1007); 3 May 2012 09:19:56 +0200 Date: Thu, 3 May 2012 09:19:56 +0200 From: Gert Doering To: Ole =?iso-8859-1?Q?Tr=F8an?= Message-ID: <20120503071956.GN84425@Space.Net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 07:19:58 -0000 Hi, On Thu, May 03, 2012 at 09:15:14AM +0200, Ole Trĝan wrote: > I think adding these paragraphs in the section introduction, would set the context for these > requirements better: > > A multihomed, multiprefix, IPv6 CE router has multiple WAN interfaces > connecting it to one or more Service Providers. The interfaces may > be "real" or "virtual" in the case of tunneling technology such as > 6rd [RFC5969]. The CE router receives one or more delegated > prefixes, each associated with one or more WAN interfaces. > > WAN interfaces are used to send Ingress traffic from the Internet to > the End-User, and Egress traffic from the End-User network to the > Internet. Ingress traffic may be received on any active interface at > any time. Egress traffic follows a set of rules within the CE in > order to choose the proper WAN interface. This is important not only > in order to choose the best path, but also because the networks that > the CE are connected to typically employ source address verification > mechanisms. > > Packets arriving at the CE have an IPv6 source address chosen by the > host [RFC3484]. The CE router performs source address dependent routing (SAD), > such that the egress WAN interface is chosen based on the packet's source > address matching the delegated prefix associate with the egress WAN > interface. +1 :-) (Given that the first paragraph considers all "outside" interfaces to be "WAN interfaces", and doesn't differenciate between "the 6rd" and "the WAN" interface, generic usage of "WAN interface" in the following text is perfectly fine with me). 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 mark@townsley.net Thu May 3 00:41:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1330F21F85A3 for ; Thu, 3 May 2012 00:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArKPE9F14sMx for ; Thu, 3 May 2012 00:41:23 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1B321F8564 for ; Thu, 3 May 2012 00:41:23 -0700 (PDT) Received: by werb10 with SMTP id b10so1147848wer.31 for ; Thu, 03 May 2012 00:41:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8sIvD91VbtUM6UrlJvqhkssWx2LuITN1OEmwZ1jadCA=; b=iDzpkiKIHxzVahUsUJgzUwhIE/Sm9RLCj58D4HDaSMskOun8yVOojX9aFrFxbLtQiG QYW76396GsGNou6q4sjk3dIdL0JLIZylewbauRB4YLNfDtJD9Ntze4IuT1pNYv8rxcCK U+McbxlMXffuY2VE7am09Yqq0LXoQuz46TgeNWWYjDtdfwDefeUcEEUFv9beuuInQLu8 QKurD3cJCq47ZKDto8OORp0dy3aH4qedTH4gGbAI9BPMuBg4GKr6XCgcYWVFIol57+cX I8f4zir3GB+jMR6l1rwcy3UP3+PZ7CB5jW7RI3DdcKMucSqW5dJeEqwWL6ArAVqzR4Ns 7HvA== Received: by 10.216.29.197 with SMTP id i47mr750478wea.45.1336030882035; Thu, 03 May 2012 00:41:22 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n20sm898178wiw.5.2012.05.03.00.41.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 00:41:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <20120503071956.GN84425@Space.Net> Date: Thu, 3 May 2012 09:41:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AD77422-D4D4-4A37-B37F-E55C4166860D@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> <20120503071956.GN84425@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl1OjLCaqqPtxTukr/h3il61xHtaPYBrrBkIiCN0BMQziOEZbusvoNaO6ylDRtuVV3KNf1D Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 07:41:24 -0000 On May 3, 2012, at 9:19 AM, Gert Doering wrote: > Hi, >=20 > On Thu, May 03, 2012 at 09:15:14AM +0200, Ole Tr=F8an wrote: >> I think adding these paragraphs in the section introduction, would = set the context for these >> requirements better: >>=20 >> A multihomed, multiprefix, IPv6 CE router has multiple WAN = interfaces >> connecting it to one or more Service Providers. The interfaces may >> be "real" or "virtual" in the case of tunneling technology such as >> 6rd [RFC5969]. The CE router receives one or more delegated >> prefixes, each associated with one or more WAN interfaces. >>=20 >> WAN interfaces are used to send Ingress traffic from the Internet = to >> the End-User, and Egress traffic from the End-User network to the >> Internet. Ingress traffic may be received on any active interface = at >> any time. Egress traffic follows a set of rules within the CE in >> order to choose the proper WAN interface. This is important not = only >> in order to choose the best path, but also because the networks = that >> the CE are connected to typically employ source address = verification >> mechanisms. >>=20 >> Packets arriving at the CE have an IPv6 source address chosen by = the >> host [RFC3484]. The CE router performs source address dependent = routing (SAD), >> such that the egress WAN interface is chosen based on the packet's = source >> address matching the delegated prefix associate with the egress WAN >> interface. >=20 > +1 :-) >=20 >=20 > (Given that the first paragraph considers all "outside" interfaces to = be > "WAN interfaces", and doesn't differenciate between "the 6rd" and "the = WAN" > interface, generic usage of "WAN interface" in the following text is=20= > perfectly fine with me). Yes, 6rd, native, and any other data link that can carry IPv6 packet = to/from an ISP is a "WAN Interface" in the context of the requirements. I agree that the above descriptive text would be helpful to the = reader/implementor.=20 - Mark >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From v6ops@globis.net Thu May 3 02:03:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EC521F85B8 for ; Thu, 3 May 2012 02:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, MANGLED_MARKET=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4mDHrbmwk7b for ; Thu, 3 May 2012 02:03:54 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E5F2A21F854B for ; Thu, 3 May 2012 02:03:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8D2E6870082; Thu, 3 May 2012 11:03:45 +0200 (CEST) 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 sFj76jWrJbvK; Thu, 3 May 2012 11:03:37 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 7C06D87005E; Thu, 3 May 2012 11:03:37 +0200 (CEST) Message-ID: <4FA249E8.5020709@globis.net> Date: Thu, 03 May 2012 11:03:36 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com > <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> In-Reply-To: <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 09:03:55 -0000 Sorry. 6204bis is in danger of rat-holing. 6204bis is not multihomed IMHO. Section 3.2. "The end-user network is a stub network" Section 2 states "The IPv6 CE router connects the end-user network to a [singular] service provider network." Section 2 also talks about "WAN Interface an IPv6 CE router's attachment to a [singular] link " Section 3.2 the document also talks about "Provisioning of the [singular] WAN interface connecting to the [singular] service provider" W1 "When the router is attached to the [singular] WAN interface link" If we're going to get picky about one or more WAN interfaces on the CPE router, one or more active links per WAN interface, or one or more service provider networks per router, there's plenty more places that need to be changed in the text if we want to be entirely consistent. regards, RayH Ole Trĝan wrote: > Mark, et, al, > > [...] > >> 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6. >> >> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the upstream network the WAN interface is connected to [Section 4.3 [RFC3704]]. >> >> 6RD-6: The CE router MUST allow different as well as identical delegated prefixes to be configured via each (6rd or native) WAN interface. >> >> 6RD-7: In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. > > I have a few nitpicks with the language above. e.g. the use of "derived". I'll send those privately. generally I'm OK with the above. > > I think adding these paragraphs in the section introduction, would set the context for these > requirements better: > > A multihomed, multiprefix, IPv6 CE router has multiple WAN interfaces > connecting it to one or more Service Providers. The interfaces may > be "real" or "virtual" in the case of tunneling technology such as > 6rd [RFC5969]. The CE router receives one or more delegated > prefixes, each associated with one or more WAN interfaces. > > WAN interfaces are used to send Ingress traffic from the Internet to > the End-User, and Egress traffic from the End-User network to the > Internet. Ingress traffic may be received on any active interface at > any time. Egress traffic follows a set of rules within the CE in > order to choose the proper WAN interface. This is important not only > in order to choose the best path, but also because the networks that > the CE are connected to typically employ source address verification > mechanisms. > > Packets arriving at the CE have an IPv6 source address chosen by the > host [RFC3484]. The CE router performs source address dependent routing (SAD), > such that the egress WAN interface is chosen based on the packet's source > address matching the delegated prefix associate with the egress WAN > interface. > > > cheers, > Ole > > From fgont@si6networks.com Thu May 3 02:08:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C25621F85B5 for ; Thu, 3 May 2012 02:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOjpWvtHQDDy for ; Thu, 3 May 2012 02:08:24 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id A75BE21F85D0 for ; Thu, 3 May 2012 02:08:24 -0700 (PDT) Received: from [190.50.178.136] (helo=[192.168.1.42]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SPs1H-0005Bl-02; Thu, 03 May 2012 11:08:15 +0200 Message-ID: <4FA22A2A.5080006@si6networks.com> Date: Thu, 03 May 2012 03:48:10 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> In-Reply-To: <4F948546.8040205@inex.ie> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 09:08:25 -0000 Hi, Nick, On 04/22/2012 07:25 PM, Nick Hilliard wrote: > reading back over this, I wonder would it be useful to make a > recommendation to vendors to implement some form of logging for dropped > packets so that operators can choose to have visibility into this problem > on their networks. Silently dropping packets is all very well, but many > operators like to feel that if a packet is dropped, they should know about it. Regarding your suggestion to log dropped packets, do you have any proposed text to address it? May be I could simply add this "and this event SHOULD be logged (e.g., a counter could be incremented reflecting the packet drop)." to each rule that recommends to drop the packet? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ichiroumakino@gmail.com Thu May 3 02:19:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0BA21F85D3 for ; Thu, 3 May 2012 02:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, MANGLED_MARKET=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9p7odtPjprB for ; Thu, 3 May 2012 02:19:50 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E93B21F854C for ; Thu, 3 May 2012 02:19:49 -0700 (PDT) Received: by werb10 with SMTP id b10so1210303wer.31 for ; Thu, 03 May 2012 02:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MEpASXt8zoGz7633WPV/MK3DFRyBwSSZmNpH9R4HDbY=; b=HdY3nMrFlfwolFp0FJ0hnm+Ix5BRSp7vQlFM2rhIKnCW7keP773j+TbAq8Ziq9mVrE Vv0sV4agZufyd8q9dlwSP7Wf8NgMWCpodJ2VL+YNCs276qeLO7W4uYRZtXh/r3QzDbvl e5/9H11tmKTNiTaHlIc/rOP3ThDvGZFYguDFwfEy8cLgwxygd8nYs3aCu8vptZf7CNcd 2jCrgs/EDpakvbCkhOgNt8RUwh0TKsmDJFmOC0WKX2K9pWhQUcRvj67E1xvY+jCy360j yfigV2Zt9UGB5KOIRizbanc5TGJZH6B0hBT+UmoeN78AfFzAH7RR9TOyoFhPPR4cfD9B ZZ0Q== Received: by 10.180.82.5 with SMTP id e5mr1435114wiy.0.1336036394681; Thu, 03 May 2012 02:13:14 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-95.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fl2sm1585224wib.2.2012.05.03.02.13.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 02:13:13 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4FA249E8.5020709@globis.net> Date: Thu, 3 May 2012 11:13:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <228ABEB7-1136-47AC-AF97-F8EBC1303030@employees.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com > <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> <4FA249E8.5020709@globis.net > To: Ray Hunter X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 09:19:51 -0000 > Sorry. 6204bis is in danger of rat-holing. 6204bis is not multihomed = IMHO. been ratholed for a long time. ;-) the introduction of transition mechanisms implies multi-homing. we went = over this in Paris. I just don't see a way around that. cheers, Ole >=20 > Section 3.2. "The end-user network is a stub network" >=20 > Section 2 states "The IPv6 CE router connects the end-user network to = a [singular] service provider network." >=20 > Section 2 also talks about "WAN Interface an IPv6 CE = router's attachment to a [singular] link " >=20 > Section 3.2 the document also talks about "Provisioning of the = [singular] WAN interface connecting to the [singular] service provider" >=20 > W1 "When the router is attached to the [singular] WAN interface link" >=20 > If we're going to get picky about one or more WAN interfaces on the = CPE router, one or more active links per WAN interface, or one or more = service provider networks per router, there's plenty more places that = need to be changed in the text if we want to be entirely consistent. >=20 > regards, > RayH >=20 >=20 > Ole Tr=F8an wrote: >> Mark, et, al, >>=20 >> [...] >>=20 >>> 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to = be active alone as well as simultaneously in order to support = coexistence of the two technologies during an incremental migration = period from 6rd to native IPv6. >>>=20 >>> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [Section 4.3 [RFC3704]]. >>>=20 >>> 6RD-6: The CE router MUST allow different as well as identical = delegated prefixes to be configured via each (6rd or native) WAN = interface. >>>=20 >>> 6RD-7: In the event that forwarding rules produce a tie between 6rd = and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. >>=20 >> I have a few nitpicks with the language above. e.g. the use of = "derived". I'll send those privately. generally I'm OK with the above. >>=20 >> I think adding these paragraphs in the section introduction, would = set the context for these >> requirements better: >>=20 >> A multihomed, multiprefix, IPv6 CE router has multiple WAN = interfaces >> connecting it to one or more Service Providers. The interfaces = may >> be "real" or "virtual" in the case of tunneling technology such as >> 6rd [RFC5969]. The CE router receives one or more delegated >> prefixes, each associated with one or more WAN interfaces. >>=20 >> WAN interfaces are used to send Ingress traffic from the Internet = to >> the End-User, and Egress traffic from the End-User network to the >> Internet. Ingress traffic may be received on any active interface = at >> any time. Egress traffic follows a set of rules within the CE in >> order to choose the proper WAN interface. This is important not = only >> in order to choose the best path, but also because the networks = that >> the CE are connected to typically employ source address = verification >> mechanisms. >>=20 >> Packets arriving at the CE have an IPv6 source address chosen by = the >> host [RFC3484]. The CE router performs source address dependent = routing (SAD), >> such that the egress WAN interface is chosen based on the packet's = source >> address matching the delegated prefix associate with the egress = WAN >> interface. >>=20 >>=20 >> cheers, >> Ole >>=20 >>=20 From nick@inex.ie Thu May 3 04:22:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930DD21F85C0 for ; Thu, 3 May 2012 04:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0BCwoxGdZnt for ; Thu, 3 May 2012 04:22:39 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 41CEB21F85BD for ; Thu, 3 May 2012 04:22:38 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-251.int.inex.ie (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q43BM3Q6045729 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 May 2012 12:22:03 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FA26A73.9070001@inex.ie> Date: Thu, 03 May 2012 12:22:27 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Fernando Gont References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> <4FA22A2A.5080006@si6networks.com> In-Reply-To: <4FA22A2A.5080006@si6networks.com> X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 11:22:47 -0000 On 03/05/2012 07:48, Fernando Gont wrote: > Regarding your suggestion to log dropped packets, do you have any > proposed text to address it? yes, that would probably help. I'd drop the word "silently" from paragraphs 3.1, 3.2 and 3.3, because that implies no logging. After paragraph 3.4, insert before "In order to protect current ...": -- If a packet is dropped due to this filtering mechanism, then this packet drop event SHOULD be logged. The logging mechanism SHOULD include a drop counter dedicated to RA-Guard packet drops. -- Nick From Jean-Francois.TremblayING@videotron.com Thu May 3 07:23:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F82D21F85D3 for ; Thu, 3 May 2012 07:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6bXxU9EBRIy for ; Thu, 3 May 2012 07:23:03 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 41A9F21F85C2 for ; Thu, 3 May 2012 07:23:03 -0700 (PDT) In-Reply-To: <228ABEB7-1136-47AC-AF97-F8EBC1303030@employees.org> To: IPv6 Operations , =?ISO-8859-1?Q?Ole_Tr=F8an?= MIME-Version: 1.0 X-KeepSent: 6F3FFE2A:09D389E8-852579F3:0044C883; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 3 May 2012 10:22:44 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/03/2012 10:22:52, Serialize complete at 05/03/2012 10:22:52 Content-Type: multipart/alternative; boundary="=_alternative 004EFF9A852579F3_=" Received-SPF: none Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 14:23:04 -0000 Message en plusieurs parties au format MIME --=_alternative 004EFF9A852579F3_= Content-Type: text/plain; charset="US-ASCII" > been ratholed for a long time. ;-) A very deep hole indeed. My apologies for adding depth to it, below. > the introduction of transition mechanisms implies multi-homing. we went over this in Paris. I wasn't in Paris, so I might be missing something here (I did read slides-83-v6ops-13), but allow me to disagree partially with your statement above. Transition mechanisms only imply multihoming if both native and transition are run in parallel for a given address family (as stated in your presentation). Running them in parallel is only desirable if the same prefix has to be used internally (this is 6RD sunsetting requirement #2, page 4 of the slides). What is the applicability of that requirement? In my humble opinion as an operator running both 6RD and native IPv6, it's perfectly fine to toggle between native IPv6 and 6RD without having both enabled at the same time. Ever. Yes, this means the delegated prefix will change, but I am perfectly fine with this and I suspect many operators will be too. How many operators who will sunset 6RD one day will really in a position to 1) keep the same prefix and 2) really need the prefix to remain the same at all cost? I suspect 1) is a fairly small number and 2) is an even smaller subset (equal to 1?). 6RD sunsetting can be done automatically easily and cheaply. Send option 212 in DHCPv4 and if DHCPv6 fails, start 6RD after DHCPv4 has completed. Call this "poor-man's 6RD sunsetting", but it works and is probably in line with most operators needs. I agree with Barbara here, what we need is working IPv6 implementations that include 6RD. Adding any kind of multihoming requirement such as 6RD-[4-7] is counterproductive to timely and widespread implementations of 6204bis in home routeurs. It took years of work to get DHCPv6-PD implementations right, adding multihoming will likely add more years to that. I understand this comment comes late in an argument that seems alredy lost, but I felt it needed to be said. As Barbara pointed out, we haven't seen the 6RD sunsetting requirements being discussed on the list. IMHO any form of multihoming, including 6RD sunsetting, shouldn't be in 6204bis at all. This was agreed initially when work on 'bis' began and the current text still reflects it (Ray just pointed it out). JF Tremblay --=_alternative 004EFF9A852579F3_= Content-Type: text/html; charset="US-ASCII"
> been ratholed for a long time. ;-)
A very deep hole indeed. My apologies for adding depth to it, below.

> the introduction of transition mechanisms implies multi-homing. we went over this in Paris.

I wasn't in Paris, so I might be missing something here (I did read
slides-83-v6ops-13), but allow me to disagree partially with your
statement above.

Transition mechanisms only imply multihoming if both native and transition are
run in parallel for a given address family (as stated in your presentation).
Running them in parallel is only desirable if the same prefix has to be used
internally (this is 6RD sunsetting requirement #2, page 4 of the slides).
What is the applicability of that requirement?

In my humble opinion as an operator running both 6RD and native IPv6, it's
perfectly fine to toggle between native IPv6 and 6RD without having both
enabled at the same time. Ever. Yes, this means the delegated prefix will
change, but I am perfectly fine with this and I suspect many operators will
be too. How many operators who will sunset 6RD one day will really in a
position to 1) keep the same prefix and 2) really need the prefix to remain
the same at all cost? I suspect 1) is a fairly small number and 2) is an even
smaller subset (equal to 1?).

6RD sunsetting can be done automatically easily and cheaply. Send option 212
in DHCPv4 and if DHCPv6 fails, start 6RD after DHCPv4 has completed. Call this
"poor-man's 6RD sunsetting", but it works and is probably in line
with most operators needs.

I agree with Barbara here, what we need is working IPv6 implementations that
include 6RD. Adding any kind of multihoming requirement such as 6RD-[4-7] is
counterproductive to timely and widespread implementations of 6204bis in home
routeurs. It took years of work to get DHCPv6-PD implementations right, adding
multihoming will likely add more years to that.

I understand this comment comes late in an argument that seems alredy lost, but
I felt it needed to be said. As Barbara pointed out, we haven't seen the
6RD sunsetting requirements being discussed on the list. IMHO any form
of multihoming, including 6RD sunsetting, shouldn't be in 6204bis at all.
This was agreed initially when work on 'bis' began and the current text
still reflects it (Ray just pointed it out).  

JF Tremblay
</operator hat>

--=_alternative 004EFF9A852579F3_=-- From ichiroumakino@gmail.com Thu May 3 07:52:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF75621F8592 for ; Thu, 3 May 2012 07:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6uzmNlEw0cI for ; Thu, 3 May 2012 07:52:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 721B521F846C for ; Thu, 3 May 2012 07:52:16 -0700 (PDT) Received: by lagj5 with SMTP id j5so1505022lag.31 for ; Thu, 03 May 2012 07:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=IEbIqtUZScuAibTTfHzUkTJxKkMqPwPTW1yL/ussYec=; b=tz/b33L3QOLIpCCEcRo/nTy+1lkzwX7gQrIJqKmay+lcthryXTfhjhqBtq5Q3ReCk0 xAmj7wSfrHDBJQRXB98AgDKLEhnsxewo4qL1wpLSAOMO1gIha9M/tLDfnW7Jeu9U0mJJ 99u3uIIlJhX23UpK1aIXJLY9hvJr9XQar8+V4+Vsse+zJuShhGQ1sDz2YfiNZO0zgWEg Yt1q6H7XDswgF0NeXg3H6oQbX26Mbahr43s/Lhk0ap3y/nXIKkq9vR0s1CEiOnjbPE6o bt1+I2qrS2qfd7DGZQuQyfDlHDPaKmO/TZ+1TtL+N/EQcWTAl5mbFipTVNQFpvsIiUjd GchA== Received: by 10.152.112.100 with SMTP id ip4mr2412080lab.1.1336056735168; Thu, 03 May 2012 07:52:15 -0700 (PDT) Received: from gomlefisk.lan ([84.48.213.97]) by mx.google.com with ESMTPS id oi3sm5779925lab.12.2012.05.03.07.52.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 07:52:14 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 3 May 2012 16:52:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 14:52:18 -0000 > 6RD sunsetting can be done automatically easily and cheaply. Send = option 212=20 > in DHCPv4 and if DHCPv6 fails, start 6RD after DHCPv4 has completed. = Call this=20 > "poor-man's 6RD sunsetting", but it works and is probably in line=20 > with most operators needs. >=20 > [VK] Agree. This is the way I want my vendors to do it (and what I = will demand). Only do 6RD if IPv6 fails (if I can figure out how to = only offer Option 212 when desired =96 is even better, but may not be = possible). I have no production need to have everything turned on and = run complex code to sort out the details. At this point, my opinion = remains the same. Keep it simple. The small delay in activation is = well worth the operational benefits of simpler code and more = deterministic behaviours (IMHO). yes, you _can_ do it this way. iff we were to do this, someone would have to describe what the = time-outs are going to be, and how a CPE should behave when this is = 'changed on the fly'. the same thing has to be described in reverse for = the DS-lite case. basically 6rd has to wait for IPv4 to be provisioned, = and IPv4 has to wait for IPv6 to be provisioned (to determine if it = should do DS-lite for IPv4 or not). I claim this is more complicated = than simply specifying how they can operate independently of each other. cheers, Ole= From victor.kuarsingh@gmail.com Thu May 3 07:53:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BC821F861B for ; Thu, 3 May 2012 07:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM3b4AaN2lsH for ; Thu, 3 May 2012 07:53:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA0521F8628 for ; Thu, 3 May 2012 07:53:16 -0700 (PDT) Received: by yenq7 with SMTP id q7so2190171yen.31 for ; Thu, 03 May 2012 07:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type; bh=o6+FQYcmvZzMv32kiqkY36Z+bsYA4WK9wJsMjz2sYCg=; b=kuGZdpdiOJWj79Nl1FPCZlCA3TJyWSjtvKV2FVVLdA2yD5n1nCaYMtP49/b8FGLjie 715hqlWGDPDalktFEw6d9Z6cOJytMi03ke9GyA8hikKlxQt2Lx+8wmX2IbfgQj38GxqT OcwTWCmpbmhcEInTXWTzO+OqPun3mBfd7FLbA/aBN4XgObOrljr72Du0Sk0FLMxFFgVr pt97Vyox9jS+tkiOb9EIzN9BZ3ftOCUvT4l8Uew84m6L5UCchQQzmlGmIx+8BFdny4wW xqoMd6Tep76oy1gq0gRyCMuQWuqfHSXliGPf919Yy2SEjC+kveiiZQU7Lx/pGfBfG+Tu 7fRw== Received: by 10.50.180.137 with SMTP id do9mr818509igc.71.1336056458066; Thu, 03 May 2012 07:47:38 -0700 (PDT) Received: from [10.10.58.56] (surf3.net.rss.rogers.com. [24.114.255.3]) by mx.google.com with ESMTPS id gf4sm63064igb.14.2012.05.03.07.47.34 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 07:47:36 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 03 May 2012 10:47:34 -0400 From: Victor Kuarsingh To: , IPv6 Operations , Ole =?ISO-8859-1?B?VHL4YW4=?= Message-ID: Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3418886857_5087681" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 14:53:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3418886857_5087681 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable From: wrote: Transition mechanisms only imply multihoming if both native and transition are=20 run in parallel for a given address family (as stated in your presentation)= . Running them in parallel is only desirable if the same prefix has to be use= d internally (this is 6RD sunsetting requirement #2, page 4 of the slides). What is the applicability of that requirement? [VK] We do not plan on running them in parallel In my humble opinion as an operator running both 6RD and native IPv6, it's perfectly fine to toggle between native IPv6 and 6RD without having both enabled at the same time. Ever. Yes, this means the delegated prefix will change, but I am perfectly fine with this and I suspect many operators will be too. How many operators who will sunset 6RD one day will really in a position to 1) keep the same prefix and 2) really need the prefix to remain the same at all cost? I suspect 1) is a fairly small number and 2) is an even=20 smaller subset (equal to 1?). [VK] Toggle, yes, both active simultaneously? - No. One or the other seems the most operationally sound. I don't have IETFers troubleshooting connectivity issues for the millions of endpoints in the network, so comple= x flow patterns will likely result in long and complex troubleshooting (which is the worst thing for my IPv6 deployment). 6RD sunsetting can be done automatically easily and cheaply. Send option 21= 2 in DHCPv4 and if DHCPv6 fails, start 6RD after DHCPv4 has completed. Call this=20 "poor-man's 6RD sunsetting", but it works and is probably in line with most operators needs. [VK] Agree. This is the way I want my vendors to do it (and what I will demand). Only do 6RD if IPv6 fails (if I can figure out how to only offer Option 212 when desired =AD is even better, but may not be possible). I have no production need to have everything turned on and run complex code to sor= t out the details. At this point, my opinion remains the same. Keep it simple. The small delay in activation is well worth the operational benefits of simpler code and more deterministic behaviours (IMHO). I agree with Barbara here, what we need is working IPv6 implementations tha= t include 6RD. Adding any kind of multihoming requirement such as 6RD-[4-7] i= s counterproductive to timely and widespread implementations of 6204bis in home=20 routeurs. It took years of work to get DHCPv6-PD implementations right, adding=20 multihoming will likely add more years to that. [VK] Agree. My biggest issue is basic code not running well in production. Having solid IPv6 is mission #1. All these points were the ones I made at the MIC in paris. Also, Operator Hat. Regards, Victor _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3418886857_5087681 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
From: <Jean-Francois.TremblayING@videotron.com> wrote:<= /div>


Transition mechanisms only imply mul= tihoming if both native and transition are
run in parallel for a given ad= dress family (as stated in your presentation).
Running them in parallel is only = desirable if the same prefix has to be used
internally (this is 6RD sunse= tting requirement #2, page 4 of the slides).
What is the applicability of that= requirement?

[VK] We do not plan on running them in parallel

In my humble opinion as an operator run= ning both 6RD and native IPv6, it's
perfectly fine to = toggle between native IPv6 and 6RD without having both
enabled at the same = time. Ever. Yes, this means the delegated prefix will
change, but I am p= erfectly fine with this and I suspect many operators will
be too. How many ope= rators who will sunset 6RD one day will really in a
position to 1) keep= the same prefix and 2) really need the prefix to remain
the same at al= l cost? I suspect 1) is a fairly small number and 2) is an even
smaller subset = (equal to 1?).

[VK] Toggle, yes, both active simultaneously? - No. &n= bsp;One or the other seems the most operationally sound.  I don't have = IETFers troubleshooting connectivity issues for the millions of endpoints in= the network, so complex flow patterns will likely result in long and comple= x troubleshooting (which is the worst thing for my IPv6 deployment).


6RD sunsetting can be done automati= cally easily and cheaply. Send option 212
in DHCPv4 and i= f DHCPv6 fails, start 6RD after DHCPv4 has completed. Call this
"poor-man's 6RD= sunsetting", but it works and is probably in line
with most operat= ors needs.

[VK] Agree. This is the way I want my vendors to do it (an= d what I will demand).  Only do 6RD if IPv6 fails (if I can figure out = how to only offer Option 212 when desired – is even better, but may no= t be possible).  I have no production need to have everything turned on= and run complex code to sort out the details.  At this point, my opini= on remains the same.  Keep it simple.  The small delay in activati= on is well worth the operational benefits of simpler code and more determini= stic behaviours (IMHO).


I ag= ree with Barbara here, what we need is working IPv6 implementations that
include 6RD. A= dding any kind of multihoming requirement such as 6RD-[4-7] is
counterproductive t= o timely and widespread implementations of 6204bis in home
routeurs. It took yea= rs of work to get DHCPv6-PD implementations right, adding
multihoming will likely ad= d more years to that.

[VK] Agree. My biggest issue is basic code not = running well in production. Having solid IPv6 is mission #1.

All these points were = the ones I made at the MIC in paris.

Also, Operator Hat.

Regards,

Victor

_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3418886857_5087681-- From simon.perreault@viagenie.ca Thu May 3 08:04:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327AD21F8630 for ; Thu, 3 May 2012 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFCrRi+ZXDu3 for ; Thu, 3 May 2012 08:04:10 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 8D78621F84C5 for ; Thu, 3 May 2012 08:04:10 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:fd74:94dc:fbc7:7264]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2006B4038B for ; Thu, 3 May 2012 11:04:10 -0400 (EDT) Message-ID: <4FA29E69.1040304@viagenie.ca> Date: Thu, 03 May 2012 11:04:09 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 15:04:11 -0000 On 2012-05-03 10:47, Victor Kuarsingh wrote: > Only do 6RD if IPv6 fails (if I can figure out how to only > offer Option 212 when desired – is even better, but may not be > possible). Why not unconditionally ask for option 212 and only activate the 6RD interface after DHCPv6 fails? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Jean-Francois.TremblayING@videotron.com Thu May 3 08:18:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06EE21F8659 for ; Thu, 3 May 2012 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz4JMTIS4F9Z for ; Thu, 3 May 2012 08:18:27 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3B53321F8653 for ; Thu, 3 May 2012 08:18:27 -0700 (PDT) In-Reply-To: To: otroan@employees.org MIME-Version: 1.0 X-KeepSent: BC03B948:9AEEBA22-852579F3:00528448; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 3 May 2012 11:18:13 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/03/2012 11:18:21, Serialize complete at 05/03/2012 11:18:21 Content-Type: multipart/alternative; boundary="=_alternative 0054140B852579F3_=" Received-SPF: none Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 15:18:27 -0000 Message en plusieurs parties au format MIME --=_alternative 0054140B852579F3_= Content-Type: text/plain; charset="US-ASCII" > basically 6rd has to wait for IPv4 to be provisioned, and IPv4 has to wait > for IPv6 to be provisioned (to determine if it should do DS-lite for IPv4 or not). > I claim this is more complicated than simply specifying how they can operate > independently of each other. > Ole Agreed. But I claim the "alternate-on" approach, even given timers and a proper (small) state machine is less complex for an implementer to put together than introducing multihoming at this point. I would love to hear from implementers such as Hans on this. Even on the long term, although the multi-homed approach seems great engineering idea for 6RD, I'm not sure the requirement of keeping the same IPv6 prefix needs to be there. It looks hardly feasible to keep the same prefix length between 6RD and native, as the first tends to be much longer (smaller) in most deployments. It also ties together the IPv6 and IPv4 topologies, which is not especially desirable in most networks. Again, feedback from those who consider 6RD sunset would be desirable. /JF --=_alternative 0054140B852579F3_= Content-Type: text/html; charset="US-ASCII"
> basically 6rd has to wait for IPv4 to be provisioned, and IPv4 has to wait
> for IPv6 to be provisioned (to determine if it should do DS-lite for IPv4 or not).
> I claim this is more complicated than simply specifying how they can operate
> independently of each other.
> Ole

Agreed. But I claim the "alternate-on" approach, even given timers and a proper
(small) state machine is less complex for an implementer to put together
than introducing multihoming at this point. I would love to hear from
implementers such as Hans on this.

Even on the long term, although the multi-homed approach seems great
engineering idea for 6RD, I'm not sure the requirement of keeping
the same IPv6 prefix needs to be there. It looks hardly feasible to keep
the same prefix length between 6RD and native, as the first tends to be
much longer (smaller) in most deployments. It also ties together the IPv6
and IPv4 topologies, which is not especially desirable in most networks.
Again, feedback from those who consider 6RD sunset would be desirable.

/JF


--=_alternative 0054140B852579F3_=-- From mark@townsley.net Thu May 3 08:40:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A94421F853E for ; Thu, 3 May 2012 08:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6U+uln7kqnM for ; Thu, 3 May 2012 08:40:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8356721F850C for ; Thu, 3 May 2012 08:40:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMWlok+Q/khL/2dsb2JhbABEsnaBB4IJAQEBAwEBAQEPAVsLBQsLRicwGSKHZgULmiegHwSQJWMEpFeBaYJq X-IronPort-AV: E=Sophos;i="4.75,524,1330905600"; d="scan'208,217";a="136961468" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 May 2012 15:40:01 +0000 Received: from ams-townsley-8914.cisco.com (ams-townsley-8914.cisco.com [10.55.23.165]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q43Fe15O004634; Thu, 3 May 2012 15:40:01 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_F054A3C0-C016-45E2-B83F-4677651720CE" From: Mark Townsley In-Reply-To: Date: Thu, 3 May 2012 17:40:00 +0200 Message-Id: References: To: Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 15:40:04 -0000 --Apple-Mail=_F054A3C0-C016-45E2-B83F-4677651720CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 And there is nothing stopping you from toggling your users with the = model we have described. =20 But, if you happen to be an operator with no ability to control your = CPE, or to detect whether the CPE connected is has only 6rd or native = (or if there is a local switch on the CPE, what position it is in), = there is a problem. =20 What we don't want to develop is something that will work on one network = when set in one mode, and another network only when set in another mode. = We don't want to care what network we are connected to. We want to let = the ISP send whatever configuration it wants, in whatever order it = wants, and we'll make it work rather than trying to guess what you are = trying to do -- or, force our home-user customers to step through some = manual configuration process=85 "Check with your Operator to see if they = are a 6rd or Native IPv6 operator and set this value accordingly"=20 The "Poor man's 6rd sunsetting" you refer to is what I called "forced = single-homing" in the presentation. This is begging for a race-condition = issue to crop up, ties together the v4 and v6 state machines, and = eliminates the ability to transition a user without renumbering.=20 - Mark On May 3, 2012, at 4:22 PM, Jean-Francois.TremblayING@videotron.com = wrote: >=20 > > been ratholed for a long time. ;-) > A very deep hole indeed. My apologies for adding depth to it, below.=20= >=20 > > the introduction of transition mechanisms implies multi-homing. we = went over this in Paris.=20 >=20 > I wasn't in Paris, so I might be missing something here (I did read=20 > slides-83-v6ops-13), but allow me to disagree partially with your=20 > statement above.=20 >=20 > Transition mechanisms only imply multihoming if both native and = transition are=20 > run in parallel for a given address family (as stated in your = presentation).=20 > Running them in parallel is only desirable if the same prefix has to = be used=20 > internally (this is 6RD sunsetting requirement #2, page 4 of the = slides).=20 > What is the applicability of that requirement?=20 >=20 > In my humble opinion as an operator running both 6RD and native IPv6, = it's=20 > perfectly fine to toggle between native IPv6 and 6RD without having = both=20 > enabled at the same time. Ever. Yes, this means the delegated prefix = will=20 > change, but I am perfectly fine with this and I suspect many operators = will=20 > be too. How many operators who will sunset 6RD one day will really in = a=20 > position to 1) keep the same prefix and 2) really need the prefix to = remain=20 > the same at all cost? I suspect 1) is a fairly small number and 2) is = an even=20 > smaller subset (equal to 1?).=20 >=20 > 6RD sunsetting can be done automatically easily and cheaply. Send = option 212=20 > in DHCPv4 and if DHCPv6 fails, start 6RD after DHCPv4 has completed. = Call this=20 > "poor-man's 6RD sunsetting", but it works and is probably in line=20 > with most operators needs.=20 >=20 > I agree with Barbara here, what we need is working IPv6 = implementations that=20 > include 6RD. Adding any kind of multihoming requirement such as = 6RD-[4-7] is=20 > counterproductive to timely and widespread implementations of 6204bis = in home=20 > routeurs. It took years of work to get DHCPv6-PD implementations = right, adding=20 > multihoming will likely add more years to that.=20 >=20 > I understand this comment comes late in an argument that seems alredy = lost, but=20 > I felt it needed to be said. As Barbara pointed out, we haven't seen = the=20 > 6RD sunsetting requirements being discussed on the list. IMHO any form=20= > of multihoming, including 6RD sunsetting, shouldn't be in 6204bis at = all.=20 > This was agreed initially when work on 'bis' began and the current = text=20 > still reflects it (Ray just pointed it out). =20 >=20 > JF Tremblay=20 > =20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_F054A3C0-C016-45E2-B83F-4677651720CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

The "Poor man's 6rd = sunsetting" you refer to is what I called "forced single-homing" in the = presentation. This is begging for a race-condition issue to crop up, = ties together the v4 and v6 state machines, and eliminates the ability = to transition a user without = renumbering. 

- Mark

On = May 3, 2012, at 4:22 PM, Jean-Francois.Trem= blayING@videotron.com wrote:


> been ratholed for a long time. ;-)
A very deep hole indeed. My apologies for adding depth to it, below. =

> the introduction of transition mechanisms implies multi-homing. we went over this in Paris.

I wasn't in Paris, so I might be missing = something here (I did read
slides-83-v6ops-13), but allow me to disagree = partially with your
statement above.

Transition mechanisms only imply multihoming if = both native and transition are
run in parallel for a given address family (as = stated in your presentation).
Running them in parallel is only desirable if = the same prefix has to be used
internally (this is 6RD sunsetting requirement = #2, page 4 of the slides).
What is the applicability of that requirement? =

In my humble opinion as an operator running = both 6RD and native IPv6, it's
perfectly fine to toggle between native IPv6 = and 6RD without having both
enabled at the same time. Ever. Yes, this means = the delegated prefix will
change, but I am perfectly fine with this and I = suspect many operators will
be too. How many operators who will sunset 6RD = one day will really in a
position to 1) keep the same prefix and 2) = really need the prefix to remain
the same at all cost? I suspect 1) is a fairly = small number and 2) is an even
smaller subset (equal to 1?).

6RD sunsetting can be done automatically easily = and cheaply. Send option 212
in DHCPv4 and if DHCPv6 fails, start 6RD after = DHCPv4 has completed. Call this
"poor-man's 6RD sunsetting", but it works and is probably in line
with most operators needs.

I agree with Barbara here, what we need is = working IPv6 implementations that
include 6RD. Adding any kind of multihoming = requirement such as 6RD-[4-7] is
counterproductive to timely and widespread = implementations of 6204bis in home
routeurs. It took years of work to get = DHCPv6-PD implementations right, adding
multihoming will likely add more years to that. =

I understand this comment comes late in an = argument that seems alredy lost, but
I felt it needed to be said. As Barbara pointed = out, we haven't seen the
6RD sunsetting requirements being discussed on = the list. IMHO any form
of multihoming, including 6RD sunsetting, = shouldn't be in 6204bis at all.
This was agreed initially when work on 'bis' = began and the current text
still reflects it (Ray just pointed it out). =  

JF Tremblay
</operator hat>

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

= --Apple-Mail=_F054A3C0-C016-45E2-B83F-4677651720CE-- From mark@townsley.net Thu May 3 08:43:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094E021F860F for ; Thu, 3 May 2012 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BUHf+SV36Nw for ; Thu, 3 May 2012 08:43:38 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 89C5721F85FB for ; Thu, 3 May 2012 08:43:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKamok+Q/khM/2dsb2JhbABEsnaBB4IJAQEBAwESAWYFCwsRAwECLyEuCBkih10DBgWaMJZDDYlTigaDXYJCYwShPYMagWmCag X-IronPort-AV: E=Sophos;i="4.75,524,1330905600"; d="scan'208,217";a="72377848" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 May 2012 15:43:33 +0000 Received: from ams-townsley-8914.cisco.com (ams-townsley-8914.cisco.com [10.55.23.165]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q43FhXBi029456; Thu, 3 May 2012 15:43:33 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_42962ED4-426D-4CE5-98EB-980CD3DD97CB" From: Mark Townsley In-Reply-To: Date: Thu, 3 May 2012 17:43:33 +0200 Message-Id: <04A5E500-9228-41D2-9B30-C8FA8D53B3B7@townsley.net> References: To: Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 15:43:39 -0000 --Apple-Mail=_42962ED4-426D-4CE5-98EB-980CD3DD97CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2012, at 5:18 PM, Jean-Francois.TremblayING@videotron.com = wrote: >=20 > > basically 6rd has to wait for IPv4 to be provisioned, and IPv4 has = to wait=20 > > for IPv6 to be provisioned (to determine if it should do DS-lite for = IPv4 or not).=20 > > I claim this is more complicated than simply specifying how they can = operate=20 > > independently of each other. > > Ole=20 >=20 > Agreed. But I claim the "alternate-on" approach, even given timers and = a proper=20 > (small) state machine is less complex for an implementer to put = together=20 > than introducing multihoming at this point. I would love to hear from=20= > implementers such as Hans on this.=20 Begin forwarded message: > From: Hans Liu > Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) > Date: May 1, 2012 12:27:47 AM GMT+02:00 > To: Mark Townsley > Cc: IPv6 Operations , Claire Cheng = >=20 > It looks like a lot of discussions were going on last week during my = absence. > I'm good with the idea in general while I believe Mark and Chris are > working on the text. > If a operator chooses to provision both 6rd and native IPv6, a CE > router needs to have the capability to support them simultaneously. In > terms, CPE has the capability while operators have the privilege > whether they would like to do that in their networks. And I will > implement the requirements in boxes of my company. --Apple-Mail=_42962ED4-426D-4CE5-98EB-980CD3DD97CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jean-Francois.Trem= blayING@videotron.com wrote:


> basically 6rd has to wait for IPv4 to be = provisioned, and IPv4 has to wait
> for IPv6 to be provisioned (to determine = if it should do DS-lite for IPv4 or not).
> I claim this is more complicated than = simply specifying how they can operate
> independently of each other.
> Ole

Agreed. But I claim the "alternate-on" = approach, even given timers and a proper
(small) state machine is less complex for an = implementer to put together
than introducing multihoming at this point. I = would love to hear from
implementers such as Hans on = this. 

Begin forwarded = message:

Hans Liu <hansliu@gmail.com>
Subject: Re: [v6ops] 6rd = sunsetting requirements (version 2)
Date: May 1, 2012 = 12:27:47 AM GMT+02:00
Mark Townsley <mark@townsley.net>
Cc: IPv6 Operations = <v6ops@ietf.org>, Claire = Cheng <claire_cheng@dlink.com.tw>= ;

It looks like a lot of discussions were going = on last week during my absence.
I'm good with the idea in general = while I believe Mark and Chris are
working on the text.
If a = operator chooses to provision both 6rd and native IPv6, a CE
router = needs to have the capability to support them simultaneously. = In
terms, CPE has the capability while operators have the = privilege
whether they would like to do that in their networks. And I = will
implement the requirements in boxes of my = company.
= --Apple-Mail=_42962ED4-426D-4CE5-98EB-980CD3DD97CB-- From Jean-Francois.TremblayING@videotron.com Thu May 3 09:10:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D22121F8630 for ; Thu, 3 May 2012 09:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS9kXJmUrVFw for ; Thu, 3 May 2012 09:10:05 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id A41E321F8604 for ; Thu, 3 May 2012 09:10:05 -0700 (PDT) In-Reply-To: To: mark@townsley.net MIME-Version: 1.0 X-KeepSent: 89FC7CA0:49307968-852579F3:00565E14; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 3 May 2012 12:09:51 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/03/2012 12:09:58, Serialize complete at 05/03/2012 12:09:58 Content-Type: multipart/alternative; boundary="=_alternative 0058CDE3852579F3_=" Received-SPF: none Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 16:10:09 -0000 Message en plusieurs parties au format MIME --=_alternative 0058CDE3852579F3_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgTWFyay4gDQoNCj4gQW5kIHRoZXJlIGlzIG5vdGhpbmcgc3RvcHBpbmcgeW91IGZyb20gdG9n Z2xpbmcgeW91ciB1c2VycyB3aXRoIHRoZSANCm1vZGVsIHdlIGhhdmUgZGVzY3JpYmVkLiANCg0K QWdyZWVkLCBidXQgdGhpcyBpcyBub3QgbXkgcG9pbnQuIE15IHBvaW50IGlzIHRoYXQgaW50cm9k dWNpbmcgbXVsdGlob21pbmcgDQppbiAnYmlzJyANCmJhc2VkIG9uIDZSRCBzdW5zZXR0aW5nIHJl cXVpcmVtZW50cyBpcyB2ZXJ5IGxpa2VseSB0byBzbG93IGRvd24gDQppbXBsZW1lbnRlcnMuIFdo ZXRoZXIgDQp0aGlzIHNsb3dkb3duIGlzIHRhbmdpYmxlIG9yIG5vdCByZW1haW5zIHRvIGJlIGNv bmZpcm1lZCwgYnV0IGEgbm9uLWVtcHR5IA0KZ3JvdXAgDQpvZiBjb25jZXJuZWQgb3BlcmF0b3Jz IGRlZmluaXRlbHkgZXhpc3RzIGhlcmUuIA0KDQo+IEJ1dCwgaWYgeW91IGhhcHBlbiB0byBiZSBh biBvcGVyYXRvciB3aXRoIG5vIGFiaWxpdHkgdG8gY29udHJvbCB5b3VyIA0KQ1BFLCBvciB0byBk ZXRlY3QgDQo+IHdoZXRoZXIgdGhlIENQRSBjb25uZWN0ZWQgaXMgaGFzIG9ubHkgNnJkIG9yIG5h dGl2ZSAob3IgaWYgdGhlcmUgaXMgYSANCmxvY2FsIHN3aXRjaCANCj4gb24gdGhlIENQRSwgd2hh dCBwb3NpdGlvbiBpdCBpcyBpbiksIHRoZXJlIGlzIGEgcHJvYmxlbS4gDQoNCldvdWxkIHlvdSBi ZSBraW5kIGVub3VnaCB0byBwb2ludCBhIHNjZW5hcmlvIHdoZXJlIHRoaXMgaXMgYW55IG1vcmUg DQpkYW5nZXJvdXMgdGhhbiANCmhhdmluZyB0aGUgdXNlciBjaG9vc2luZyAiNlJEIiBzdGF0aWNh bGx5IGZyb20gYSBkcm9wLWRvd24gbWVudT8gVGhpcyBpcyANCndoYXQgd2UgDQpoYXZlIG5vdyBh bmQgdGhlcmUgYXJlIGNlcnRhaW5seSBob21lIHVzZXJzIHdobyBzdGljayB0byA2UkQgZXZlbiBp ZiANCm5hdGl2ZSBpcyANCmF2YWlsYWJsZSBiZWNhdXNlIHRoZXkncmUgbm90IGF3YXJlIGl0J3Mg dGhlcmUuIFRoaXMgaXMgd2h5ICdiaXMnIGhhcyB0byANCmJlIHB1Ymxpc2hlZCBBU0FQIHdpdGgg cmVxdWlyZW1lbnRzIHRoYXQgY2FuIGJlIG1ldCBvbiBhIHNob3J0IHRpbWVmcmFtZS4gDQoNCj4g V2hhdCB3ZSBkb24ndCB3YW50IHRvIGRldmVsb3AgaXMgc29tZXRoaW5nIHRoYXQgd2lsbCB3b3Jr IG9uIG9uZSBuZXR3b3JrIA0Kd2hlbiANCj4gc2V0IGluIG9uZSBtb2RlLCBhbmQgYW5vdGhlciBu ZXR3b3JrIG9ubHkgd2hlbiBzZXQgaW4gYW5vdGhlciBtb2RlLiANCkFncmVlZC4gDQoNCj4gV2Ug ZG9uJ3QgDQo+IHdhbnQgdG8gY2FyZSB3aGF0IG5ldHdvcmsgd2UgYXJlIGNvbm5lY3RlZCB0by4g V2Ugd2FudCB0byBsZXQgdGhlIElTUCANCnNlbmQgDQo+IHdoYXRldmVyIGNvbmZpZ3VyYXRpb24g aXQgd2FudHMsIGluIHdoYXRldmVyIG9yZGVyIGl0IHdhbnRzLCBhbmQgd2UnbGwgDQo+IG1ha2Ug aXQgd29yayByYXRoZXIgdGhhbiB0cnlpbmcgdG8gZ3Vlc3Mgd2hhdCB5b3UgYXJlIHRyeWluZyB0 byBkbyAtLSANCj4gb3IsIGZvcmNlIG91ciBob21lLXVzZXIgY3VzdG9tZXJzIHRvIHN0ZXAgdGhy b3VnaCBzb21lIG1hbnVhbCANCmNvbmZpZ3VyYXRpb24gDQo+IHByb2Nlc3PigKYgIkNoZWNrIHdp dGggeW91ciBPcGVyYXRvciB0byBzZWUgaWYgdGhleSBhcmUgYSA2cmQgb3IgDQo+IE5hdGl2ZSBJ UHY2IG9wZXJhdG9yIGFuZCBzZXQgdGhpcyB2YWx1ZSBhY2NvcmRpbmdseSIgDQpBZ3JlZWQuIA0K DQo+IFRoZSAiUG9vciBtYW4ncyA2cmQgc3Vuc2V0dGluZyIgeW91IHJlZmVyIHRvIGlzIHdoYXQg SSBjYWxsZWQgDQo+ICJmb3JjZWQgc2luZ2xlLWhvbWluZyIgaW4gdGhlIHByZXNlbnRhdGlvbi4g VGhpcyBpcyBiZWdnaW5nIGZvciBhIA0KcmFjZS1jb25kaXRpb24gDQo+IGlzc3VlIHRvIGNyb3Ag dXAsIHRpZXMgdG9nZXRoZXIgdGhlIHY0IGFuZCB2NiBzdGF0ZSBtYWNoaW5lcywgYW5kIA0KZWxp bWluYXRlcyANCj4gdGhlIGFiaWxpdHkgdG8gdHJhbnNpdGlvbiBhIHVzZXIgd2l0aG91dCByZW51 bWJlcmluZy4gDQoNCkkgdW5kZXJzdGFuZCB5b3VyIHBvaW50LCBidXQgYWdhaW4sIEkgYmVsaWV2 ZSB0aGlzIHN0YXRlIG1hY2hpbmUgY2FuIGJlIA0KbWFkZSANCnNvIHNpbXBsZSB0aGF0IEkgc2lt cGx5IGRvbid0IGZvcmVzZWUgYSBzY2VuYXJpbyB3aGVyZSBpdCBjb3VsZCBmYWlsLiBBbmQgDQp5 ZXMgeW91IGNhbiBxdW90ZSBtZSBmb3IgcHJvcG9zaW5nIGFuIGlkZWEgdGhhdCBJIGJlbGlldmUg d2UgY2FuIA0KZW5naW5lZXJlZCB0byBiZSAidG9vIHNpbXBsZSB0byBmYWlsIi4gDQoNCkknbSBs b29raW5nIGZvcndhcmQgdG8gaGVhciBzY2VuYXJpb3Mgd2hlcmUgdGhpcyB3b3VsZCBsZWFkIHRv IGEgDQpzaWduaWZpY2FudCBmYWlsdXJlLiANCklmIHRoZXNlIHNjZW5hcmlvcyBkbyBleGlzdCBh bmQgaGF2ZSBhIHNpZ25pZmljYW50IGNoYW5jZSBvZiBoYXBwZW5pbmcgDQppbiBhIGNvcnJlY3Rs eSBjb25maWd1cmVkIG5ldHdvcmssIHRoZW4gdGhlICJzaW1wbGUtc3Vuc2V0IiBpZGVhIHNob3Vs ZCBiZSANCnJldHJhY3RlZCwgSSBhZ3JlZS4gDQoNCi9KRg0KDQoNCg0KDQoNCg0KDQoNCg== --=_alternative 0058CDE3852579F3_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBNYXJrLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQW5kIHRoZXJlIGlzIG5vdGhpbmcgc3RvcHBpbmcgeW91IGZy b20gdG9nZ2xpbmcNCnlvdXIgdXNlcnMgd2l0aCB0aGUgbW9kZWwgd2UgaGF2ZSBkZXNjcmliZWQu ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QWdyZWVkLCBi dXQgdGhpcyBpcyBub3QgbXkgcG9pbnQuIE15IHBvaW50IGlzIHRoYXQNCmludHJvZHVjaW5nIG11 bHRpaG9taW5nIGluICdiaXMnIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+YmFz ZWQgb24gNlJEIHN1bnNldHRpbmcgcmVxdWlyZW1lbnRzIGlzIHZlcnkgbGlrZWx5DQp0byBzbG93 IGRvd24gaW1wbGVtZW50ZXJzLiBXaGV0aGVyIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+dGhpcyBzbG93ZG93biBpcyB0YW5naWJsZSBvciBub3QgcmVtYWlucyB0byBiZSBjb25m aXJtZWQsDQpidXQgYSBub24tZW1wdHkgZ3JvdXAgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5vZiBjb25jZXJuZWQgb3BlcmF0b3JzIGRlZmluaXRlbHkgZXhpc3RzIGhlcmUuIDwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBCdXQsIGlmIHlvdSBo YXBwZW4gdG8gYmUgYW4gb3BlcmF0b3Igd2l0aCBubw0KYWJpbGl0eSB0byBjb250cm9sIHlvdXIg Q1BFLCBvciB0byBkZXRlY3QgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IHdoZXRoZXIgdGhlIENQRSBjb25uZWN0ZWQgaXMgaGFzIG9ubHkgNnJkIG9yDQpuYXRpdmUgKG9y IGlmIHRoZXJlIGlzIGEgbG9jYWwgc3dpdGNoIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBvbiB0aGUgQ1BFLCB3aGF0IHBvc2l0aW9uIGl0IGlzIGluKSwgdGhlcmUgaXMN CmEgcHJvYmxlbS4gJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5Xb3VsZCB5b3UgYmUga2luZCBlbm91Z2ggdG8gcG9pbnQgYSBzY2VuYXJpbyB3aGVyZQ0KdGhp cyBpcyBhbnkgbW9yZSBkYW5nZXJvdXMgdGhhbiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPmhhdmluZyB0aGUgdXNlciBjaG9vc2luZyAmcXVvdDs2UkQmcXVvdDsgc3RhdGljYWxs eQ0KZnJvbSBhIGRyb3AtZG93biBtZW51PyBUaGlzIGlzIHdoYXQgd2UgPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5oYXZlIG5vdyBhbmQgdGhlcmUgYXJlIGNlcnRhaW5seSBob21l IHVzZXJzIHdobyBzdGljaw0KdG8gNlJEIGV2ZW4gaWYgbmF0aXZlIGlzIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+YXZhaWxhYmxlIGJlY2F1c2UgdGhleSdyZSBub3QgYXdhcmUg aXQncyB0aGVyZS4gVGhpcw0KaXMgd2h5ICdiaXMnIGhhcyB0byA8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPmJlIHB1Ymxpc2hlZCBBU0FQIHdpdGggcmVxdWlyZW1lbnRzIHRoYXQg Y2FuIGJlIG1ldA0Kb24gYSBzaG9ydCB0aW1lZnJhbWUuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBXaGF0IHdlIGRvbid0IHdhbnQgdG8gZGV2ZWxvcCBpcyBz b21ldGhpbmcgdGhhdA0Kd2lsbCB3b3JrIG9uIG9uZSBuZXR3b3JrIHdoZW4gPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHNldCBpbiBvbmUgbW9kZSwgYW5kIGFub3RoZXIg bmV0d29yayBvbmx5IHdoZW4NCnNldCBpbiBhbm90aGVyIG1vZGUuIDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+QWdyZWVkLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgV2UgZG9uJ3QgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IHdhbnQgdG8gY2FyZSB3aGF0IG5ldHdvcmsgd2UgYXJlIGNvbm5lY3RlZCB0by4NCldl IHdhbnQgdG8gbGV0IHRoZSBJU1Agc2VuZCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgd2hhdGV2ZXIgY29uZmlndXJhdGlvbiBpdCB3YW50cywgaW4gd2hhdGV2ZXINCm9y ZGVyIGl0IHdhbnRzLCBhbmQgd2UnbGwgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IG1ha2UgaXQgd29yayByYXRoZXIgdGhhbiB0cnlpbmcgdG8gZ3Vlc3Mgd2hhdA0KeW91 IGFyZSB0cnlpbmcgdG8gZG8gLS0gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IG9yLCBmb3JjZSBvdXIgaG9tZS11c2VyIGN1c3RvbWVycyB0byBzdGVwIHRocm91Z2gNCnNv bWUgbWFudWFsIGNvbmZpZ3VyYXRpb24gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IHByb2Nlc3PigKYgJnF1b3Q7Q2hlY2sgd2l0aCB5b3VyIE9wZXJhdG9yIHRvIHNlZQ0K aWYgdGhleSBhcmUgYSA2cmQgb3IgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IE5hdGl2ZSBJUHY2IG9wZXJhdG9yIGFuZCBzZXQgdGhpcyB2YWx1ZSBhY2NvcmRpbmdseSZx dW90Ow0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5BZ3JlZWQuIDwvZm9udD48 L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGUgJnF1b3Q7UG9vciBtYW4n cyA2cmQgc3Vuc2V0dGluZyZxdW90OyB5b3UNCnJlZmVyIHRvIGlzIHdoYXQgSSBjYWxsZWQgPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZxdW90O2ZvcmNlZCBzaW5nbGUt aG9taW5nJnF1b3Q7IGluIHRoZSBwcmVzZW50YXRpb24uDQpUaGlzIGlzIGJlZ2dpbmcgZm9yIGEg cmFjZS1jb25kaXRpb24gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGlz c3VlIHRvIGNyb3AgdXAsIHRpZXMgdG9nZXRoZXIgdGhlIHY0IGFuZCB2Ng0Kc3RhdGUgbWFjaGlu ZXMsIGFuZCBlbGltaW5hdGVzIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyB0aGUgYWJpbGl0eSB0byB0cmFuc2l0aW9uIGEgdXNlciB3aXRob3V0IHJlbnVtYmVyaW5nLg0K PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIHVuZGVyc3RhbmQgeW91 ciBwb2ludCwgYnV0IGFnYWluLCBJIGJlbGlldmUgdGhpcw0Kc3RhdGUgbWFjaGluZSBjYW4gYmUg bWFkZSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnNvIHNpbXBsZSB0aGF0IEkg c2ltcGx5IGRvbid0IGZvcmVzZWUgYSBzY2VuYXJpbyB3aGVyZQ0KaXQgY291bGQgZmFpbC4gQW5k IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+eWVzIHlvdSBjYW4gcXVvdGUgbWUg Zm9yIHByb3Bvc2luZyBhbiBpZGVhIHRoYXQgSQ0KYmVsaWV2ZSB3ZSBjYW4gZW5naW5lZXJlZCB0 byBiZSAmcXVvdDt0b28gc2ltcGxlIHRvIGZhaWwmcXVvdDsuIDwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+SSdtIGxvb2tpbmcgZm9yd2FyZCB0byBoZWFyIHNjZW5hcmlv cyB3aGVyZSB0aGlzIHdvdWxkDQpsZWFkIHRvIGEgc2lnbmlmaWNhbnQgZmFpbHVyZS4gPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JZiB0aGVzZSBzY2VuYXJpb3MgZG8gZXhpc3Qg YW5kIGhhdmUgYSBzaWduaWZpY2FudA0KY2hhbmNlIG9mIGhhcHBlbmluZyA8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPmluIGEgY29ycmVjdGx5IGNvbmZpZ3VyZWQgbmV0d29yaywg dGhlbiB0aGUgJnF1b3Q7c2ltcGxlLXN1bnNldCZxdW90Ow0KaWRlYSBzaG91bGQgYmUgcmV0cmFj dGVkLCBJIGFncmVlLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPi9K RjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0K --=_alternative 0058CDE3852579F3_=-- From jason.weil@twcable.com Thu May 3 09:25:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C259B21F85B7 for ; Thu, 3 May 2012 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.082 X-Spam-Level: * X-Spam-Status: No, score=1.082 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MANGLED_MARKET=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IFRh-cpDc7U for ; Thu, 3 May 2012 09:25:38 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 244F921F85A3 for ; Thu, 3 May 2012 09:25:38 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,524,1330923600"; d="scan'208";a="359556010" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 May 2012 12:24:33 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 3 May 2012 12:25:37 -0400 From: "Weil, Jason" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Mark Townsley Date: Thu, 3 May 2012 12:25:34 -0400 Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: Ac0pSV9jEVy4EefGQymD+E/BSXuIEw== Message-ID: In-Reply-To: <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 16:25:38 -0000 How does source address verification come into play in this picture? For those brave enough to try this, my understanding of the use case is to offer 6rd and native IPv6 on the same WAN interface terminating at the same edge router. You will have both the native IPv6 prefix and the IPv4 prefix for the 6rd tunnel configured on the edge router's interface. I am not seeing how you would trigger any source verification drops in this scenario. I also believe the use of multihoming in this text is way too liberal for this section. Multihoming to a single edge router !=3D Multihoming to 2 edge routers !=3D Multihoming to two providers. We need to be more specific in our multihoming definitions. On 5/3/12 3:15 AM, "Ole Tr=F8an" wrote: >Mark, et, al, > >[...] > >> 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to be >>active alone as well as simultaneously in order to support coexistence >>of the two technologies during an incremental migration period from 6rd >>to native IPv6. >> >> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be >>directed such that its source IP address is derived from the delegated >>prefix associated with the upstream network the WAN interface is >>connected to [Section 4.3 [RFC3704]]. >> >> 6RD-6: The CE router MUST allow different as well as identical >>delegated prefixes to be configured via each (6rd or native) WAN >>interface. >> >> 6RD-7: In the event that forwarding rules produce a tie between 6rd >>and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. > >I have a few nitpicks with the language above. e.g. the use of "derived". >I'll send those privately. generally I'm OK with the above. > >I think adding these paragraphs in the section introduction, would set >the context for these >requirements better: > > A multihomed, multiprefix, IPv6 CE router has multiple WAN interfaces > connecting it to one or more Service Providers. The interfaces may > be "real" or "virtual" in the case of tunneling technology such as > 6rd [RFC5969]. The CE router receives one or more delegated > prefixes, each associated with one or more WAN interfaces. > > WAN interfaces are used to send Ingress traffic from the Internet to > the End-User, and Egress traffic from the End-User network to the > Internet. Ingress traffic may be received on any active interface at > any time. Egress traffic follows a set of rules within the CE in > order to choose the proper WAN interface. This is important not only > in order to choose the best path, but also because the networks that > the CE are connected to typically employ source address verification > mechanisms. > > Packets arriving at the CE have an IPv6 source address chosen by the > host [RFC3484]. The CE router performs source address dependent >routing (SAD), > such that the egress WAN interface is chosen based on the packet's >source > address matching the delegated prefix associate with the egress WAN > interface. > > >cheers, >Ole > >_______________________________________________ >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 Jean-Francois.TremblayING@videotron.com Thu May 3 09:30:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE8C21F8639 for ; Thu, 3 May 2012 09:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVidyZU1nznQ for ; Thu, 3 May 2012 09:30:09 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD7021F8636 for ; Thu, 3 May 2012 09:30:09 -0700 (PDT) In-Reply-To: <04A5E500-9228-41D2-9B30-C8FA8D53B3B7@townsley.net> To: mark@townsley.net MIME-Version: 1.0 X-KeepSent: 83A99EE4:8BDCDEDC-852579F3:0058D3E4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 3 May 2012 12:30:00 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/03/2012 12:30:08, Serialize complete at 05/03/2012 12:30:08 Content-Type: multipart/alternative; boundary="=_alternative 005AA662852579F3_=" Received-SPF: none Cc: Claire_Cheng@dlink.com.tw, IPv6 Operations , Hans_Liu@dlink.com.tw Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 16:30:10 -0000 Message en plusieurs parties au format MIME --=_alternative 005AA662852579F3_= Content-Type: text/plain; charset="US-ASCII" Mark, Hans stated that multihoming is possible and he'll be willing to do it if there's a strong requirement from his client. Not that it's easy or feasible within a reasonable timeframe. And we definitely have some history when it comes to IPv6 implementations timeframes: http://www.videotron.com/service/internet-services/internet-access/wifi-router Features: IPv6-compatible John B. and others people on this list who work actively on deploying IPv6 also have their stories. It all boils down to the fact complexity costs deployment time. By keeping complexity down, we can hope to have better IPv6 in home routers within a reasonable timeframe. Multihoming in 'bis' is undue complexity IMHO. /JF > basically 6rd has to wait for IPv4 to be provisioned, and IPv4 has to wait > for IPv6 to be provisioned (to determine if it should do DS-lite for IPv4 or not). > I claim this is more complicated than simply specifying how they can operate > independently of each other. > Ole Agreed. But I claim the "alternate-on" approach, even given timers and a proper (small) state machine is less complex for an implementer to put together than introducing multihoming at this point. I would love to hear from implementers such as Hans on this. Begin forwarded message: From: Hans Liu Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) Date: May 1, 2012 12:27:47 AM GMT+02:00 To: Mark Townsley Cc: IPv6 Operations , Claire Cheng < claire_cheng@dlink.com.tw> It looks like a lot of discussions were going on last week during my absence. I'm good with the idea in general while I believe Mark and Chris are working on the text. If a operator chooses to provision both 6rd and native IPv6, a CE router needs to have the capability to support them simultaneously. In terms, CPE has the capability while operators have the privilege whether they would like to do that in their networks. And I will implement the requirements in boxes of my company. --=_alternative 005AA662852579F3_= Content-Type: text/html; charset="US-ASCII"
Mark,
Hans stated that multihoming is possible and he'll be willing
to do it if there's a strong requirement from his client. Not that
it's easy or feasible within a reasonable timeframe.  

And we definitely have some history when it comes to IPv6 implementations timeframes:  
http://www.videotron.com/service/internet-services/internet-access/wifi-router
Features:
    IPv6-compatible

John B. and others people on this list who work actively on deploying IPv6 also
have their stories. It all boils down to the fact complexity costs deployment time.
By keeping complexity down, we can hope to have better IPv6 in home routers within
a reasonable timeframe. Multihoming in 'bis' is undue complexity IMHO.

/JF



> basically 6rd has to wait for IPv4 to be provisioned, and IPv4 has to wait
> for IPv6 to be provisioned (to determine if it should do DS-lite for IPv4 or not).
> I claim this is more complicated than simply specifying how they can operate
> independently of each other.
> Ole

Agreed. But I claim the "alternate-on" approach, even given timers and a proper
(small) state machine is less complex for an implementer to put together
than introducing multihoming at this point. I would love to hear from
implementers such as Hans on this.

Begin forwarded message:

From: Hans Liu <hansliu@gmail.com>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 2)
Date: May 1, 2012 12:27:47 AM GMT+02:00
To: Mark Townsley <mark@townsley.net>
Cc: IPv6 Operations <v6ops@ietf.org>, Claire Cheng <claire_cheng@dlink.com.tw>

It looks like a lot of discussions were going on last week during my absence.
I'm good with the idea in general while I believe Mark and Chris are
working on the text.
If a operator chooses to provision both 6rd and native IPv6, a CE
router needs to have the capability to support them simultaneously. In
terms, CPE has the capability while operators have the privilege
whether they would like to do that in their networks. And I will
implement the requirements in boxes of my company.
--=_alternative 005AA662852579F3_=-- From bs7652@att.com Thu May 3 09:48:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646FB21F8622 for ; Thu, 3 May 2012 09:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.656 X-Spam-Level: X-Spam-Status: No, score=-105.656 tagged_above=-999 required=5 tests=[AWL=0.943, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bARaQ4r49Nc9 for ; Thu, 3 May 2012 09:48:15 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id B009721F861C for ; Thu, 3 May 2012 09:48:14 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id ec6b2af4.0.1141776.00-494.3161222.nbfkord-smmo04.seg.att.com (envelope-from ); Thu, 03 May 2012 16:48:14 +0000 (UTC) X-MXL-Hash: 4fa2b6ce3bd71141-274219f3d8d36410925866de40e865db4171ecfd 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 q43GmD4P013632; Thu, 3 May 2012 12:48:14 -0400 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 q43Gm5Fp013297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 12:48:08 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint03.pst.cso.att.com (RSA Interceptor); Thu, 3 May 2012 12:47:53 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.81]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.01.0355.002; Thu, 3 May 2012 12:47:53 -0400 From: "STARK, BARBARA H" To: Simon Perreault , "v6ops@ietf.org" Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNKPSFHaTi59li002JhDEAyFznTpa36hwAgAAeRwCAAAKugIAAVn0AgAAG8ACAAASigP//1LVg Date: Thu, 3 May 2012 16:47:52 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <4FA29E69.1040304@viagenie.ca> In-Reply-To: <4FA29E69.1040304@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.63.21] 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-RSA-Action: allow 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=1.0 c=1 a=FBOW6tpZRsYA:10 a=KJxBHbnaG1YA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=MAkyDe20cb969njikusA:9 a=Csv70a8CIQ5LEeVQK] X-AnalysisOut: [d4A:7 a=CjuIK1q_8ugA:10] Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 16:48:15 -0000 > Why not unconditionally ask for option 212 and only activate the 6RD > interface after DHCPv6 fails? Not all 6rd will be configured via option 212. On PPPoE, we're configuring = our routers through TR-069, and have requested retail CE routers that do PP= PoE and 6rd support manual entry of 6rd config parameters (6204bis 6RD-2). But as I've said, we have no problem toggling native IPv6 and 6rd in our TR= -069 managed routers, and have no objection to having the user manually tog= gle in CE routers where they have manually configured 6rd. So I'm not oppos= ed to the sentiment expressed, I would just want to be careful to make sure= that we appropriately define behavior for devices not configured through o= ption 212. Barbara From simon.perreault@viagenie.ca Thu May 3 09:54:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1737521F862F for ; Thu, 3 May 2012 09:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJMenSjGsBIu for ; Thu, 3 May 2012 09:54:18 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7249721F8534 for ; Thu, 3 May 2012 09:54:18 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:fd74:94dc:fbc7:7264]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DC8444157F; Thu, 3 May 2012 12:54:17 -0400 (EDT) Message-ID: <4FA2B838.6000703@viagenie.ca> Date: Thu, 03 May 2012 12:54:16 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "STARK, BARBARA H" References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 16:54:19 -0000 On 2012-05-03 12:47, STARK, BARBARA H wrote: >> Why not unconditionally ask for option 212 and only activate the 6RD >> interface after DHCPv6 fails? > > Not all 6rd will be configured via option 212. On PPPoE, we're configuring our routers through TR-069, and have requested retail CE routers that do PPPoE and 6rd support manual entry of 6rd config parameters (6204bis 6RD-2). Right. Then the algorithm becomes something like this: 1. If the CPE has no 6rd config (either static config or from TR-69) then do a DHCPv4 request with option 212. 2. Do a DHCPv6 request. 3. If the DHCPv6 request fails, wait until we have 6rd config, then bring up the 6rd interface. > But as I've said, we have no problem toggling native IPv6 and 6rd in our TR-069 managed routers, and have no objection to having the user manually toggle in CE routers where they have manually configured 6rd. So I'm not opposed to the sentiment expressed, I would just want to be careful to make sure that we appropriately define behavior for devices not configured through option 212. Absolutely. And TR-69 will be used alongside option 212 in some deployments too. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From gert@space.net Thu May 3 10:29:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7938D21F8628 for ; Thu, 3 May 2012 10:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCHoYcrgzD-y for ; Thu, 3 May 2012 10:29:40 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id A601621F85FC for ; Thu, 3 May 2012 10:29:38 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B87E9F8AEC for ; Thu, 3 May 2012 19:29:37 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 96D89F8AE2 for ; Thu, 3 May 2012 19:29:37 +0200 (CEST) Received: (qmail 9320 invoked by uid 1007); 3 May 2012 19:29:37 +0200 Date: Thu, 3 May 2012 19:29:37 +0200 From: Gert Doering To: "Weil, Jason" Message-ID: <20120503172937.GM84425@Space.Net> References: <78B75F49-56D1-4269-A250-AA872AB6C4B2@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 17:29:40 -0000 Hi, On Thu, May 03, 2012 at 12:25:34PM -0400, Weil, Jason wrote: > How does source address verification come into play in this picture? For > those brave enough to try this, my understanding of the use case is to > offer 6rd and native IPv6 on the same WAN interface terminating at the > same edge router. You will have both the native IPv6 prefix and the IPv4 > prefix for the 6rd tunnel configured on the edge router's interface. I am > not seeing how you would trigger any source verification drops in this > scenario. This has been explained a number of times on this list. Typically, the 6rd and the "regular" ISP PE router are not the same box, and the "regular" PE router does not know anything about the 6rd addresses on the client. BCP38 strongly recommends to do source address verification - this is typically implemented similar to Cisco's "uRPF", as in "the PE router will accept packets with a source address only if it would route that source address to *this* customer". Since the "WAN" PE doesn't *know* about the 6rd prefix at this customer site, it will automatically drop all packets sourced from 6rd-derived addresses if those arrive on the "regular WAN" link. (Someone stated that we're ratholing. And indeed we are, if questions are asked again that have been answered and discused quite in depth months ago already. And where those answers are really obvious to anyone who bothered to fully think through an ISP deployment with 6rd and native IPv6, and BCP38 deployed). > I also believe the use of multihoming in this text is way too liberal for > this section. > > Multihoming to a single edge router != Multihoming to 2 edge routers != > Multihoming to two providers. We need to be more specific in our > multihoming definitions. The specific style of multihoming is fully irrelevant to the text bits proposed by Mark and Ole (and applies to all of them). This is not about defining multihoming, but about a few specific caveats that will show up as soon as you have more than one "WAN-style" interface. Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jason.weil@twcable.com Thu May 3 14:04:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE79721F86B0 for ; Thu, 3 May 2012 14:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.309 X-Spam-Level: X-Spam-Status: No, score=0.309 tagged_above=-999 required=5 tests=[AWL=0.773, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjTxs2cJybSj for ; Thu, 3 May 2012 14:04:16 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA4F21F86B1 for ; Thu, 3 May 2012 14:04:16 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,526,1330923600"; d="scan'208";a="359734651" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 May 2012 17:03:11 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 3 May 2012 17:04:15 -0400 From: "Weil, Jason" To: Gert Doering Date: Thu, 3 May 2012 17:04:12 -0400 Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: Ac0pcEuG/HUB3oYTQGS7ldkhTWEoaQ== Message-ID: In-Reply-To: <20120503172937.GM84425@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 21:04:18 -0000 I guess I need to 2nd Ray's comment. What you are describing now (and apparently I have filtered due to complexity filter) is a variant of the Two ISP, One CER topology from the Homene-archictecture draft but what the current draft bis describes is a single Service Provider router topology. I fail to see how this falls in scope of the current draft and seems more in-line with Homenet problem statements. 3.1.3 . C: Two ISPs, One CER, Shared subnet +-------+-------+ +-------+-------+ \ | Service | | Service | \ | Provider A | | Provider B | | Service | Router | | Router | | Provider +-------+-------+ +-------+-------+ | network | | / | Customer | / | Internet | / | connections | | +---------+---------+ \ | IPv6 | \ | Customer Edge | \ | Router | / +---------+---------+ / | / | | End-User ---+------------+-------+--------+-------------+--- | network(s) | | | | \ +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / | | | | | | | | / +----------+ +----------+ +----------+ +----------+ What is in the 6204bis draft is this: http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08#section-3.2 The end-user network is a stub network. Figure 1 illustrates the model topology for the end-user network. +-------+-------+ \ | Service | \ | Provider | | Service | Router | | Provider +-------+-------+ | network | / | Customer / | Internet connection / | +------+--------+ \ | IPv6 | \ | Customer Edge | \ | Router | / +---+-------+-+-+ / Network A | | Network B | End-User ---+-------------+----+- --+--+-------------+--- | network(s) | | | | \ +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / | | | | | | | | / +----------+ +-----+----+ +----------+ +----------+ / Jason On 5/3/12 1:29 PM, "Gert Doering" wrote: >Hi, > >On Thu, May 03, 2012 at 12:25:34PM -0400, Weil, Jason wrote: >> How does source address verification come into play in this picture? For >> those brave enough to try this, my understanding of the use case is to >> offer 6rd and native IPv6 on the same WAN interface terminating at the >> same edge router. You will have both the native IPv6 prefix and the IPv4 >> prefix for the 6rd tunnel configured on the edge router's interface. I >>am >> not seeing how you would trigger any source verification drops in this >> scenario. > >This has been explained a number of times on this list. > >Typically, the 6rd and the "regular" ISP PE router are not the same box, >and the "regular" PE router does not know anything about the 6rd addresses >on the client. > >BCP38 strongly recommends to do source address verification - this is >typically implemented similar to Cisco's "uRPF", as in "the PE router >will accept packets with a source address only if it would route that >source address to *this* customer". > >Since the "WAN" PE doesn't *know* about the 6rd prefix at this customer >site, it will automatically drop all packets sourced from 6rd-derived >addresses if those arrive on the "regular WAN" link. > >(Someone stated that we're ratholing. And indeed we are, if questions >are asked again that have been answered and discused quite in depth >months ago already. And where those answers are really obvious to >anyone who bothered to fully think through an ISP deployment with 6rd >and native IPv6, and BCP38 deployed). > >> I also believe the use of multihoming in this text is way too liberal >>for >> this section. >> >> Multihoming to a single edge router !=3D Multihoming to 2 edge routers != =3D >> Multihoming to two providers. We need to be more specific in our >> multihoming definitions. > >The specific style of multihoming is fully irrelevant to the text bits >proposed by Mark and Ole (and applies to all of them). This is not about >defining multihoming, but about a few specific caveats that will show >up as soon as you have more than one "WAN-style" interface. > >Gert Doering > -- Operator >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 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 mark@townsley.net Thu May 3 15:34:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20E421F8720 for ; Thu, 3 May 2012 15:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1QqvSJ2Z2Zk for ; Thu, 3 May 2012 15:34:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1C321F870F for ; Thu, 3 May 2012 15:34:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKoGo0+Q/khM/2dsb2JhbABFsn2BB4IJAQEBAwESAWYFCwtGVxkih2YFmk6gFpAlYwSkV4Fpgmo X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208,217";a="136990998" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 May 2012 22:34:26 +0000 Received: from ams-townsley-8914.cisco.com (ams-townsley-8914.cisco.com [10.55.23.165]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q43MYOmG004367; Thu, 3 May 2012 22:34:25 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_4A4EBD7F-C699-42CF-816F-83C9EE9471F8" From: Mark Townsley In-Reply-To: Date: Fri, 4 May 2012 00:34:25 +0200 Message-Id: <5775A2A3-BCC5-4700-AC2D-0297B8B9C058@townsley.net> References: To: Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 22:34:28 -0000 --Apple-Mail=_4A4EBD7F-C699-42CF-816F-83C9EE9471F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 3, 2012, at 6:09 PM, Jean-Francois.TremblayING@videotron.com = wrote: >=20 > Hi Mark.=20 >=20 > > And there is nothing stopping you from toggling your users with the = model we have described. =20 >=20 > Agreed, but this is not my point. My point is that introducing = multihoming in 'bis'=20 > based on 6RD sunsetting requirements is very likely to slow down = implementers. Whether=20 > this slowdown is tangible or not remains to be confirmed, but a = non-empty group=20 > of concerned operators definitely exists here.=20 6rd began appearing in CPE with RFC 5969. It didn't need v6ops to become = fairly widely deployed already, and CPE vendors have either implemented = it, or made a conscious decision to not to, by now. I don't see how = RFC-6204 bis is going to speed that up or slow it down. 6rd is not even = a MUST in 6204-bis.=20 What is new in 6204-bis is a set of Native IPv6 requirements (that are = indeed MUSTs) and 6rd mentioned together. I think it is incumbent upon = us to make sure that the two work well together, and put us on a path = towards moving to native IPv6 with as few barriers as possible. Remove = this, and the delta between the status quo and -bis gets pretty darn = small.=20 - Mark >=20 > > But, if you happen to be an operator with no ability to control your = CPE, or to detect=20 > > whether the CPE connected is has only 6rd or native (or if there is = a local switch=20 > > on the CPE, what position it is in), there is a problem. =20 >=20 > Would you be kind enough to point a scenario where this is any more = dangerous than=20 > having the user choosing "6RD" statically from a drop-down menu? This = is what we=20 > have now and there are certainly home users who stick to 6RD even if = native is=20 > available because they're not aware it's there. This is why 'bis' has = to=20 > be published ASAP with requirements that can be met on a short = timeframe.=20 >=20 > > What we don't want to develop is something that will work on one = network when=20 > > set in one mode, and another network only when set in another mode.=20= > Agreed.=20 >=20 > > We don't=20 > > want to care what network we are connected to. We want to let the = ISP send=20 > > whatever configuration it wants, in whatever order it wants, and = we'll=20 > > make it work rather than trying to guess what you are trying to do = --=20 > > or, force our home-user customers to step through some manual = configuration=20 > > process=85 "Check with your Operator to see if they are a 6rd or=20 > > Native IPv6 operator and set this value accordingly"=20 > Agreed.=20 >=20 > > The "Poor man's 6rd sunsetting" you refer to is what I called=20 > > "forced single-homing" in the presentation. This is begging for a = race-condition=20 > > issue to crop up, ties together the v4 and v6 state machines, and = eliminates=20 > > the ability to transition a user without renumbering.=20 >=20 > I understand your point, but again, I believe this state machine can = be made=20 > so simple that I simply don't foresee a scenario where it could fail. = And=20 > yes you can quote me for proposing an idea that I believe we can = engineered to be "too simple to fail".=20 >=20 > I'm looking forward to hear scenarios where this would lead to a = significant failure.=20 > If these scenarios do exist and have a significant chance of happening=20= > in a correctly configured network, then the "simple-sunset" idea = should be retracted, I agree.=20 >=20 > /JF=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_4A4EBD7F-C699-42CF-816F-83C9EE9471F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Jean-Francois.Trem= blayING@videotron.com wrote:

Hi Mark.

> And there is nothing stopping you from = toggling your users with the model we have described.  

Agreed, but this is not my point. My point is = that introducing multihoming in 'bis'
based on 6RD sunsetting requirements is very = likely to slow down implementers. Whether
this slowdown is tangible or not remains to be = confirmed, but a non-empty group
of concerned operators definitely exists here. =

6rd began appearing in CPE with RFC = 5969. It didn't need v6ops to become fairly widely deployed already, and = CPE vendors have either implemented it, or made a conscious decision to = not to, by now. I don't see how RFC-6204 bis is going to speed that up = or slow it down. 6rd is not even a MUST in = 6204-bis. 

What is new in 6204-bis is a = set of Native IPv6 requirements (that are indeed MUSTs) and 6rd = mentioned together. I think it is incumbent upon us to make sure that = the two work well together, and put us on a path towards moving to = native IPv6 with as few barriers as possible. Remove this, and the delta = between the status quo and -bis gets pretty darn = small. 

- = Mark


> But, if you happen to be an operator with = no ability to control your CPE, or to detect
> whether the CPE connected is has only 6rd = or native (or if there is a local switch
> on the CPE, what position it is in), there = is a problem.  

Would you be kind enough to point a scenario = where this is any more dangerous than
having the user choosing "6RD" statically from a drop-down menu? This is what we
have now and there are certainly home users who = stick to 6RD even if native is
available because they're not aware it's there. = This is why 'bis' has to
be published ASAP with requirements that can be = met on a short timeframe.

> What we don't want to develop is something = that will work on one network when
> set in one mode, and another network only = when set in another mode.
Agreed.

> We don't
> want to care what network we are connected = to. We want to let the ISP send
> whatever configuration it wants, in = whatever order it wants, and we'll
> make it work rather than trying to guess = what you are trying to do --
> or, force our home-user customers to step = through some manual configuration
> process=85 "Check with your Operator to = see if they are a 6rd or
> Native IPv6 operator and set this value = accordingly"
Agreed.

> The "Poor man's 6rd sunsetting" you refer to is what I called
> "forced single-homing" in the = presentation. This is begging for a race-condition
> issue to crop up, ties together the v4 and = v6 state machines, and eliminates
> the ability to transition a user without = renumbering.

I understand your point, but again, I believe = this state machine can be made
so simple that I simply don't foresee a = scenario where it could fail. And
yes you can quote me for proposing an idea that = I believe we can engineered to be "too simple to fail".

I'm looking forward to hear scenarios where = this would lead to a significant failure.
If these scenarios do exist and have a = significant chance of happening
in a correctly configured network, then the = "simple-sunset" idea should be retracted, I agree.

/JF








= --Apple-Mail=_4A4EBD7F-C699-42CF-816F-83C9EE9471F8-- From mark@townsley.net Thu May 3 15:48:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A1721F8733 for ; Thu, 3 May 2012 15:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiOrZirdKSVx for ; Thu, 3 May 2012 15:48:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4721F8731 for ; Thu, 3 May 2012 15:48:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAI4Ko0+Q/khL/2dsb2JhbABFsn2BB4IJAQEBAwEBAQEPARRHCwULCxguJzAGEyKHZgULmjygGosGhgIElw+NSIFpgmo X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208";a="72401525" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 May 2012 22:48:02 +0000 Received: from ams-townsley-8914.cisco.com (ams-townsley-8914.cisco.com [10.55.23.165]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q43Mm2dX012309; Thu, 3 May 2012 22:48:02 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Mark Townsley In-Reply-To: <4FA2B838.6000703@viagenie.ca> Date: Fri, 4 May 2012 00:48:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1257) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 22:48:04 -0000 On May 3, 2012, at 6:54 PM, Simon Perreault wrote: > On 2012-05-03 12:47, STARK, BARBARA H wrote: >>> Why not unconditionally ask for option 212 and only activate the 6RD >>> interface after DHCPv6 fails? >>=20 >> Not all 6rd will be configured via option 212. On PPPoE, we're = configuring our routers through TR-069, and have requested retail CE = routers that do PPPoE and 6rd support manual entry of 6rd config = parameters (6204bis 6RD-2). >=20 > Right. Then the algorithm becomes something like this: >=20 > 1. If the CPE has no 6rd config (either static config or from TR-69) = then do a DHCPv4 request with option 212. Except TR-69 doesn't operate without IP, which means DHCPv4 (or is it = DHCPv6?) goes first of course. >=20 > 2. Do a DHCPv6 request. >=20 > 3. If the DHCPv6 request fails, wait until we have 6rd config, then = bring up the 6rd interface. How long do you wait for DHCPv6 to fail before you bring up 6rd? 15 = seconds? 30? A minute? Would my 6rd-provider like that v6 bringup is = delayed by that long for *all* their users?=20 Do we really want v6 to take a minute longer to come up than v4? I = honestly had a power breaker flip just today (two, actually) - the DSL = gateway came back pretty quickly, the VPN router took quite a bit = longer.. .I was not at all happy with the VPN router. =20 We've even had operators say on this list that they want to have the = alternative to move from v6 back to 6rd, so perhaps the order of your = state machine should be reversed?=20 Bottom line: you probably are not going to agree on what to do here, and = as a retail CPE vendor, I want to be sure that what comes out works with = all operational cases, and without bugging the users for config (even if = you tell me it is OK to have manual config for your customers, that's = not OK for me as a CPE vendor).=20 What Ole and I proposed, defended in Paris, and have been asked by the = chairs to formulate simple requirements for, is the only option that = hits *all* cases you can throw at the problem=85 and, it's really not as = hard as it sounds to make happen. RFC 3704 has been around since 2004, = let's not pretend it is rocket science today.=20 - Mark >=20 >> But as I've said, we have no problem toggling native IPv6 and 6rd in = our TR-069 managed routers, and have no objection to having the user = manually toggle in CE routers where they have manually configured 6rd. = So I'm not opposed to the sentiment expressed, I would just want to be = careful to make sure that we appropriately define behavior for devices = not configured through option 212. >=20 > Absolutely. And TR-69 will be used alongside option 212 in some = deployments too. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Thu May 3 15:54:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F5E21F8744 for ; Thu, 3 May 2012 15:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUy+79bSu124 for ; Thu, 3 May 2012 15:54:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC9E21F8743 for ; Thu, 3 May 2012 15:54:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADwLo0+Q/khN/2dsb2JhbABFsn2BB4IJAQEBAwESAV8HBQsLEgYuSQ4GEyKHZgULmjygG4sFhSBjBJcPjUiBaYJqgVo X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208";a="136991624" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 May 2012 22:54:25 +0000 Received: from ams-townsley-8914.cisco.com (ams-townsley-8914.cisco.com [10.55.23.165]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q43MsPch018892; Thu, 3 May 2012 22:54:25 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: Date: Fri, 4 May 2012 00:54:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4348CF9E-3965-4E17-AC6E-130BB3032693@townsley.net> References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2012 22:54:28 -0000 On May 3, 2012, at 11:04 PM, Weil, Jason wrote: > I guess I need to 2nd Ray's comment. What you are describing now (and > apparently I have filtered due to complexity filter) is a variant of = the > Two ISP, One CER topology from the Homene-archictecture draft but what = the > current draft bis describes is a single Service Provider router = topology. > I fail to see how this falls in scope of the current draft and seems = more > in-line with Homenet problem statements. When we divided up the work between homenet and v6ops, v6ops kept the = "WAN" side, hence why it lands here and now Homenet scope doesn't = include, for example, 6rd, DS-Lite, etc. at all. Your observation that = what we are proposing is in line with the homenet architecture is = correct, and I'd hope that is considered a good thing.=20 - Mark=20 >=20 > 3.1.3 > . = C: > Two ISPs, One CER, Shared subnet >=20 >=20 > +-------+-------+ +-------+-------+ \ > | Service | | Service | \ > | Provider A | | Provider B | | Service > | Router | | Router | | Provider > +-------+-------+ +-------+-------+ | network > | | / > | Customer | / > | Internet | / > | connections | | > +---------+---------+ \ > | IPv6 | \ > | Customer Edge | \ > | Router | / > +---------+---------+ / > | / > | | End-User > ---+------------+-------+--------+-------------+--- | network(s) > | | | | \ > +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ > |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / > | | | | | | | | / > +----------+ +----------+ +----------+ +----------+ >=20 >=20 >=20 >=20 > What is in the 6204bis draft is this: > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08#section-3.2 >=20 >=20 > The end-user network is a stub network. Figure 1 illustrates the > model topology for the end-user network. >=20 > +-------+-------+ \ > | Service | \ > | Provider | | Service > | Router | | = Provider > +-------+-------+ | network > | / > | Customer / > | Internet connection / > | > +------+--------+ \ > | IPv6 | \ > | Customer Edge | \ > | Router | / > +---+-------+-+-+ / > Network A | | Network B | End-User > ---+-------------+----+- --+--+-------------+--- | network(s) > | | | | \ > +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ > |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / > | | | | | | | | / > +----------+ +-----+----+ +----------+ +----------+ / >=20 >=20 >=20 > Jason >=20 >=20 >=20 > On 5/3/12 1:29 PM, "Gert Doering" wrote: >=20 >> Hi, >>=20 >> On Thu, May 03, 2012 at 12:25:34PM -0400, Weil, Jason wrote: >>> How does source address verification come into play in this picture? = For >>> those brave enough to try this, my understanding of the use case is = to >>> offer 6rd and native IPv6 on the same WAN interface terminating at = the >>> same edge router. You will have both the native IPv6 prefix and the = IPv4 >>> prefix for the 6rd tunnel configured on the edge router's interface. = I >>> am >>> not seeing how you would trigger any source verification drops in = this >>> scenario. >>=20 >> This has been explained a number of times on this list. >>=20 >> Typically, the 6rd and the "regular" ISP PE router are not the same = box, >> and the "regular" PE router does not know anything about the 6rd = addresses >> on the client. >>=20 >> BCP38 strongly recommends to do source address verification - this is >> typically implemented similar to Cisco's "uRPF", as in "the PE router >> will accept packets with a source address only if it would route that >> source address to *this* customer". >>=20 >> Since the "WAN" PE doesn't *know* about the 6rd prefix at this = customer >> site, it will automatically drop all packets sourced from 6rd-derived >> addresses if those arrive on the "regular WAN" link. >>=20 >> (Someone stated that we're ratholing. And indeed we are, if = questions >> are asked again that have been answered and discused quite in depth >> months ago already. And where those answers are really obvious to >> anyone who bothered to fully think through an ISP deployment with 6rd >> and native IPv6, and BCP38 deployed). >>=20 >>> I also believe the use of multihoming in this text is way too = liberal >>> for >>> this section. >>>=20 >>> Multihoming to a single edge router !=3D Multihoming to 2 edge = routers !=3D >>> Multihoming to two providers. We need to be more specific in our >>> multihoming definitions. >>=20 >> The specific style of multihoming is fully irrelevant to the text = bits >> proposed by Mark and Ole (and applies to all of them). This is not = about >> defining multihoming, but about a few specific caveats that will show >> up as soon as you have more than one "WAN-style" interface. >>=20 >> Gert Doering >> -- Operator >> -- >> have you enabled IPv6 on something today...? >>=20 >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From fgont@si6networks.com Thu May 3 17:02:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C6021F864F for ; Thu, 3 May 2012 17:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg7fNjpXKD9c for ; Thu, 3 May 2012 17:02:52 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7191B21F8675 for ; Thu, 3 May 2012 17:02:52 -0700 (PDT) Received: from [2001:5c0:1400:a::149] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SQ5yr-0004YF-78; Fri, 04 May 2012 02:02:42 +0200 Message-ID: <4FA31C7F.1040601@si6networks.com> Date: Thu, 03 May 2012 21:02:07 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> <4FA22A2A.5080006@si6networks.com> <4FA26A73.9070001@inex.ie> In-Reply-To: <4FA26A73.9070001@inex.ie> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 00:02:53 -0000 On 05/03/2012 08:22 AM, Nick Hilliard wrote: > On 03/05/2012 07:48, Fernando Gont wrote: >> Regarding your suggestion to log dropped packets, do you have any >> proposed text to address it? > > yes, that would probably help. > > I'd drop the word "silently" from paragraphs 3.1, 3.2 and 3.3, because that > implies no logging. By "paragraphs" you mean the bullets corresponding to the filtering rules, right? > After paragraph 3.4, insert before "In order to protect current ...": > > -- > If a packet is dropped due to this filtering mechanism, then this packet > drop event SHOULD be logged. The logging mechanism SHOULD include a drop > counter dedicated to RA-Guard packet drops. Great. Will apply thi. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From hansliu@gmail.com Thu May 3 17:57:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE49521F86AB for ; Thu, 3 May 2012 17:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rfx1TvAGGTR for ; Thu, 3 May 2012 17:57:05 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B745421F86A8 for ; Thu, 3 May 2012 17:57:04 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1917953lbb.31 for ; Thu, 03 May 2012 17:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wm6CBzXLFQd8CrnSI3wBdw1YToAe4DFjRQ6rjxahbEo=; b=VR0z2znZ6Er/AqB6/61BCyzDsQK6cPSO3SY81ygH71eXYqx23xyvL7IyLFsjXEsZSA 7NRKVD4EqnVX7Gw+EydKCdZ78Its57KslgPrOXzo1mlr6whLOLHg9L/18d8m1OroSC9V 8dVeKcLXZY00xTQ2LUW1qDlWM3HZnyOsHiHmvot7j3kW2sS8IwzCopaCtzpcRFa9YKKd FSdxVPVJMBttmbHuPLOEAXVm5g33/Eyg7vPD6BBsCF0OHra4O8lvT2I9YNsNsmEzOi0x lDdw9M4eEAkw5e5tL2Qjb45XaoG7i6Fs5DMo96lG9JeyfIX0R3GNsmLzjxU7ER0zYmAO /4cQ== MIME-Version: 1.0 Received: by 10.152.110.116 with SMTP id hz20mr836170lab.33.1336093023698; Thu, 03 May 2012 17:57:03 -0700 (PDT) Received: by 10.112.43.8 with HTTP; Thu, 3 May 2012 17:57:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 May 2012 08:57:03 +0800 Message-ID: From: Hans Liu To: Jean-Francois.TremblayING@videotron.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Claire Cheng , IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 00:57:06 -0000 I don't normally speak my implementation in public, but let's do it! :P My current "AutoDetection" implementation supports 6rd (DHCPv4 Option 212) and native IPv6 (Autoconfiguration). It doesn't take multihoming into account but it is sort of taking care of the goal toward native IPv6. It starts IPv4 and IPv6 provisioning in parallel, and I expects that it ends up with a native dual stack. If both 6rd and native IPv6 are provisioned, it will only bring up native IPv6. The problem of it is above procedure only does once, when the device boots up. And the question will be if a power cycle or reboot is ok to everyone. I made a quick survey when I first designed above flow. It seems most people have pretty good sense (or are pretty well-educated) to power cycle their device when it doesn't work well. (I know I'm one of the blame for) For the sunset requirements we discussed here, I don't have much to share since I don't yet start my development. I will develop it when we have the final text, and I might be able to share more when I meet a problem during my development. Best regards, Hans On Fri, May 4, 2012 at 12:09 AM, wrote: > > Hi Mark. > >> And there is nothing stopping you from toggling your users with the mode= l >> we have described. > > Agreed, but this is not my point. My point is that introducing multihomin= g > in 'bis' > based on 6RD sunsetting requirements is very likely to slow down > implementers. Whether > this slowdown is tangible or not remains to be confirmed, but a non-empty > group > of concerned operators definitely exists here. > >> But, if you happen to be an operator with no ability to control your CPE= , >> or to detect >> whether the CPE connected is has only 6rd or native (or if there is a >> local switch >> on the CPE, what position it is in), there is a problem. > > Would you be kind enough to point a scenario where this is any more > dangerous than > having the user choosing "6RD" statically from a drop-down menu? This is > what we > have now and there are certainly home users who stick to 6RD even if nati= ve > is > available because they're not aware it's there. This is why 'bis' has to > be published ASAP with requirements that can be met on a short timeframe. > >> What we don't want to develop is something that will work on one network >> when >> set in one mode, and another network only when set in another mode. > Agreed. > >> We don't >> want to care what network we are connected to. We want to let the ISP se= nd >> whatever configuration it wants, in whatever order it wants, and we'll >> make it work rather than trying to guess what you are trying to do -- >> or, force our home-user customers to step through some manual >> configuration >> process=E2=80=A6 "Check with your Operator to see if they are a 6rd or >> Native IPv6 operator and set this value accordingly" > Agreed. > >> The "Poor man's 6rd sunsetting" you refer to is what I called >> "forced single-homing" in the presentation. This is begging for a >> race-condition >> issue to crop up, ties together the v4 and v6 state machines, and >> eliminates >> the ability to transition a user without renumbering. > > I understand your point, but again, I believe this state machine can be m= ade > so simple that I simply don't foresee a scenario where it could fail. And > yes you can quote me for proposing an idea that I believe we can engineer= ed > to be "too simple to fail". > > I'm looking forward to hear scenarios where this would lead to a signific= ant > failure. > If these scenarios do exist and have a significant chance of happening > in a correctly configured network, then the "simple-sunset" idea should b= e > retracted, I agree. > > /JF > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Instead of following the fashion, we lead it through. From farmer@umn.edu Thu May 3 18:05:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E470521F870F for ; Thu, 3 May 2012 18:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4w7ea+7lJnr for ; Thu, 3 May 2012 18:05:44 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEE621F870A for ; Thu, 3 May 2012 18:05:44 -0700 (PDT) Received: from mail-yw0-f43.google.com (mail-yw0-f43.google.com [209.85.213.43]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 3 May 2012 20:05:33 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-yw0-f43.google.com [209.85.213.43] #+LO+TR X-Umn-Classification: local Received: by mail-yw0-f43.google.com with SMTP id k6so2715556yhk.16 for ; Thu, 03 May 2012 18:05:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=XAzjxYuVEybYgDH4HZO/lDrcOGBDYA5JqiczIpjlEno=; b=LVqfebJnmYhlzxZfPzqFFdWVWD4/sPSrMPjNUwQVdjq+Fm609dAcXIUq0n16A84peu McICjU++SVFuIvNTW+Ce50X5o6rJIXERF3xXPYhTDTtXsS4xfYtG9WZMVGMEPLxTDFEL JY6R0shbdplW5bh4kpCoNtJj2iX1s33kB0JwdUkvvqjAMpjDP5WrnIYJHUqvbVbgH7xj 0IDtT7QYylsXBpc2gDFqG2PZ2/ivEOMDcIt5d1w4ZlCP3vIAVBqGOM5F9mu+3swm7vLW 9LiM1QvyQ8fu2LXm628IOXA69qfhaZgoURe4J92f/MSMQr1ZDqJ+Z+9uinvWWHK5+8dZ 29iA== Received: by 10.42.117.129 with SMTP id t1mr2086204icq.0.1336093533252; Thu, 03 May 2012 18:05:33 -0700 (PDT) Received: from x-128-101-233-147.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:223:6cff:fe94:288c]) by mx.google.com with ESMTPS id pa6sm3219025igc.12.2012.05.03.18.05.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 18:05:31 -0700 (PDT) Message-ID: <4FA32B59.3020204@umn.edu> Date: Thu, 03 May 2012 20:05:29 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Fred Baker References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> In-Reply-To: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl9Bzhck/bC7yM1PeqBN9NI99zNcSMSuK5nsb6V0v3MbTKAwepie7pqpDtNjY8i1nfkoyfT Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC 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: Fri, 04 May 2012 01:05:45 -0000 I support this draft, it provides important and useful advice to RA-Guard implementers and the IPv6 operations community. On 4/22/12 13:00 CDT, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-ra-guard-implementation. 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. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mark@townsley.net Fri May 4 00:42:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8D21F862B for ; Fri, 4 May 2012 00:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-kXakwFoO1c for ; Fri, 4 May 2012 00:42:19 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB19021F8629 for ; Fri, 4 May 2012 00:42:09 -0700 (PDT) Received: by eeke51 with SMTP id e51so799595eek.31 for ; Fri, 04 May 2012 00:42:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FUbes0ilsRtJKzPOMAqakIpcRsmi5NdFjDUyv7DpSkM=; b=IihuUkGKGk6j3Lo5FOFmxOUXUtwmprCVD1LFq2yku76CimRSPAgMbJKy1ZYGomuJZR i2iLQJkulLQcqXjOZgQ8AWbB6eQNeSpfwmFDJJYwKxahBSlBb1PUlYO1uH6HjeHyOwN4 xwkoGpOq3zY3ms7p0N7eOGIjk6o77Mv7l1/fZHws7YcmfdlIAlzFTPeks6iYJvFXvSvI sroxf93/4UNsFVX/xDY6S5QMr5rLy0Me81BogSi4rgBOiiPFyOYVXss0T412eGX+WwmE 9SiREaf09Yj66iVEugHiT2lE2XAZS+YBM9tdoka6Kz9R3oTkgyqO3XD2llRKRjN6rI92 dsng== Received: by 10.213.110.12 with SMTP id l12mr987868ebp.25.1336117328788; Fri, 04 May 2012 00:42:08 -0700 (PDT) Received: from ?IPv6:2a01:e35:2ef3:a3f0:c21:30a5:d6:d11f? ([2a01:e35:2ef3:a3f0:c21:30a5:d6:d11f]) by mx.google.com with ESMTPS id d18sm37314643eeb.7.2012.05.04.00.42.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 00:42:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <20120503065046.GJ84425@Space.Net> Date: Fri, 4 May 2012 09:42:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AA30D5F-048D-4092-B721-B261A9F6AA53@townsley.net> References: <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> <20120503065046.GJ84425@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmSlWfDHdCUEAstcxGpjUi5wJq6MkDvfSQkFCtvWQKLBFz5jptP3+bJxMXuevbfayELxdBK Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 07:42:19 -0000 On May 3, 2012, at 8:50 AM, Gert Doering wrote: > Hi, >=20 > On Thu, May 03, 2012 at 08:17:51AM +0200, Mark Townsley wrote: >> Thanks everyone for the comments.=20 >>=20 >> After some additional word-smithing offline between Chris, Hemant, = Wes, and I, the four of us are _finally_ in agreement on the following = text. I think we'd all like to put this one to rest now, and at least as = far as the four of us are concerned, we can if this is what goes into = the next rev of the document.=20 >>=20 >> 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to = be active alone as well as simultaneously in order to support = coexistence of the two technologies during an incremental migration = period from 6rd to native IPv6.=20 >=20 > ACK. >=20 >> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [Section 4.3 [RFC3704]]. >=20 > I still disagree with the wording "the WAN interface is connected to" = - in Yes, I remember you mentioning that before but didn't manage to = incorporate it.=20 > the first half of the sentence, you have "the 6rd" and "the WAN" = interface, > while the second half only talks about "the WAN". So which addresses = is > the 6rd interface to forward? Why is the 6rd interface tied to > "the upstream network the WAN interface is connected to"? >=20 > My suggestion: >=20 > "... the delegated prefix associated with this particular interface=20 > [Section 4.3 [RFC3704]]". So, something like: 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that the packet's source IP address is derived from a = delegated prefix associated with the particular interface the packet is = being sent on [Section 4.3 [RFC3704]]. I'm OK with that if you are. - Mark >=20 > shorter, not tied to "WAN", and the reference to "upstream network" is > not needed anyway. >=20 >> 6RD-6: The CE router MUST allow different as well as identical = delegated prefixes to be configured via each (6rd or native) WAN = interface. =20 >>=20 >> 6RD-7: In the event that forwarding rules produce a tie between 6rd = and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. >=20 > ACK. >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From shemant@cisco.com Fri May 4 01:12:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDE221F8555 for ; Fri, 4 May 2012 01:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.126 X-Spam-Level: X-Spam-Status: No, score=-10.126 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDxXay9lyd6f for ; Fri, 4 May 2012 01:12:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A03DD21F84EA for ; Fri, 4 May 2012 01:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2706; q=dns/txt; s=iport; t=1336119145; x=1337328745; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9XIsF5913CvNpLQrCRxTL12yFuvDgApQNtzho96LZ+U=; b=CBiGWEPh9css8KS7sULsQzB4qiwVQtpnRteJgLiDdFZvjhBYfFQpQse1 9LOUXTPTGKqVd9Sdh7/RoSvSEMH+9FG4jMDtuJ6AwpxMLulEfyNcoFGVm XOmPb23+4D+cyWBgGs1yi9mRktn4F1tdu5RygvZ2sQqPRLnuQsmmEl08Z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAE6Oo0+tJV2c/2dsb2JhbABFhW6sB4ESgQeCCQEBAQQBAQEPARANBDoLDAQCAQgRBAEBAQICBgYXAQICAgEBHwYfCQgBAQQBEggah10DCwuaco0WiR4NiU8EgS+IXIVqNWMEiGSYWYMagWmDBg X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="80331866" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 04 May 2012 08:12:25 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q448CPij024161; Fri, 4 May 2012 08:12:25 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 May 2012 03:12:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 4 May 2012 03:12:23 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30496616C@XMB-RCD-109.cisco.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A7F88@GAALPA1MSGUSR9N.ITServices.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] (S)NTP in 6204bis Thread-Index: Ac0myZUhauwjtOVfSFuWu+r+34uEagAA7AzgAAmr4IAAB6el4ACuVjLw References: <2D09D61DDFA73D4C884805CC7865E6110A7F1D@GAALPA1MSGUSR9N.ITServices.sbc.com><5B6B2B64C9FE2A489045EEEADDAFF2C3048C36F0@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7F88@GAALPA1MSGUSR9N.ITServices.sbc.com> From: "Hemant Singh (shemant)" To: "STARK, BARBARA H" , "Hans Liu" X-OriginalArrivalTime: 04 May 2012 08:12:25.0370 (UTC) FILETIME=[A39E2FA0:01CD29CD] Cc: v6ops@ietf.org Subject: Re: [v6ops] (S)NTP in 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 08:12:26 -0000 SSBiZWdhbiBlZGl0aW5nIHJmYzYyMDRiaXMgZm9yIFNOVFAgYW5kIHRoZW4gcmVhbGl6ZWQgYW4g aW50ZXJlc3RpbmcgaXNzdWUuICBSRkMgNTkwOCBkZWZpbmVzIGEgRlFETiBESENQdjYgc3Vib3B0 aW9uIG9ubHkgZm9yIE5UUHY0IGFzIGRlZmluZWQgaW4gUkZDIDU5MDUuICBSZmM2MjA0YmlzIGNh bGxzIG91dCBmb3IgdXNlIG9mIFNOVFAgYXMgZGVmaW5lZCBpbiBSRkMgMjAzMC4gIEFueW9uZSBt aW5kIGlmIHJmYzYyMDRiaXMgY2hhbmdlcyBmcm9tIFJGQyAyMDMwIHRvIFJGQyA1OTA1Pw0KDQpU aGFua3MsDQoNCkhlbWFudA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU1RB UkssIEJBUkJBUkEgSCBbbWFpbHRvOmJzNzY1MkBhdHQuY29tXSANClNlbnQ6IE1vbmRheSwgQXBy aWwgMzAsIDIwMTIgOTozMCBBTQ0KVG86IEhhbnMgTGl1OyBIZW1hbnQgU2luZ2ggKHNoZW1hbnQp DQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbdjZvcHNdIChTKU5UUCBpbiA2MjA0 YmlzDQoNClllcywgdGhhbmtzLiA1OTA4Lg0KQmFyYmFyYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEhhbnMgTGl1IFttYWlsdG86aGFuc2xpdUBnbWFpbC5jb21dDQo+ IFNlbnQ6IE1vbmRheSwgQXByaWwgMzAsIDIwMTIgOTowOSBBTQ0KPiBUbzogSGVtYW50IFNpbmdo IChzaGVtYW50KQ0KPiBDYzogU1RBUkssIEJBUkJBUkEgSDsgdjZvcHNAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFt2Nm9wc10gKFMpTlRQIGluIDYyMDRiaXMNCj4gDQo+IFJGQyA1OTA4ICE/ICA6 KQ0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBIYW5zDQo+IA0KPiBPbiBNb24sIEFwciAzMCwgMjAx MiBhdCA4OjMzIFBNLCBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpDQo+IDxzaGVtYW50QGNpc2NvLmNv bT4gd3JvdGU6DQo+ID4gQmFyYmFyYSwNCj4gPg0KPiA+IFNlY3Rpb24gNyBvZiBSRkMgNTA5OCBp cyB0aGUgQWNrbm93bGVkZ2VtZW50cyBzZWN0aW9uLiDCoElzIFJGQyA1MDk4DQo+ID4gdGhlIGNv cnJlY3QgUkZDPw0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+DQo+ID4gSGVtYW50DQo+ID4NCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZiBTVEFS SywgQkFSQkFSQSBIDQo+ID4gU2VudDogTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiA4OjA2IEFNDQo+ ID4gVG86IHY2b3BzQGlldGYub3JnDQo+ID4gU3ViamVjdDogW3Y2b3BzXSAoUylOVFAgaW4gNjIw NGJpcw0KPiA+DQo+ID4gQSBjb2xsZWFndWUgb2YgbWluZSBwb2ludGVkIG91dCB0byBtZSB0aGF0 IDYyMDQgYW5kIDYyMDRiaXMgcmVmZXJlbmNlDQo+ID4gUkZDIDQwNzUgZm9yIHRoZSBESENQdjYg U05UUCBzZXJ2ZXIgb3B0aW9uLCBhbmQgdGhhdCBSRkMgNTA5OCBjbGFpbXMNCj4gPiBpbiB0aGUg Ym9keSBvZiBpdHMgdGV4dCAoc2VjdGlvbiA3KSB0byBkZXByZWNhdGUgNDA3NS4gU2hvdWxkIHdl IGJlDQo+ID4gcmVjb21tZW5kaW5nIHVzZSBvZiA0MDc1IG9yIDUwOTggaW4gNjIwNChiaXMpPw0K PiA+IEJhcmJhcmENCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGlu ZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiANCj4gDQo+IC0tDQo+IEluc3RlYWQgb2YgZm9sbG93 aW5nIHRoZSBmYXNoaW9uLCB3ZSBsZWFkIGl0IHRocm91Z2guDQo= From ichiroumakino@gmail.com Fri May 4 02:40:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5AE21F86F7 for ; Fri, 4 May 2012 02:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFv+WisPNQHu for ; Fri, 4 May 2012 02:40:20 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A05C21F86C8 for ; Fri, 4 May 2012 02:40:20 -0700 (PDT) Received: by werf13 with SMTP id f13so715485wer.31 for ; Fri, 04 May 2012 02:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=l+aD0Ra8qqDN4TeVc8PV42sjX2j/rfqK6AwJF7e+fRE=; b=TSkfY/Pv0J2nJS3z3vSKCzENKS7szGM/yBu3SKR2AH+nomRBo3OQjYLlc/z3qy4hrW 8pbGAu+ThMvhF0t9A4jjyW1+18OyDleMMLtpc1Dts8UNF6waF/UYevQ/EJVn3Dn6KJzX 3CuzIuiUoUM53aE1fZyC+su/iFPzFuMFUS/35B8bNFVU4Q7KCJLB0g7M7nw+mOPVHQl4 jmjDETVheRCqTwWW3PNT4oZP2qsbOpe56ZqD4ux8QRrCfP8z3fR/vDqGp54D5W3H8qc0 mv95sCUg3hD0Oz9CDikZnmbk8F78B4qwoAUF1Y+NjjJ1qVpTwuHm5FsIq9CBh84/Nb7d 3SLQ== Received: by 10.180.90.102 with SMTP id bv6mr11251068wib.6.1336124410465; Fri, 04 May 2012 02:40:10 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j3sm13278669wiw.1.2012.05.04.02.40.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 02:40:09 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 4 May 2012 11:40:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4AD61E75-59AA-4D9E-AF45-6B3766E48272@employees.org> References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 09:40:21 -0000 Jason, RFC6204 specifies an IPv6 CE router. it only considers IPv6. any IPv4 = considerations where out of scope. with the introduction of IPv4 in RFC6204bis, you at least are dual = stacked multi-homed to the same ISP: +------------+------------+ \ | Service | \ | Provider A | | Service | Router | | Provider +------------+------------+ | network | | / | Customer | / IPv6 | Internet | IPv4 / | connections | | +---------+---------+ \ | IPv6 | \ | Customer Edge | \ | Router | / +---------+---------+ / | / | | End-User ---+------------+-------+--------+-------------+--- | network(s) | | | | \ +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / | | | | | | | | / +----------+ +----------+ +----------+ +----------+ with a mechanism for IPv4 sunsetting and a mechanism for IPv6 = transition, you have 4 "WAN interfaces", that have interdependencies between each other. this document is = describing the behaviour of a retail router, _without_ a management interface available to the ISP. (so can we please = agree that "how this can be solved with TR-69" is irrelevant for this = discussion?) cheers, Ole= From simon.perreault@viagenie.ca Fri May 4 06:15:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2A721F867C for ; Fri, 4 May 2012 06:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqLtuVoM58cQ for ; Fri, 4 May 2012 06:15:17 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37F21F8675 for ; Fri, 4 May 2012 06:15:17 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:fd74:94dc:fbc7:7264]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4E26F40090; Fri, 4 May 2012 09:15:16 -0400 (EDT) Message-ID: <4FA3D663.8080708@viagenie.ca> Date: Fri, 04 May 2012 09:15:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Mark Townsley References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> In-Reply-To: <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 13:15:18 -0000 On 2012-05-03 18:48, Mark Townsley wrote: >> 1. If the CPE has no 6rd config (either static config or from >> TR-69) then do a DHCPv4 request with option 212. > > Except TR-69 doesn't operate without IP, which means DHCPv4 (or is it > DHCPv6?) goes first of course. Right, but that's not the important part. Let's not get distracted by TR-69, it's not a hard problem to fix. >> 2. Do a DHCPv6 request. >> >> 3. If the DHCPv6 request fails, wait until we have 6rd config, then >> bring up the 6rd interface. > > How long do you wait for DHCPv6 to fail before you bring up 6rd? 15 > seconds? 30? A minute? I'm sure we can suggest something reasonable. 10 seconds looks fine to me. If DHCPv6 succeeds later on (it could even be several days later, when e.g. the ISP turns on DHCPv6), you just turn off the 6rd interface. > Would my 6rd-provider like that v6 bringup is > delayed by that long for *all* their users? It's acceptable. It only affects 6rd. IPv4 is still instantaneous. IPv6 native is still instantaneous. > Do we really want v6 to take a minute longer to come up than v4? s/v6/6rd/ So far it looks like an acceptable trade-off vs simplicity. > I honestly had a power breaker flip just today (two, actually) - the > DSL gateway came back pretty quickly, the VPN router took quite a bit > longer.. .I was not at all happy with the VPN router. The vast majority of users don't care about 6rd and won't notice. > We've even had operators say on this list that they want to have the > alternative to move from v6 back to 6rd, so perhaps the order of your > state machine should be reversed? Sure. DHCPv6 goes down --> activate 6rd DHCPv6 goes up --> deactivate 6rd > Bottom line: you probably are not going to agree on what to do here, > and as a retail CPE vendor, I want to be sure that what comes out > works with all operational cases, and without bugging the users for > config (even if you tell me it is OK to have manual config for your > customers, that's not OK for me as a CPE vendor). > > What Ole and I proposed, defended in Paris, and have been asked by > the chairs to formulate simple requirements for, is the only option > that hits *all* cases you can throw at the problem… and, it's really > not as hard as it sounds to make happen. RFC 3704 has been around > since 2004, let's not pretend it is rocket science today. Brain surgery isn't rocket science either. So far the "poor man's sunsetting" proposal seems very simple and I can't find holes in it. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Carl.Wuyts@technicolor.com Fri May 4 06:28:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5338321F8650 for ; Fri, 4 May 2012 06:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bWBfHGbAfVK for ; Fri, 4 May 2012 06:28:16 -0700 (PDT) Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) by ietfa.amsl.com (Postfix) with ESMTP id 7917221F863F for ; Fri, 4 May 2012 06:28:12 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKT6PZZ3iDrwCeB/eFMlc+Et2fpUpQm56s@postini.com; Fri, 04 May 2012 06:28:16 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 4 May 2012 15:26:46 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Fri, 4 May 2012 15:27:04 +0200 From: Wuyts Carl To: Simon Perreault , Mark Townsley Date: Fri, 4 May 2012 15:27:02 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: Ac0p9/y562GkWsTZT+S2+3jAm2pDWQAADcTg Message-ID: <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> In-Reply-To: <4FA3D663.8080708@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 13:28:17 -0000 I read: "" DHCPv6 goes down --> activate 6rd DHCPv6 goes up --> deactivate 6rd "" Seems a recurring event to link different protocols to each other. 6rd, i.= e. IPv4 with optional DHCPv4 has no real link with IPv6/DHCPv6, so please l= et's avoid (again) to link things to each other and ask from the CPE to bri= ng A up when B goes down and/or vice versa. No matter how long you will wa= it, you'll need some daemon to listen and push some action to the other pro= tocol, or some eventing between the 2, while they in fact have nothing to d= o with each other, so should not be linked and only increases complexity. = Use the "normal" routing to enforce something, i.e. give better metric for = one (native) vs the other or something, a simple mechanism where normal/sta= ndard routing decisions are in place do to their job, so just select the 'b= est route', but please don't link them up. If both native v6 and 6rd route= s are in place, the metric can be used to select the best route, if one of = the 2 is not present it's no issue. It should not be different from any ot= her routing decision. I've seen before similar suggestions (linking protocols up) to ask for opti= on X if option Y or if Z is not set or ... is not answered and things like = that, please avoid this. Thx and regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of S= imon Perreault Sent: vrijdag 4 mei 2012 15:15 To: Mark Townsley Cc: v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) On 2012-05-03 18:48, Mark Townsley wrote: >> 1. If the CPE has no 6rd config (either static config or from >> TR-69) then do a DHCPv4 request with option 212. > > Except TR-69 doesn't operate without IP, which means DHCPv4 (or is it > DHCPv6?) goes first of course. Right, but that's not the important part. Let's not get distracted by TR-69= , it's not a hard problem to fix. >> 2. Do a DHCPv6 request. >> >> 3. If the DHCPv6 request fails, wait until we have 6rd config, then=20 >> bring up the 6rd interface. > > How long do you wait for DHCPv6 to fail before you bring up 6rd? 15=20 > seconds? 30? A minute? I'm sure we can suggest something reasonable. 10 seconds looks fine to me. = If DHCPv6 succeeds later on (it could even be several days later, when e.g.= the ISP turns on DHCPv6), you just turn off the 6rd interface. > Would my 6rd-provider like that v6 bringup is delayed by that long for=20 > *all* their users? It's acceptable. It only affects 6rd. IPv4 is still instantaneous. IPv6 nat= ive is still instantaneous. > Do we really want v6 to take a minute longer to come up than v4? s/v6/6rd/ So far it looks like an acceptable trade-off vs simplicity. > I honestly had a power breaker flip just today (two, actually) - the=20 > DSL gateway came back pretty quickly, the VPN router took quite a bit=20 > longer.. .I was not at all happy with the VPN router. The vast majority of users don't care about 6rd and won't notice. > We've even had operators say on this list that they want to have the=20 > alternative to move from v6 back to 6rd, so perhaps the order of your=20 > state machine should be reversed? Sure. DHCPv6 goes down --> activate 6rd DHCPv6 goes up --> deactivate 6rd > Bottom line: you probably are not going to agree on what to do here,=20 > and as a retail CPE vendor, I want to be sure that what comes out=20 > works with all operational cases, and without bugging the users for=20 > config (even if you tell me it is OK to have manual config for your=20 > customers, that's not OK for me as a CPE vendor). > > What Ole and I proposed, defended in Paris, and have been asked by the=20 > chairs to formulate simple requirements for, is the only option that=20 > hits *all* cases you can throw at the problem... and, it's really not as= =20 > hard as it sounds to make happen. RFC 3704 has been around since 2004,=20 > let's not pretend it is rocket science today. Brain surgery isn't rocket science either. So far the "poor man's sunsetting" proposal seems very simple and I can't f= ind holes in it. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Fri May 4 06:40:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC9D21F86E2 for ; Fri, 4 May 2012 06:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7o2+aA-PdYM for ; Fri, 4 May 2012 06:40:13 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63721F8685 for ; Fri, 4 May 2012 06:40:13 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:fd74:94dc:fbc7:7264]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BCC3240090; Fri, 4 May 2012 09:40:12 -0400 (EDT) Message-ID: <4FA3DC3C.7090602@viagenie.ca> Date: Fri, 04 May 2012 09:40:12 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Wuyts Carl References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 13:40:14 -0000 On 2012-05-04 09:27, Wuyts Carl wrote: > I read: > > "" > DHCPv6 goes down --> activate 6rd > DHCPv6 goes up --> deactivate 6rd > "" > > Seems a recurring event to link different protocols to each other. 6rd, i.e. IPv4 with optional DHCPv4 has no real link with IPv6/DHCPv6, so please let's avoid (again) to link things to each other and ask from the CPE to bring A up when B goes down and/or vice versa. No matter how long you will wait, you'll need some daemon to listen and push some action to the other protocol, or some eventing between the 2, while they in fact have nothing to do with each other, so should not be linked and only increases complexity. The goal here is to actually *reduce* complexity. If you let DHCPv6 and 6rd be up simultaneously, you end up having to do source-based routing. > Use the "normal" routing to enforce something, i.e. give better metric for one (native) vs the other or something, a simple mechanism where normal/standard routing decisions are in place do to their job, so just select the 'best route', but please don't link them up. If both native v6 and 6rd routes are in place, the metric can be used to select the best route, if one of the 2 is not present it's no issue. It should not be different from any other routing decision. This won't work because of the ISP's ingress filtering. You have to send packets to the interface where the ISP's routers doing RPF check will not drop them. So we're talking about source-based routing on the CPE. This has been discussed many times. It's the only reason we're having this discussion, otherwise your suggestion would have been adopted a long time ago. ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nick@inex.ie Fri May 4 07:12:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B97D21F87B2 for ; Fri, 4 May 2012 07:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NcZh22NciHt for ; Fri, 4 May 2012 07:12:15 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A205821F87A2 for ; Fri, 4 May 2012 07:12:14 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local ([IPv6:2001:1bb8:2004:100:d47d:275c:1469:5eb4]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q44EBaHY066429 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 May 2012 15:11:37 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FA3E3B2.1080808@inex.ie> Date: Fri, 04 May 2012 15:12:02 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Fernando Gont References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> <4FA22A2A.5080006@si6networks.com> <4FA26A73.9070001@inex.ie> <4FA31C7F.1040601@si6networks.com> In-Reply-To: <4FA31C7F.1040601@si6networks.com> X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:12:16 -0000 On 04/05/2012 01:02, Fernando Gont wrote: > By "paragraphs" you mean the bullets corresponding to the filtering > rules, right? yes. Nick From gert@space.net Fri May 4 08:13:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721ED21F8606 for ; Fri, 4 May 2012 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-4B2ZQrgYFb for ; Fri, 4 May 2012 08:13:40 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C87421F85F0 for ; Fri, 4 May 2012 08:13:38 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E4843F8ADE for ; Fri, 4 May 2012 17:13:36 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D2DA9F8AB9 for ; Fri, 4 May 2012 17:13:36 +0200 (CEST) Received: (qmail 7833 invoked by uid 1007); 4 May 2012 17:13:36 +0200 Date: Fri, 4 May 2012 17:13:36 +0200 From: Gert Doering To: Mark Townsley Message-ID: <20120504151336.GZ84425@Space.Net> References: <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> <20120503065046.GJ84425@Space.Net> <8AA30D5F-048D-4092-B721-B261A9F6AA53@townsley.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VIwbchOY3sivGJsr" Content-Disposition: inline In-Reply-To: <8AA30D5F-048D-4092-B721-B261A9F6AA53@townsley.net> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 15:13:40 -0000 --VIwbchOY3sivGJsr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment Content-Transfer-Encoding: quoted-printable Hi, On Fri, May 04, 2012 at 09:42:02AM +0200, Mark Townsley wrote: > > "... the delegated prefix associated with this particular interface=20 > > [Section 4.3 [RFC3704]]". >=20 > So, something like: >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directe= d such that the packet's source IP address is derived from a delegated pref= ix associated with the particular interface the packet is being sent on [Se= ction 4.3 [RFC3704]]. >=20 > I'm OK with that if you are. That would work for me. (Ole's text suggestions would also work). Gert Doering -- Operator --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --VIwbchOY3sivGJsr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT6PyIKkuBuNlUUl1AQIO/wQAsI4uqTf2VzxLoI7+Qyw/gz519z5w5Kwl aGJT1BcLt4VkeaNWTxNKmAFaGxuPZtrD7qaP2c/VmCK9HisMBplalbUB7S1cg22Y gjdfTW4kMCB1gUCKZGiKukZf24yJC3TOg5dz4sMd24HK8wAFdOUfn+txQSHLVqfV Wtmn7/9+ND4= =Z9ON -----END PGP SIGNATURE----- --VIwbchOY3sivGJsr-- From Tina.Tsou.Zouting@huawei.com Fri May 4 08:41:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C121F8685 for ; Fri, 4 May 2012 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ2gTF3DFdtw for ; Fri, 4 May 2012 08:41:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 376FD21F8680 for ; Fri, 4 May 2012 08:41:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN22849; Fri, 04 May 2012 11:41:52 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 08:39:21 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 08:39:18 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.48]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Fri, 4 May 2012 23:39:15 +0800 From: Tina TSOU To: Simon Perreault Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNKPSKZzcvLM2PKkmdpLGhI75yTZa3IPIAgAAeRwCAAAKtgIAAVn0AgAAG8ACAAASjgIAAHPoAgAABygCAAGLXAIAA8kyAgAADSwCAAAOuAIAAp2Ao Date: Fri, 4 May 2012 15:39:15 +0000 Message-ID: <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com>, <4FA3DC3C.7090602@viagenie.ca> In-Reply-To: <4FA3DC3C.7090602@viagenie.ca> Accept-Language: en-US, zh-CN 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 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 15:41:53 -0000 Sent from my iPad On May 4, 2012, at 6:40 AM, "Simon Perreault" = wrote: > On 2012-05-04 09:27, Wuyts Carl wrote: >> I read: >>=20 >> "" >> DHCPv6 goes down --> activate 6rd >> DHCPv6 goes up --> deactivate 6rd >> "" >>=20 >> Seems a recurring event to link different protocols to each other. 6rd,= i.e. IPv4 with optional DHCPv4 has no real link with IPv6/DHCPv6, so pleas= e let's avoid (again) to link things to each other and ask from the CPE to = bring A up when B goes down and/or vice versa. No matter how long you will= wait, you'll need some daemon to listen and push some action to the other = protocol, or some eventing between the 2, while they in fact have nothing t= o do with each other, so should not be linked and only increases complexity= . >=20 > The goal here is to actually *reduce* complexity. If you let DHCPv6 and 6= rd be up simultaneously, you end up having to do source-based routing. It is not pretty. But it seems the only way for efficiency. >=20 >> Use the "normal" routing to enforce something, i.e. give better metric f= or one (native) vs the other or something, a simple mechanism where normal/= standard routing decisions are in place do to their job, so just select the= 'best route', but please don't link them up. If both native v6 and 6rd ro= utes are in place, the metric can be used to select the best route, if one = of the 2 is not present it's no issue. It should not be different from any= other routing decision. >=20 > This won't work because of the ISP's ingress filtering. You have to send = packets to the interface where the ISP's routers doing RPF check will not d= rop them. So we're talking about source-based routing on the CPE. This has = been discussed many times. It's the only reason we're having this discussio= n, otherwise your suggestion would have been adopted a long time ago. ;) >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jason.weil@twcable.com Fri May 4 11:10:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8202B21F8616 for ; Fri, 4 May 2012 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xbO57-bFQVF for ; Fri, 4 May 2012 11:10:16 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id EA45521F8613 for ; Fri, 4 May 2012 11:10:15 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,532,1330923600"; d="scan'208";a="360181316" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 04 May 2012 14:09:07 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 4 May 2012 14:10:14 -0400 From: "Weil, Jason" To: =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Fri, 4 May 2012 14:10:14 -0400 Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: Ac0qISeL74uQL/ImTpGshwIe+sfA8g== Message-ID: In-Reply-To: <4AD61E75-59AA-4D9E-AF45-6B3766E48272@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 18:10:16 -0000 So we are very close to a gray area in which you are trying to solve for an arbitrary upstream topology based on lack of detail in the current test. I have no doubt the solution is doable given enough iterations and a year or two of trial and error in the field. All I am asking is we do our best not to overly engineer the "best" solution for the minority use cases that results in negative impact to the majority of use cases. Thanks, Jason On 5/4/12 5:40 AM, "Ole Tr=F8an" wrote: >Jason, > >RFC6204 specifies an IPv6 CE router. it only considers IPv6. any IPv4 >considerations where out of scope. > >with the introduction of IPv4 in RFC6204bis, you at least are dual >stacked multi-homed to the >same ISP: > > +------------+------------+ \ > | Service | \ > | Provider A | | Service > | Router | | Provider > +------------+------------+ | network > | | / > | Customer | / > IPv6 | Internet | IPv4 / > | connections | | > +---------+---------+ \ > | IPv6 | \ > | Customer Edge | \ > | Router | / > +---------+---------+ / > | / > | | End-User > ---+------------+-------+--------+-------------+--- | network(s) > | | | | \ > +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ > |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / > | | | | | | | | / > +----------+ +----------+ +----------+ +----------+ > >with a mechanism for IPv4 sunsetting and a mechanism for IPv6 transition, >you have 4 "WAN interfaces", >that have interdependencies between each other. this document is >describing the behaviour of a retail router, >_without_ a management interface available to the ISP. (so can we please >agree that "how this can be solved with TR-69" is irrelevant for this >discussion?) > >cheers, >Ole 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 ichiroumakino@gmail.com Fri May 4 11:26:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2429B21F8587 for ; Fri, 4 May 2012 11:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUavAAYpoYNG for ; Fri, 4 May 2012 11:26:28 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 60C6421F8585 for ; Fri, 4 May 2012 11:26:28 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so1435520wgb.1 for ; Fri, 04 May 2012 11:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nPjZFEicECPyFC14jvi1E9MWV42qTheDvQujbEIhO+U=; b=RM5yPWvXyA0pZlGu82WlnplzEAVednzbVdSkl2VIiEYLaSnX60o7h9R01rH7iWxdNK r3xjyQJHz5o+loQegVlbVnLugEbb/f5ThQpQvVNunDaLJIxvZ74AMV580/SE8DMtiCEL tVQWm2HG3lj5voB+ffqTWWDtYDvaSK1AUskUMcyVwkpQfSzSZep7jettfKkqOD0ko9W/ ur5gmJwCvkj15m++71xFO4IkAz98pf8zPwvIQaLCwW8LiBCDAu7nzTS77b62EafeqoSe jLKsbGNzhoX1GSn/uQfHvEcX/kfsHChp2GNvnDF7Sor3WOjIo3evDsVC90tB+uQ3ubib MFvw== Received: by 10.180.82.136 with SMTP id i8mr15126877wiy.19.1336155987633; Fri, 04 May 2012 11:26:27 -0700 (PDT) Received: from dhcp-10-61-98-139.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff2sm17572513wib.9.2012.05.04.11.26.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 11:26:26 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 4 May 2012 20:26:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22FDE471-F531-4FAE-8453-885E153559A4@employees.org> References: To: Jason Weil X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 18:26:29 -0000 Jason, > So we are very close to a gray area in which you are trying to solve = for > an arbitrary upstream topology based on lack of detail in the current > test. I have no doubt the solution is doable given enough iterations = and a > year or two of trial and error in the field. All I am asking is we do = our > best not to overly engineer the "best" solution for the minority use = cases > that results in negative impact to the majority of use cases. you claim complexity, complex for whom? for ISPs, having CPEs work in a consistent with regards to 6rd/native = IPv6 means they can transition from one to the other without a flag day. = it is also simpler to provision as the CPE would do the right thing (tm) = regardless of how it was provisioned. for the end user, the CPE comes from the shop with the right defaults, = being able to handle both native IPv6 and 6rd (we obviously need that = for IPv4 sunset as well), with no need to reboot the CPE, or manually = configure it, or call the ISP help desk. for the CPE implementor, there is no need to create dependencies between = IPv4 and IPv6 provisioning, but we need to implement SAD. sitting here = looking at our PBR code right now... well, it isn't particularly hard. cheers, Ole= From Jean-Francois.TremblayING@videotron.com Fri May 4 12:52:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377E221F84E2; Fri, 4 May 2012 12:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5mGeX1dsIrH; Fri, 4 May 2012 12:52:15 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id A01D021F8469; Fri, 4 May 2012 12:52:15 -0700 (PDT) In-Reply-To: To: IPv6 Operations MIME-Version: 1.0 X-KeepSent: DB84F5FC:9CBBAB3A-852579F4:006CB822; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Fri, 4 May 2012 15:52:02 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/04/2012 15:52:10, Serialize complete at 05/04/2012 15:52:10 Content-Type: multipart/alternative; boundary="=_alternative 006D2562852579F4_=" Received-SPF: none Cc: v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 19:52:16 -0000 Message en plusieurs parties au format MIME --=_alternative 006D2562852579F4_= Content-Type: text/plain; charset="US-ASCII" > All I am asking is we do our > best not to overly engineer the "best" solution for the minority use cases > that results in negative impact to the majority of use cases. +1 Keeping the same prefix in 6RD sunset and therefore requiring multihoming seems to be the need of a very small minority. Let's not overengineer (is that even a verb?) solutions for the whole industry based on the need of very few. /JF --=_alternative 006D2562852579F4_= Content-Type: text/html; charset="US-ASCII"
> All I am asking is we do our
> best not to overly engineer the "best" solution for the minority use cases
> that results in negative impact to the majority of use cases.
+1
Keeping the same prefix in 6RD sunset and therefore requiring multihoming
seems to be the need of a very small minority. Let's not overengineer
(is that even a verb?) solutions for the whole industry based on
the need of very few.

/JF

 --=_alternative 006D2562852579F4_=-- From Jean-Francois.TremblayING@videotron.com Fri May 4 13:02:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA73F21F855B; Fri, 4 May 2012 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOD-JlLHZ-pH; Fri, 4 May 2012 13:02:08 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 4B28521F855A; Fri, 4 May 2012 13:02:08 -0700 (PDT) In-Reply-To: <22FDE471-F531-4FAE-8453-885E153559A4@employees.org> To: otroan@employees.org MIME-Version: 1.0 X-KeepSent: 24937CED:9BD18B83-852579F4:006D2993; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Fri, 4 May 2012 16:01:54 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/04/2012 16:02:02, Serialize complete at 05/04/2012 16:02:02 Content-Type: multipart/alternative; boundary="=_alternative 006E0CC1852579F4_=" Received-SPF: none Cc: IPv6 Operations , v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 20:02:08 -0000 Message en plusieurs parties au format MIME --=_alternative 006E0CC1852579F4_= Content-Type: text/plain; charset="US-ASCII" Ole, > you claim complexity, complex for whom? > for the CPE implementor, there is no need to create dependencies between > IPv4 and IPv6 provisioning, but we need to implement SAD. The claim here is that these 'dependancies' are significantly easier and faster to implement than SAD, altough the latter is probably more elegant on the long term. Time is the essence here. As Hans mentioned, this is already implemented, so we even have running code proving it works without significant impacts. > sitting here looking at our PBR code right now... well, it isn't particularly hard. This is not the feedback I received from implementors. They claim this is a significant challenge and will impact the delivery of IPv6 features. I can't speak for them here, but this is actual feedback from the field, verified by experience in the past years. /JF --=_alternative 006E0CC1852579F4_= Content-Type: text/html; charset="US-ASCII"
Ole,
> you claim complexity, complex for whom?
> for the CPE implementor, there is no need to create dependencies between
> IPv4 and IPv6 provisioning, but we need to implement SAD.

The claim here is that these 'dependancies' are significantly easier and faster
to implement than SAD, altough the latter is probably more elegant on the long term.
Time is the essence here. As Hans mentioned, this is already implemented,
so we even have running code proving it works without significant impacts.

> sitting here looking at our PBR code right now... well, it isn't particularly hard.

This is not the feedback I received from implementors. They claim this is a
significant challenge and will impact the delivery of IPv6 features.
I can't speak for them here, but this is actual feedback from the field,
verified by experience in the past years.

/JF

--=_alternative 006E0CC1852579F4_=-- From ichiroumakino@gmail.com Fri May 4 13:08:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F49521F85B6; Fri, 4 May 2012 13:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ulSW4vh-paP; Fri, 4 May 2012 13:08:40 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2529C21F85A3; Fri, 4 May 2012 13:08:39 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so3333599wgb.34 for ; Fri, 04 May 2012 13:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RCBaW9b9KMZpDExr0C2H+zAuMGWkLh6T24cbQxyvuZM=; b=TG0mr/nFp2eE0dmNcSfUQL4SjX0+SvTMS9nHxpwGXNd9EhHErpM284D3sR1cUbx6N8 S8QgnbBE4cv7qcOuLYG9a8LJ/DUJdW7hdMr12MeZHjUb5mPJSsgZH1Ak+Gu1iO0SF6b8 d3C80d8/kXi4ZnB2OmsPQ0Z2skUx5jsC9y0aPPJGADTlLuKzbCxc4/hCYC0SJ+yeQAie THFtcOPJRWuOXqsHzHQ2IlLollVmzrZoynC9OcfAOeh6HJbpq/4sfR3zBdTg+cscgHNH zlHS1+ygSLIQeQ5rGZpMDHEpGpwr4Cd5etbBzE88JgAfWFK+BGdE+3TOkkFKPmTuSo6z h42Q== Received: by 10.216.134.28 with SMTP id r28mr4760704wei.2.1336162119101; Fri, 04 May 2012 13:08:39 -0700 (PDT) Received: from dhcp-10-61-98-139.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id k6sm3516315wiy.7.2012.05.04.13.08.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 13:08:38 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 4 May 2012 22:08:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations , v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 20:08:41 -0000 JF, > > All I am asking is we do our > > best not to overly engineer the "best" solution for the minority use = cases > > that results in negative impact to the majority of use cases. >=20 > +1=20 > Keeping the same prefix in 6RD sunset and therefore requiring = multihoming=20 > seems to be the need of a very small minority. Let's not overengineer=20= > (is that even a verb?) solutions for the whole industry based on=20 > the need of very few.=20 it isn't the "same prefix requirement" that is driving multi-homing. what is driving it is that otherwise you'd require a "flag day" what = Mark calls "forced single homing". cheers, Ole= From ichiroumakino@gmail.com Fri May 4 13:09:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1444211E8072; Fri, 4 May 2012 13:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.104 X-Spam-Level: X-Spam-Status: No, score=-3.104 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVnO80bWWgme; Fri, 4 May 2012 13:09:21 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E57521F85B9; Fri, 4 May 2012 13:09:21 -0700 (PDT) Received: by werf13 with SMTP id f13so1137029wer.31 for ; Fri, 04 May 2012 13:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=44BJ/X1j6EC2V1RGyYufuiiWlQYjH3fYqLaD0nIGQeU=; b=UxjVhhNSpQVbnsJ6hO1aZnFQNAd17j688VMjyYvDwBUWIZA/kBFNQUucZTRUEKr7Sr UU6PwzxUZlTyUpdJPFhqiZnKMPv/+IDonuxX6xEC/146kblIuonMRv/BiRfH+WuXwCei 2XDWS+40MkwFNq5zVcpCq/bQWxiaSt12jglujXb04t0QQUQ+4fbhRBFuZH4j2GhP8Bb4 64tN8HI4ph45G/qR1Qv4O/q4cUbeESC5CsWWOpXRXExMIYVD4Qijg0ghkevhGrGVB8Rl 1JOIabsFMVRbGywxY+skfvmQ3Wog/uKxbeGPmb75jLzHEFt8dP4yuv8Kctg8YzLF9m+o s9TQ== Received: by 10.180.105.194 with SMTP id go2mr15789533wib.22.1336162160286; Fri, 04 May 2012 13:09:20 -0700 (PDT) Received: from dhcp-10-61-98-139.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l5sm3521687wia.11.2012.05.04.13.09.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 13:09:19 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 4 May 2012 22:09:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40B6384C-DFFC-47EE-94D4-3465B230BBE7@employees.org> References: To: Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations , v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 20:09:22 -0000 > This is not the feedback I received from implementors. They claim this = is a=20 > significant challenge and will impact the delivery of IPv6 features.=20= > I can't speak for them here, but this is actual feedback from the = field,=20 > verified by experience in the past years.=20 could you ask those implementors to speak up themselves? Ole= From Jean-Francois.TremblayING@videotron.com Fri May 4 13:24:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D057D21F85AC; Fri, 4 May 2012 13:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xxzd4DB+hFa; Fri, 4 May 2012 13:24:32 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1B221F859E; Fri, 4 May 2012 13:24:32 -0700 (PDT) In-Reply-To: <40B6384C-DFFC-47EE-94D4-3465B230BBE7@employees.org> To: otroan@employees.org MIME-Version: 1.0 X-KeepSent: E7C8D60F:5E60D575-852579F4:006FD88C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Fri, 4 May 2012 16:24:16 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/04/2012 16:24:26, Serialize complete at 05/04/2012 16:24:26 Content-Type: multipart/alternative; boundary="=_alternative 0070190D852579F4_=" Received-SPF: none Cc: IPv6 Operations , v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2012 20:24:32 -0000 Message en plusieurs parties au format MIME --=_alternative 0070190D852579F4_= Content-Type: text/plain; charset="US-ASCII" >> This is not the feedback I received from implementors. They claim this is a >> significant challenge and will impact the delivery of IPv6 features. >> I can't speak for them here, but this is actual feedback from the field, >> verified by experience in the past years. > could you ask those implementors to speak up themselves? Of course I did. Publicly on this list for one of them. /JF --=_alternative 0070190D852579F4_= Content-Type: text/html; charset="US-ASCII"
>> This is not the feedback I received from implementors. They claim this is a
>> significant challenge and will impact the delivery of IPv6 features.
>> I can't speak for them here, but this is actual feedback from the field,
>> verified by experience in the past years.

> could you ask those implementors to speak up themselves?

Of course I did. Publicly on this list for one of them.

/JF
--=_alternative 0070190D852579F4_=-- From joelja@bogus.com Sat May 5 16:09:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C752821F8589; Sat, 5 May 2012 16:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.007 X-Spam-Level: X-Spam-Status: No, score=-101.007 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUMUCfp58c-U; Sat, 5 May 2012 16:09:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1B921F854B; Sat, 5 May 2012 16:09:54 -0700 (PDT) Received: from Joels-MacBook-Pro.local ([212.60.89.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q45N9ldf080138 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 5 May 2012 23:09:51 GMT (envelope-from joelja@bogus.com) Message-ID: <4FA4AE23.2090408@bogus.com> Date: Fri, 04 May 2012 21:35:47 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Newbery References: <20120418143817.19669.70000.idtracker@ietfa.amsl.com> <829911B8-D986-4381-92FE-C85F2C260EB5@gmail.com> In-Reply-To: <829911B8-D986-4381-92FE-C85F2C260EB5@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 05 May 2012 23:09:52 +0000 (UTC) Cc: IPv6 Ops WG , Internet-Drafts@ietf.org Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-icp-guidance-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, 05 May 2012 23:09:54 -0000 On 4/23/12 23:00 , Michael Newbery wrote: > >> 5.2. Routing >> >> In a dual stack network, IPv4 and IPv6 routing protocols operate >> quite independently and in parallel. The common routing protocols >> all exist in IPv6 versions, such as OSPFv3 [RFC5340], IS-IS >> [RFC5308], and even RIPng [RFC2080] [RFC2081]. For trained staff, >> >> > > Is it worthwhile to mention the potential advantage of IS-IS here? > Offset of course with the cost of converting the IPv4 routing to use > IS-IS as well if that is not already what you do. This is simply to > point out the situation, rather than to recommend. > >> 6. Load Balancers >> >> It is to be expected that IPv6 traffic will initially be low, i.e. >> a small percentage of IPv4 traffic. For this reason, updating >> load balancers to fully support IPv6 can perhaps be delayed; >> however, such >> > However, anyone deploying a load balancer is also probably relying on > it providing fail-over protection and so needs to be aware that by > deferring IPv6 support they lose that as well, not just the > load-balancing. sorry for the late reply but what of the major commercial on open-source load balancers does not support ipv6 in released code? imho, as a DC operator, stacking stateful tranforms is expensive and more sensitive to the perturbations of the larger number of elements. If it causes me to lose access to the source IP in the process then it's still more effort to debug te activity of the v6 customers. > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sun May 6 14:45:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6134C21F8554 for ; Sun, 6 May 2012 14:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.604 X-Spam-Level: X-Spam-Status: No, score=-110.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkJ2gmTgz2aS for ; Sun, 6 May 2012 14:45:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CB3A221F8551 for ; Sun, 6 May 2012 14:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=626; q=dns/txt; s=iport; t=1336340730; x=1337550330; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=ZdSO6lzPSn6rMU1aFj7aIn8KpSiw6sZYUwefvl1BcZ8=; b=hwzR+UUxoC1BsK840z1oHOTaRN04N4yFlGO4pmts0ZNFbz0Bfnek6Xxr tqdRHXwWInAvCdbO7OyiobDbMzZRGP+EAXRThiDUcOr7TFL1Gho990yH6 KcLCPCjLwGgAl3fdXTzjSJnsBUESqtQtGuFMUSWkahVDKu8dslMd50iob A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEADvwpk+rRDoH/2dsb2JhbABEsm6BB4IlASc/gXOHa5penwKNeYJDYwSIZI0ahXaIY4Fpgwc X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="40612634" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 06 May 2012 21:45:30 +0000 Received: from Freds-Computer.local (sjc-vpn6-276.cisco.com [10.21.121.20]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q46LiqTi015971; Sun, 6 May 2012 21:45:29 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 06 May 2012 16:45:30 -0500 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 06 May 2012 16:45:30 -0500 From: Fred Baker Date: Sun, 6 May 2012 16:45:28 -0500 Message-Id: <32A1D69B-8347-4F7B-AB3F-554B386022D0@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-wireline-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 21:45:31 -0000 This is to initiate a two week working group last call of = draft-ietf-v6ops-wireline-incremental-ipv6. Please read it now. If you = find nits (spelling errors, minor suggested wording changes, etc), = comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be addressed, = please post your comments to the list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= From Carl.Wuyts@technicolor.com Sun May 6 23:00:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835B221F84B8 for ; Sun, 6 May 2012 23:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB8X48cegqjv for ; Sun, 6 May 2012 23:00:29 -0700 (PDT) Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id E330E21F84B5 for ; Sun, 6 May 2012 23:00:24 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKT6dk9iG6gb3p2ZxuzT/79YTWdCp5aebX@postini.com; Sun, 06 May 2012 23:00:29 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 7 May 2012 08:00:16 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Mon, 7 May 2012 08:00:22 +0200 From: Wuyts Carl To: Tina TSOU , Simon Perreault Date: Mon, 7 May 2012 08:00:20 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNKPSKZzcvLM2PKkmdpLGhI75yTZa3IPIAgAAeRwCAAAKtgIAAVn0AgAAG8ACAAASjgIAAHPoAgAABygCAAGLXAIAA8kyAgAADSwCAAAOuAIAAp2AogAQSsqA= Message-ID: <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> In-Reply-To: <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 06:00:30 -0000 So, the ISP has a problem with the ingress filtering, hence just add a few = extra reqs to the CPE to "glue" some stuff together ? Great! What's next ? :-( As CPE vendor, our customers are deploying the managed model, so potentiall= y less issues compared to retail (as we have firmware upgrades, tr069, ...)= . I was always told to not fix to hard on this model, but to take into acc= ount that this RFC must, for starters, apply on the retail ones. Well, if = you want something in short term (like everyone seems to want, although rea= lity speaks against it) then I think you've to stop adding these kind of re= quirements as you're making your own rules, overruling protocol independenc= y, ... just for the sake of getting things added. Regs Carl -----Original Message----- From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20 Sent: vrijdag 4 mei 2012 17:39 To: Simon Perreault Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) Sent from my iPad On May 4, 2012, at 6:40 AM, "Simon Perreault" = wrote: > On 2012-05-04 09:27, Wuyts Carl wrote: >> I read: >>=20 >> "" >> DHCPv6 goes down --> activate 6rd >> DHCPv6 goes up --> deactivate 6rd >> "" >>=20 >> Seems a recurring event to link different protocols to each other. 6rd,= i.e. IPv4 with optional DHCPv4 has no real link with IPv6/DHCPv6, so pleas= e let's avoid (again) to link things to each other and ask from the CPE to = bring A up when B goes down and/or vice versa. No matter how long you will= wait, you'll need some daemon to listen and push some action to the other = protocol, or some eventing between the 2, while they in fact have nothing t= o do with each other, so should not be linked and only increases complexity= . >=20 > The goal here is to actually *reduce* complexity. If you let DHCPv6 and 6= rd be up simultaneously, you end up having to do source-based routing. It is not pretty. But it seems the only way for efficiency. >=20 >> Use the "normal" routing to enforce something, i.e. give better metric f= or one (native) vs the other or something, a simple mechanism where normal/= standard routing decisions are in place do to their job, so just select the= 'best route', but please don't link them up. If both native v6 and 6rd ro= utes are in place, the metric can be used to select the best route, if one = of the 2 is not present it's no issue. It should not be different from any= other routing decision. >=20 > This won't work because of the ISP's ingress filtering. You have to send = packets to the interface where the ISP's routers doing RPF check will not d= rop them. So we're talking about source-based routing on the CPE. This has = been discussed many times. It's the only reason we're having this discussio= n, otherwise your suggestion would have been adopted a long time ago. ;) >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Mon May 7 02:38:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F9B21F851B for ; Mon, 7 May 2012 02:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5hvl449mzcg for ; Mon, 7 May 2012 02:38:37 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id BCAC421F84CF for ; Mon, 7 May 2012 02:38:35 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 37E60F8AD8 for ; Mon, 7 May 2012 11:38:34 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2405DF8AC0 for ; Mon, 7 May 2012 11:38:34 +0200 (CEST) Received: (qmail 85162 invoked by uid 1007); 7 May 2012 11:38:34 +0200 Date: Mon, 7 May 2012 11:38:34 +0200 From: Gert Doering To: Wuyts Carl Message-ID: <20120507093834.GI84425@Space.Net> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 09:38:37 -0000 Hi, On Mon, May 07, 2012 at 08:00:20AM +0200, Wuyts Carl wrote: > So, the ISP has a problem with the ingress filtering, hence just add a few extra reqs to the CPE to "glue" some stuff together ? Great! What's next ? It's not "the ISP has a problem". The ISP is a *good guy* and following BCP38 - and there is no easy way a large-scale ISP can configure their access gear to do exceptions for "oh, that customer on a native link also has 6rd with *that* subnet, so make an exception for those source packets". This topic will come back anyway as soon as multi-ISP is considered - this is out of scope for 6204bis, but you need to be handle it in the CPEs anyway. Even if you could make the ISP case work for 6rd + native (which might be possible with some hackery, as the access router knows the ipv4 address and could theoretically be taught to recognize the corresponding 6rd address), there is no way ever you can get a large-scale ISP A to add exceptions for source addresses belonging to ISP B. So if we want ISPs to follow BCP38 *and* support multi-ISP CPEs - then there is no way around proper source-address dependend routing. 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 Carl.Wuyts@technicolor.com Mon May 7 04:06:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45FF21F8470 for ; Mon, 7 May 2012 04:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjgzIyEUpbpK for ; Mon, 7 May 2012 04:06:12 -0700 (PDT) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF6821F846F for ; Mon, 7 May 2012 04:06:07 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKT6esnZ9o0nkQsLAZscH0ADsik2QAwg44@postini.com; Mon, 07 May 2012 04:06:12 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 7 May 2012 13:05:51 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 7 May 2012 13:05:55 +0200 From: Wuyts Carl To: Gert Doering Date: Mon, 7 May 2012 13:05:54 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: Ac0sNS4p3pQWtrw4SIigFyxKepWQMAACrIwg Message-ID: <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> In-Reply-To: <20120507093834.GI84425@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 11:06:13 -0000 Well, I've mentioned earlier that I'm not against this, just against adding= it in today's req list, while you clearly confirm that multi-homed is out = of scope for this document. I don't see an issue today if an ISP provides = 6rd and the same ISP decides to move to native at a certain moment in time.= This is perfectly possible today without using any "specials", like gluei= ng protocols to each other or whatever. It in fact can even be done in bot= h directions (although it's probably not the target to switch form native t= o 6rd anyway :-)). Indeed, to switch to native, the CPE must be dual stack= , support DHCPv6 client, etc, but this is mandatory and covered in RFC6204 = anyway. And, depending on the roll-out model, it might need some (small) r= e-configuration (although this is not certain, lots of things can be pre-co= nfigured upfront but inactive due to v6 not enabled on the link to ISP), wh= ich is of course a pain. Anyway, I'll leave this discussion as is today. I can only speak from (res= idential) CPE's perspective and do want to see some progress in v6 deployme= nt. If the society however decides pro this kind of approach, democracy wi= ll be applied, but keep in mind you might put quite a few CPEs out of the g= ame with this. And, sadly enough, you'll hear the same old story on the v6= events : "The CPE is not ready". Don't forget the CPE is that edge device= , nearly free-of-charge .... Regs Carl -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: maandag 7 mei 2012 11:39 To: Wuyts Carl Cc: Tina TSOU; Simon Perreault; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) Hi, On Mon, May 07, 2012 at 08:00:20AM +0200, Wuyts Carl wrote: > So, the ISP has a problem with the ingress filtering, hence just add a fe= w extra reqs to the CPE to "glue" some stuff together ? Great! What's next= ? It's not "the ISP has a problem". The ISP is a *good guy* and following BCP38 - and there is no easy way a la= rge-scale ISP can configure their access gear to do exceptions for "oh, tha= t customer on a native link also has 6rd with *that* subnet, so make an exc= eption for those source packets". This topic will come back anyway as soon as multi-ISP is considered - this = is out of scope for 6204bis, but you need to be handle it in the CPEs anywa= y. Even if you could make the ISP case work for 6rd + native (which might = be possible with some hackery, as the access router knows the ipv4 address = and could theoretically be taught to recognize the corresponding 6rd addres= s), there is no way ever you can get a large-scale ISP A to add exceptions = for source addresses belonging to ISP B. So if we want ISPs to follow BCP38 *and* support multi-ISP CPEs - then ther= e is no way around proper source-address dependend routing. 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 simon.perreault@viagenie.ca Mon May 7 06:39:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77BE21F8639 for ; Mon, 7 May 2012 06:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3RwnQgq+RTZ for ; Mon, 7 May 2012 06:39:30 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 74E0721F85CD for ; Mon, 7 May 2012 06:39:30 -0700 (PDT) Received: from [IPv6:2607:fa48:94:201:e58b:a8ef:cc1f:bdde] (unknown [IPv6:2607:fa48:94:201:e58b:a8ef:cc1f:bdde]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 93903400F0; Mon, 7 May 2012 09:39:29 -0400 (EDT) Message-ID: <4FA7D090.30700@viagenie.ca> Date: Mon, 07 May 2012 09:39:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gert Doering References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> In-Reply-To: <20120507093834.GI84425@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 13:39:31 -0000 On 05/07/12 05:38, Gert Doering wrote: > So if we want ISPs to follow BCP38 *and* support multi-ISP CPEs - then > there is no way around proper source-address dependend routing. Agreed. And IMHO we should leave multihoming for homenet, and avoid source routing in 6204bis. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From victor.kuarsingh@gmail.com Mon May 7 06:41:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B721A21F8592 for ; Mon, 7 May 2012 06:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDYwU0cbJNJO for ; Mon, 7 May 2012 06:41:56 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 890D221F8569 for ; Mon, 7 May 2012 06:41:55 -0700 (PDT) Received: by lagj5 with SMTP id j5so3936100lag.31 for ; Mon, 07 May 2012 06:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MO47iBOJFbG1pDeNrlTSlXtIAc1a+3MpbYmRvuCMX2c=; b=uGhKt76cXYJak3fUs+B9msFhHy3mYDuhbp3P6ap/vgV/Jid7WrKL7jtXgIMnFwhHUQ SpE+dShBsUU6Bolsm7c9fmDGNE8GZLjWmyw6KE01n4ZuPhg3LwDj6rkYPBROysvEJxrR iUWWi3NzuyHPYP+XKj/WEEjbikW8MoBjRfkBNc4X3GcXkrjQpyXEjCwjn4nx/DhXJsoS ZeImRTIhe9vAV1w0UCq7C6b79pycppf9ids/tZnScEGrXl0ZzfbnbWHCsIiH+WmQk2w1 LTu0/O724OtJ2+ROMfO/oqhUlPWExkvFeH7gugHVVLW+eZlNn73lYTco38zGfHlNh9ck ooTw== MIME-Version: 1.0 Received: by 10.152.147.161 with SMTP id tl1mr14246830lab.15.1336398114314; Mon, 07 May 2012 06:41:54 -0700 (PDT) Received: by 10.112.21.73 with HTTP; Mon, 7 May 2012 06:41:54 -0700 (PDT) In-Reply-To: <32A1D69B-8347-4F7B-AB3F-554B386022D0@cisco.com> References: <32A1D69B-8347-4F7B-AB3F-554B386022D0@cisco.com> Date: Mon, 7 May 2012 09:41:54 -0400 Message-ID: From: Victor Kuarsingh To: Fred Baker Content-Type: multipart/alternative; boundary=e89a8f22bcb3e1d84804bf726ea2 Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-wireline-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 13:41:56 -0000 --e89a8f22bcb3e1d84804bf726ea2 Content-Type: text/plain; charset=ISO-8859-1 WG, As a note, I have an updated coming which incorporates comments made by Gang Chen and Christian Jacquenet. Most of those updates were related to NAT64 (inclusions for text in overview section and deployment considerations) and positioning of text. The set of updates that I have not yet included in the draft pending are those which suggest that preference should be given to IPv6 to promote deployment. Whereas I agree in general that we need to deploy IPv6 in an expedited manner, I do not think risking IPv4 running state operation is a viable option. Making IPv4 worse on purpose (when given other choices) is not a practical and reasonable option. I welcome other opinions here (please try and avoid religious positions on IPv6 and think about the customer experience). regards, Victor Kuarsingh On Sun, May 6, 2012 at 5:45 PM, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-wireline-incremental-ipv6. Please read it now. If you find > nits (spelling errors, minor suggested wording changes, etc), comment to > the authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, please > post your comments to the list. > > We are looking specifically for comments on the importance of the document > as well as its content. If you have read the document and believe it to be > of operational utility, that is also an important comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8f22bcb3e1d84804bf726ea2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable WG,

As a note, I have an updated coming which incorporates comments = made by Gang Chen and Christian Jacquenet.

Most of those updates wer= e related to NAT64 (inclusions for text in overview section and deployment = considerations) and positioning of text.

The set of updates that I have not yet included in the draft pending ar= e those which suggest that preference should be given to IPv6 to promote de= ployment.=A0 Whereas I agree in general that we need to deploy IPv6 in an e= xpedited manner, I do not think risking IPv4 running state operation is a v= iable option.=A0 Making IPv4 worse on purpose (when given other choices) is= not a practical and reasonable option.=A0 I welcome other opinions here (p= lease try and avoid religious positions on IPv6 and think about the custome= r experience).

regards,

Victor Kuarsingh
=A0

On Sun, May 6, 2012 at 5:45 PM, Fred Baker <fred@cisco.com> = wrote:
This is to initiate a two week working group= last call of draft-ietf-v6ops-wireline-incremental-ipv6. Please read it no= w. If you find nits (spelling errors, minor suggested wording changes, etc)= , comment to the authors; if you find greater issues, such as disagreeing w= ith a statement or finding additional issues that need to be addressed, ple= ase post your comments to the list.

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

--e89a8f22bcb3e1d84804bf726ea2-- From Jean-Francois.TremblayING@videotron.com Mon May 7 07:53:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0221F85D1; Mon, 7 May 2012 07:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdxUCfCMjafQ; Mon, 7 May 2012 07:53:14 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id BB46721F85D0; Mon, 7 May 2012 07:53:13 -0700 (PDT) In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> To: Carl.Wuyts@technicolor.com MIME-Version: 1.0 X-KeepSent: E93A343E:CFC85FFC-852579F7:004797A4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Mon, 7 May 2012 10:52:55 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/07/2012 10:53:02, Serialize complete at 05/07/2012 10:53:02 Content-Type: multipart/alternative; boundary="=_alternative 0051C2DB852579F7_=" Received-SPF: none Cc: "v6ops@ietf.org" , v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 14:53:17 -0000 Message en plusieurs parties au format MIME --=_alternative 0051C2DB852579F7_= Content-Type: text/plain; charset="US-ASCII" > Well, if you want something in short term (like everyone seems to want, > although reality speaks against it) then I think you've to stop adding > these kind of requirements as you're making your own rules, overruling > protocol independency, ... just for the sake of getting things added. > Carl Hum... not sure I follow you Carl. You're arguing against adding a "simple 6RD sunset" requirement that would start 6RD only if DHCPv6 fails, but you're also against multihoming in the CPE. What do you suggest we do with the 6RD requirements as stated in "version 3" ? As a reminder, here's the latest version of 6RD-[4-7] (version 3): > 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces > to be active alone as well as simultaneously in order to support > coexistence of the two technologies during an incremental > migration period from 6rd to native IPv6. > > 6RD-5: Each packet sent on a 6rd or native WAN interface > MUST be directed such that its source IP address is derived > from the delegated prefix associated with the upstream > network the WAN interface is connected to [Section 4.3 [RFC3704]]. > > 6RD-6: The CE router MUST allow different as well as identical > delegated prefixes to be configured via each (6rd or native) WAN interface. > > 6RD-7: In the event that forwarding rules produce a tie between > 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. Reading this with implementor eyes, it looks like support for multihoming native IPv6 and 6RD is required, with some form of source routing. This has significant impacts on an implementor because it implies running multiple routing tables. This is basically importing ipv6-ce-transitioning requirements in 6204bis. The choices as I see them are: 1. Leave requirements 6RD-[4-7] as they were in -08 (I'm fine with it, they're vague enough to allow 6RD single-homed) 2. Adopt requirements 6RD-[4-7] like they are in v3 (with multihoming and source adress routing) 3. Drop these reqs and add new simple 6rd sunsets requirements (more delays) 4. Drop these reqs and approve 6204bis without any sunsetting requirements. Choice 2 involves some form of multihoming in the CPE. As an implementor, how do you feel implementing this? (I am asking Carl here) This basically implies adding virtual routing tables support to the CPE (VRFs in Cisco-speak) and source-routing capabilities. Not rocket science, but it is a significantly new concept to introduce in CPEs for a specification that was meant to be a short-term and incremental change to 6204. On the flip-side, as Gert just mentioned, we're likely to need it in future versions of the specs anyways. Personnally, I would be fine with option 1 and leave the requirements as they were. This is vague enough to mandate 6RD without requiring multi-homing with native and 6RD on at the same time. My second choice is 3, as it fits better my needs as an ISP, but it does add delays. I'd also be fine with a version of the requirements that do not mandate multihoming, but it sounds like what's already in -08. /JF --=_alternative 0051C2DB852579F7_= Content-Type: text/html; charset="US-ASCII"
> Well, if you want something in short term (like everyone seems to want,
> although reality speaks against it) then I think you've to stop adding
> these kind of requirements as you're making your own rules, overruling
> protocol independency, ... just for the sake of getting things added.
> Carl

Hum... not sure I follow you Carl. You're arguing against adding a
"simple 6RD sunset" requirement that would start 6RD only if DHCPv6
fails, but you're also against multihoming in the CPE. What do you
suggest we do with the 6RD requirements as stated in "version 3" ?

As a reminder, here's the latest version of 6RD-[4-7] (version 3):

> 6RD-4:  A CE router MUST allow 6rd and native IPv6 WAN interfaces
> to be active alone as well as simultaneously in order to support
> coexistence of the two technologies during an incremental
> migration period from 6rd to native IPv6.
>
> 6RD-5:  Each packet sent on a 6rd or native WAN interface
> MUST be directed such that its source IP address is derived
> from the delegated prefix associated with the upstream
> network the WAN interface is connected to [Section 4.3 [RFC3704]].
>
> 6RD-6: The CE router MUST allow different as well as identical
> delegated prefixes to be configured via each (6rd or native) WAN interface.  
>
> 6RD-7:  In the event that forwarding rules produce a tie between
> 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6.

Reading this with implementor eyes, it looks like support for multihoming
native IPv6 and 6RD is required, with some form of source routing.
This has significant impacts on an implementor because it implies
running multiple routing tables. This is basically
importing ipv6-ce-transitioning requirements in 6204bis.  

The choices as I see them are:
1. Leave requirements 6RD-[4-7] as they were in -08
   (I'm fine with it, they're vague enough to allow 6RD single-homed)
2. Adopt requirements 6RD-[4-7] like they are in v3
   (with multihoming and source adress routing)
3. Drop these reqs and add new simple 6rd sunsets requirements (more delays)
4. Drop these reqs and approve 6204bis without any sunsetting requirements.

Choice 2 involves some form of multihoming in the CPE. As an implementor,
how do you feel implementing this? (I am asking Carl here) This basically
implies adding virtual routing tables support to the CPE (VRFs in Cisco-speak)
and source-routing capabilities. Not rocket science, but it is a
significantly new concept to introduce in CPEs for a specification
that was meant to be a short-term and incremental change to 6204.
On the flip-side, as Gert just mentioned, we're likely to need it
in future versions of the specs anyways.  

Personnally, I would be fine with option 1 and leave the requirements as they were.
This is vague enough to mandate 6RD without requiring multi-homing with native and
6RD on at the same time. My second choice is 3, as it fits better my needs as an ISP,
but it does add delays. I'd also be fine with a version of the requirements
that do not mandate multihoming, but it sounds like what's already in -08.

/JF


--=_alternative 0051C2DB852579F7_=-- From despres.remi@laposte.net Mon May 7 08:30:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2C821F8642; Mon, 7 May 2012 08:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eankTdLWgGmq; Mon, 7 May 2012 08:30:12 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BF721F863F; Mon, 7 May 2012 08:30:09 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 382BD94018A; Mon, 7 May 2012 17:29:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--532373197 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 7 May 2012 17:29:55 +0200 Message-Id: <4FD5E0A3-8298-4874-A747-06CFF6E505D7@laposte.net> References: To: Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 15:30:12 -0000 --Apple-Mail-1--532373197 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Jean-Francois, Le 2012-05-07 =E0 16:52, Jean-Francois.TremblayING@videotron.com a =E9crit= : > ... >=20 > The choices as I see them are:=20 > 1. Leave requirements 6RD-[4-7] as they were in -08=20 > (I'm fine with it, they're vague enough to allow 6RD single-homed)=20= > 2. Adopt requirements 6RD-[4-7] like they are in v3=20 > (with multihoming and source adress routing)=20 > 3. Drop these reqs and add new simple 6rd sunsets requirements (more = delays) >=20 > 4. Drop these reqs and approve 6204bis without any sunsetting = requirements. Preferred choice,. When approaches for 6rd sunsetting are well enough understood, it will = be time to add whatever is appropriate. Haste while the subject is still confusing is IMHO bound to deteriorate = the otherwise good quality of 6204bis. RD >=20 >=20 > Choice 2 involves some form of multihoming in the CPE. As an = implementor,=20 > how do you feel implementing this? (I am asking Carl here) This = basically=20 > implies adding virtual routing tables support to the CPE (VRFs in = Cisco-speak)=20 > and source-routing capabilities. Not rocket science, but it is a=20 > significantly new concept to introduce in CPEs for a specification=20 > that was meant to be a short-term and incremental change to 6204.=20 > On the flip-side, as Gert just mentioned, we're likely to need it=20 > in future versions of the specs anyways. =20 >=20 > Personnally, I would be fine with option 1 and leave the requirements = as they were.=20 > This is vague enough to mandate 6RD without requiring multi-homing = with native and=20 > 6RD on at the same time. My second choice is 3, as it fits better my = needs as an ISP,=20 > but it does add delays. I'd also be fine with a version of the = requirements=20 > that do not mandate multihoming, but it sounds like what's already in = -08.=20 >=20 > /JF=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-1--532373197 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi, = Jean-Francois,

Le 2012-05-07 =E0 16:52, Jean-Francois.Trem= blayING@videotron.com a =E9crit :
...

The choices as I see them are:
1. Leave requirements 6RD-[4-7] as they were in -08
   (I'm fine with it, they're vague enough to allow 6RD single-homed)
2. Adopt requirements 6RD-[4-7] like they are in v3
   (with multihoming and source adress routing)
3. Drop these reqs and add new simple 6rd sunsets requirements (more delays)


4. Drop these reqs and approve 6204bis without any sunsetting = requirements.

Preferred = choice,.
When approaches for 6rd sunsetting are well enough = understood, it will be time to add whatever is = appropriate.

Haste while the subject is still = confusing is IMHO bound to deteriorate the otherwise good quality of = 6204bis.

RD





Choice 2 involves some form of multihoming in the CPE. As an implementor,
how do you feel implementing this? (I am asking Carl here) This basically
implies adding virtual routing tables support to the CPE (VRFs in Cisco-speak)
and source-routing capabilities. Not rocket science, but it is a
significantly new concept to introduce in CPEs for a specification
that was meant to be a short-term and incremental change to 6204.
On the flip-side, as Gert just mentioned, we're likely to need it
in future versions of the specs anyways.  

Personnally, I would be fine with option 1 and leave the requirements as they were.
This is vague enough to mandate 6RD without requiring multi-homing with native and
6RD on at the same time. My second choice is 3, as it fits better my needs as an ISP,
but it does add delays. I'd also be fine with a version of the requirements
that do not mandate multihoming, but it sounds like what's already in -08.

/JF


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

<= /html>= --Apple-Mail-1--532373197-- From mark@townsley.net Mon May 7 10:55:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D40021F864F for ; Mon, 7 May 2012 10:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AKTdPVccp2f for ; Mon, 7 May 2012 10:55:57 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5342621F864E for ; Mon, 7 May 2012 10:55:57 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3596887wgb.13 for ; Mon, 07 May 2012 10:55:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=U6hIrs25mm9djhdXaMtrijKIpIawdLro0QD5hlqGBGI=; b=AEiEXvV9RHL8U+dhFreJiuwEdT59EFzo53X+LbffFGQyHDhqFpR9rX5vusXfL0PZJQ oP+0IRDLIPLc4vavXV8otMz3279CMHVVBntVVhvUBfSHxWC2PNiR+Epen51yu/TndBe4 uJRB8Q/ZtolRGJIP7B/jXUnZNQ22xBnau6gNM/CtGsjx0FSSe//G5pshH7VK0LAAeuxO UgL9k6itv52Nw3/A3z2+ka8ZgGHLV4svmGevNg3yXGFWH56Kt/4cm2CDzn2Jd9Xa0evM aKErTF0PI5hSVUvDDvhSZ/lp2FM+izOrMtH5wvr+IvfLa6I/NoM8FZEt6rim3OaSCL+4 d92w== Received: by 10.180.88.199 with SMTP id bi7mr37351659wib.12.1336413356365; Mon, 07 May 2012 10:55:56 -0700 (PDT) Received: from [64.103.30.112] ([64.103.30.112]) by mx.google.com with ESMTPS id ex2sm36301381wib.8.2012.05.07.10.55.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 10:55:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Mark Townsley In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> Date: Mon, 7 May 2012 19:55:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQk637MNpJGMf8dD8Wo3QHYGMdhgzno1DqtsY7P8++cWbvGLTAsDU34fytntQge1msZSMXAd Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 17:55:58 -0000 There are not a lot of Retail CPE implementers on list here, but those = that are speaking up seem to have committed to implementing multihoming = between 6rd and native (at least Linksys + D-Link). We have two BCPs = (38, 84) that have been around for quite a while that we are basing = these requirements on. Even Carl whose customers really do not have the = same issue as they mostly use non-retail routers cannot say the = multihoming-based solution is wrong technically, just that he is worried = that it will somehow delay general IPv6 availability in products.=20 With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was phase one = as they defined each technology separately. By including 6rd in the = Native IPv6 CPE document, we naturally bring ourselves to phase two = where we describe how the two methods work together best. Otherwise, we = might as well just publish an update to RFC5969 for any additional 6rd = requirements, and leave 6rd out of 6204-bis entirely.=20 We're back to moving in circles though. IIRC, the Chairs already made a = consensus call on the list, and I've been posting the text they asked me = to work on here. 3 versions later plus a privately-sent tweak from Randy = Bush saying I should write "from which the packet is being sent" vs. = "the packet is being sent on" and we will have done that. At this point, = we either move forward with what the chairs asked, or continue to beat = this horse and try to get them to reverse their decision.=20 - Mark From joelja@bogus.com Mon May 7 11:15:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5316421F8671 for ; Mon, 7 May 2012 11:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0X10kv9AbFa for ; Mon, 7 May 2012 11:15:30 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B510421F866B for ; Mon, 7 May 2012 11:15:30 -0700 (PDT) Received: from wifi-208-85.mtg.afnog.org (wifi-208-85.mtg.afnog.org [196.200.208.85]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q47IFNcr030441 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 7 May 2012 18:15:28 GMT (envelope-from joelja@bogus.com) Message-ID: <4FA81137.7070907@bogus.com> Date: Mon, 07 May 2012 18:15:19 +0000 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mark Townsley References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 07 May 2012 18:15:30 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 18:15:31 -0000 On 5/7/12 17:55 , Mark Townsley wrote: > > There are not a lot of Retail CPE implementers on list here, but > those that are speaking up seem to have committed to implementing > multihoming between 6rd and native (at least Linksys + D-Link). We > have two BCPs (38, 84) that have been around for quite a while that > we are basing these requirements on. Even Carl whose customers really > do not have the same issue as they mostly use non-retail routers > cannot say the multihoming-based solution is wrong technically, just > that he is worried that it will somehow delay general IPv6 > availability in products. > > With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was phase > one as they defined each technology separately. By including 6rd in > the Native IPv6 CPE document, we naturally bring ourselves to phase > two where we describe how the two methods work together best. > Otherwise, we might as well just publish an update to RFC5969 for any > additional 6rd requirements, and leave 6rd out of 6204-bis entirely. > > > We're back to moving in circles though. IIRC, the Chairs already made > a consensus call on the list, and I've been posting the text they > asked me to work on here. 3 versions later plus a privately-sent > tweak from Randy Bush saying I should write "from which the packet is > being sent" vs. "the packet is being sent on" and we will have done > that. At this point, we either move forward with what the chairs > asked, or continue to beat this horse and try to get them to reverse > their decision. I'm sitting here waiting for an 09 version of the draft so that I can expose the diffs to the list, test whether we need to need to reconsider the WGLC, and send a shepherds report to the IESG if not. The longer temporally and the more diveregent the document gets the more likely it is imho that we need to reconsider the wg consensus on publication, but we don't know because it's not in the tool yet. > - Mark > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From gert@space.net Mon May 7 11:26:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56DA21F8697 for ; Mon, 7 May 2012 11:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oJHfxvzeM7k for ; Mon, 7 May 2012 11:26:08 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E98721F8693 for ; Mon, 7 May 2012 11:26:06 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0F688F8A99 for ; Mon, 7 May 2012 20:26:06 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E78E4F8ABB for ; Mon, 7 May 2012 20:26:05 +0200 (CEST) Received: (qmail 39983 invoked by uid 1007); 7 May 2012 20:26:05 +0200 Date: Mon, 7 May 2012 20:26:05 +0200 From: Gert Doering To: Simon Perreault Message-ID: <20120507182605.GS84425@Space.Net> References: <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <4FA7D090.30700@viagenie.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7NHomn8xhyOhjHlC" Content-Disposition: inline In-Reply-To: <4FA7D090.30700@viagenie.ca> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 18:26:09 -0000 --7NHomn8xhyOhjHlC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, May 07, 2012 at 09:39:28AM -0400, Simon Perreault wrote: > On 05/07/12 05:38, Gert Doering wrote: > > So if we want ISPs to follow BCP38 *and* support multi-ISP CPEs - then > > there is no way around proper source-address dependend routing. >=20 > Agreed. >=20 > And IMHO we should leave multihoming for homenet, and avoid source=20 > routing in 6204bis. With 6rd included, and 6rd + native potentially running in parallel, there is no way to avoid this particular issue. (And the WG already reached consensus on this in Paris, so I wonder why this is even discussed again) Gert Doering -- Voice of Reason --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --7NHomn8xhyOhjHlC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT6gTvakuBuNlUUl1AQI8BQP/Ueyz9U/qu1l18k4HyLZnDplVyC3GIEtq 3xeT9VRCZUZrc8Y+6sleH3ijKWxN4vDwdxHzzjxx/AjZWw2fgsoKDLGdnSZK5C4d bWz9y6IoTyR/wWnzPvb60uNo1bjYbop3chMKiqaAiuHX48ofvFP23KuJV3jBVls+ 9siutRHjxD0= =WZ+o -----END PGP SIGNATURE----- --7NHomn8xhyOhjHlC-- From john_brzozowski@cable.comcast.com Mon May 7 11:40:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E21B21F8636 for ; Mon, 7 May 2012 11:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=2.055, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHeks26lqBpt for ; Mon, 7 May 2012 11:40:39 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0E821F8631 for ; Mon, 7 May 2012 11:40:39 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.16327575; Mon, 07 May 2012 12:26:08 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 7 May 2012 14:40:36 -0400 From: "Brzozowski, John" To: Mark Townsley , IPv6 Operations Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNLIDjntw3Pp+SJEqbdUjzKcryYQ== Date: Mon, 7 May 2012 18:40:35 +0000 Message-ID: In-Reply-To: <00EE98BB-E1BB-4A1F-BCC3-06CADD032606@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CBCD8F1A27BD52johnbrzozowskicablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 18:40:40 -0000 --_000_CBCD8F1A27BD52johnbrzozowskicablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is the below really a requirement or a deployment choice that an operator m= ust individually manage? John From: Mark Townsley > Date: Thu, 3 May 2012 08:17:51 +0200 To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) 6RD-6: The CE router MUST allow different as well as identical delegated pr= efixes to be configured via each (6rd or native) WAN interface. --_000_CBCD8F1A27BD52johnbrzozowskicablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <58D02F00B1735D4199EAE34787610E9F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Is the below really a requirement or a deployment choice that an opera= tor must individually manage?

John
From: Mark Townsley <mark@townsley.net>
Date: Thu, 3 May 2012 08:17:51 += ;0200
To: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] 6rd sunsetting= requirements (version 3)

6RD-6: The CE router MUST allow different as well as identi= cal delegated prefixes to be configured via each (6rd or native) WAN interf= ace.  
 --_000_CBCD8F1A27BD52johnbrzozowskicablecomcastcom_-- From mark@townsley.net Mon May 7 11:43:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3CE21F8636 for ; Mon, 7 May 2012 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwBdlUDFvGpl for ; Mon, 7 May 2012 11:43:24 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 769B621F8467 for ; Mon, 7 May 2012 11:43:23 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so3074478wib.13 for ; Mon, 07 May 2012 11:43:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4x/cJ1jB2jsGzt2k3MttqnNb7BhNBG1WUY707vz9Hvk=; b=LrOVGP4oTfNXVH4UbQ7HCYQ1GexuXZvGyjSnAGCiVU7YKs/Rd3BciEGnMAelhIehM6 0r8Yztk+lS7TIrkIHO0ryHDNfGDGOi8HMarbIejAQ+X9f1g3yLWJw+k75G16gV8vL5aD my4LbQqDBXSGR7XDCGsJqgX1KoeZj2K3fLkqtd+XNWKC9e37LW75UIuZi2FPR/kLqUij 2v/lAp+wCoDAocu1SqQiBoZLXw1HB9Dev4kwhTaFbcPVA+qppy30R7U8oEmUfBoAjFcs oOaSv6p+F8srK6OGfaERCiqq+H1CzcAC0BOVVIorogT3/y8xmOzTl42NoVtKQ4zT2YDp Ve7A== Received: by 10.216.139.73 with SMTP id b51mr10625889wej.72.1336416202605; Mon, 07 May 2012 11:43:22 -0700 (PDT) Received: from [64.103.30.112] ([64.103.30.112]) by mx.google.com with ESMTPS id e6sm23466307wix.8.2012.05.07.11.43.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 11:43:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_D7441B16-5E73-400E-AE7F-77EA6412FB59" From: Mark Townsley In-Reply-To: Date: Mon, 7 May 2012 20:43:19 +0200 Message-Id: <48251716-A044-4F39-ADFB-8074580DF942@townsley.net> References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnHw23464Z581ZqaxNxiHY5jaOPT2QhZ1KSiiZEjmMRibSl7/Ax7eAe+66jEz1X10YHihfI Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 18:43:25 -0000 --Apple-Mail=_D7441B16-5E73-400E-AE7F-77EA6412FB59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is a requirement that allows a choice. - Mark On May 7, 2012, at 8:40 PM, Brzozowski, John wrote: > Is the below really a requirement or a deployment choice that an = operator must individually manage? >=20 > John > From: Mark Townsley > Date: Thu, 3 May 2012 08:17:51 +0200 > To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) >=20 >> 6RD-6: The CE router MUST allow different as well as identical = delegated prefixes to be configured via each (6rd or native) WAN = interface. =20 --Apple-Mail=_D7441B16-5E73-400E-AE7F-77EA6412FB59 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

It is a requirement that allows a choice.

- Mark

On May 7, 2012, at 8:40 PM, Brzozowski, John wrote:

Is the below really a requirement or a deployment choice that an operator must individually manage?

John
From: Mark Townsley <mark@townsley.net>
Date: Thu, 3 May 2012 08:17:51 +0200
To: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

6RD-6: The CE router MUST allow different as well as identical delegated prefixes to be configured via each (6rd or native) WAN interface.  

--Apple-Mail=_D7441B16-5E73-400E-AE7F-77EA6412FB59-- From john_brzozowski@cable.comcast.com Mon May 7 11:46:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DD321F846A for ; Mon, 7 May 2012 11:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.689 X-Spam-Level: X-Spam-Status: No, score=-103.689 tagged_above=-999 required=5 tests=[AWL=1.541, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsHWSPKmxu3f for ; Mon, 7 May 2012 11:46:34 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE021F8467 for ; Mon, 7 May 2012 11:46:34 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.16328839; Mon, 07 May 2012 12:32:03 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Mon, 7 May 2012 14:46:31 -0400 From: "Brzozowski, John" To: Mark Townsley Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNLIDjntw3Pp+SJEqbdUjzKcryYZa+7JeA//+9zYA= Date: Mon, 7 May 2012 18:46:31 +0000 Message-ID: In-Reply-To: <48251716-A044-4F39-ADFB-8074580DF942@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CBCD909227BDA1johnbrzozowskicablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 18:46:35 -0000 --_000_CBCD909227BDA1johnbrzozowskicablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does anyone know if this a popular deployment model for 6rd adopters? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://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 From: Mark Townsley > Date: Mon, 7 May 2012 20:43:19 +0200 To: John Jason Brzozowski > Cc: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) It is a requirement that allows a choice. - Mark On May 7, 2012, at 8:40 PM, Brzozowski, John wrote: Is the below really a requirement or a deployment choice that an operator m= ust individually manage? John From: Mark Townsley > Date: Thu, 3 May 2012 08:17:51 +0200 To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) 6RD-6: The CE router MUST allow different as well as identical delegated pr= efixes to be configured via each (6rd or native) WAN interface. --_000_CBCD909227BDA1johnbrzozowskicablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2342C0517F556540BF19DA82E0C07E81@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Does anyo= ne know if this a popular deployment model for 6rd adopters?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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) +1-609-377-6594
e) mailto:john_brzozowski@cable.comcast.com
o) +1-484-962-0060
w) http://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

From: Mark Townsley <mark@townsley.net>
Date: Mon, 7 May 2012 20:43:19 += ;0200
To: John Jason Brzozowski <john_brzozowski@cable.comca= st.com>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] 6rd sunsetting= requirements (version 3)


It is a requirement that allows a choice.

- Mark

On May 7, 2012, at 8:40 PM, Brzozowski, John wrote:

Is the below really a requirement or a deployment choice that an opera= tor must individually manage?

John
From: Mark Townsley <mark@townsley.net>
Date: Thu, 3 May 2012 08:17:51 += ;0200
To: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] 6rd sunsetting= requirements (version 3)

6RD-6: The CE router MUST allow different as well as identi= cal delegated prefixes to be configured via each (6rd or native) WAN interf= ace.  

 --_000_CBCD909227BDA1johnbrzozowskicablecomcastcom_-- From dr@cluenet.de Mon May 7 11:59:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A583A21F85F2 for ; Mon, 7 May 2012 11:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEid+8XSAVx5 for ; Mon, 7 May 2012 11:59:36 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id CBC1221F85E5 for ; Mon, 7 May 2012 11:59:35 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 54E6C1083D2; Mon, 7 May 2012 20:59:33 +0200 (CEST) Date: Mon, 7 May 2012 20:59:33 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120507185933.GA27623@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6110A7F88@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30496616C@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30496616C@XMB-RCD-109.cisco.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] (S)NTP in 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 18:59:36 -0000 On Fri, May 04, 2012 at 03:12:23AM -0500, Hemant Singh (shemant) wrote: > RFC 5908 defines a FQDN DHCPv6 suboption only for NTPv4 as defined in > RFC 5905. Rfc6204bis calls out for use of SNTP as defined in RFC 2030. > Anyone mind if rfc6204bis changes from RFC 2030 to RFC 5905? Good point, and agreed to the change. 2030 got obsoleted by 4330 which in turn got obsoleted by 5905 as 5905 includes SNTPv4. Consequently replacing the 2030 with a 5905 reference seems to be correct. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From bs7652@att.com Mon May 7 12:01:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6370F21F864E for ; Mon, 7 May 2012 12:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=1.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SckLqIoSZgy9 for ; Mon, 7 May 2012 12:01:08 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9111721F8639 for ; Mon, 7 May 2012 12:01:00 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id ceb18af4.5bee4940.274058.00-588.744350.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 07 May 2012 19:01:00 +0000 (UTC) X-MXL-Hash: 4fa81bec7748ef01-68295dea685b822386b9a92413a60e77af5d61dd Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 4eb18af4.0.273986.00-426.744127.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 07 May 2012 19:00:53 +0000 (UTC) X-MXL-Hash: 4fa81be55c97ce89-b5ad154eab420ff8cf7eec8defdb4f38d982f0df 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 q47J0qjH013921; Mon, 7 May 2012 15:00:52 -0400 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 q47J0bgi013215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 15:00:45 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint03.pst.cso.att.com (RSA Interceptor); Mon, 7 May 2012 15:00:04 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.81]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.01.0355.002; Mon, 7 May 2012 15:00:03 -0400 From: "STARK, BARBARA H" To: "Brzozowski, John" , Mark Townsley Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNKPSFHaTi59li002JhDEAyFznTpa+8uyAgAAAw4CAAADlgP//vZFQ Date: Mon, 7 May 2012 19:00:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110C1047@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <48251716-A044-4F39-ADFB-8074580DF942@townsley.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.164.202.31] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6110C1047GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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=1.0 c=1 a=LnSh8mvAXcUA:10 a=KJxBHbnaG1YA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=6MyZ0KW2AAAA:8 a=wrju9itlAAAA:8 a=2okMGNwhA] X-AnalysisOut: [AAA:8 a=Ev2WcxREpYjYN7rGUsAA:9 a=CjuIK1q_8ugA:10 a=42WgJn5] X-AnalysisOut: [DhlwA:10 a=Q09VHgBEdo0A:10 a=lZB815dzVvQA:10 a=GPDuAuAC4SA] X-AnalysisOut: [A:10 a=6rFbIz0_u-GWpF8K:21 a=TFSOfqrfdc0zmvhv:21 a=yMhMjlu] X-AnalysisOut: [bAAAA:8 a=SSmOFEACAAAA:8 a=zuxAW8gs4fEqINon3E4A:9 a=0tKVhh] X-AnalysisOut: [FjHZJayKzy6PwA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZ] X-AnalysisOut: [eC7Yk6K0A:10 a=jA9qIAFiuiPrkhh1:21 a=A_1JiRD2MBSh39wZ:21] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 19:01:11 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6110C1047GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not clear as to which of the two options you're asking about. But it's = moot; the options are not for 6rd deployment models. They're for "6rd to na= tive IPv6" transition models. To the best of my knowledge, nobody has deplo= yed either such transition. I would guess that transition is far enough out= that both options are being assessed to determine which has the lesser ope= rational complexity. Operational complexity includes the amount of network = coordination needed, complexity of network element software, as well as the= potential call volume if customers find the transition to be noticeable. I= don't think operational complexity of either option has been fully determi= ned yet. But we might be able to influence an answer to the operational complexity q= uestion, by not including support for one or the other option in the CE rou= ter. Based, hopefully, on what is easier for the CE router. Barbara From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of B= rzozowski, John Sent: Monday, May 07, 2012 2:47 PM To: Mark Townsley Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) Does anyone know if this a popular deployment model for 6rd adopters? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://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 From: Mark Townsley > Date: Mon, 7 May 2012 20:43:19 +0200 To: John Jason Brzozowski > Cc: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) It is a requirement that allows a choice. - Mark On May 7, 2012, at 8:40 PM, Brzozowski, John wrote: Is the below really a requirement or a deployment choice that an operator m= ust individually manage? John From: Mark Townsley > Date: Thu, 3 May 2012 08:17:51 +0200 To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) 6RD-6: The CE router MUST allow different as well as identical delegated pr= efixes to be configured via each (6rd or native) WAN interface. --_000_2D09D61DDFA73D4C884805CC7865E6110C1047GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not clear as to which of the = two options you’re asking about. But it’s moot; the options are= not for 6rd deployment models. They’re for “6rd to native IPv6= ” transition models. To the best of my knowledge, nobody has deployed either such trans= ition. I would guess that transition is far enough out that both options ar= e being assessed to determine which has the lesser operational complexity. = Operational complexity includes the amount of network coordination needed, complexity of network element s= oftware, as well as the potential call volume if customers find the transit= ion to be noticeable. I don’t think operational complexity of either = option has been fully determined yet.

 

But we might be able to influence an an= swer to the operational complexity question, by not including support for o= ne or the other option in the CE router. Based, hopefully, on what is easier for the CE router.

Barbara

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brzozowski, John
Sent: Monday, May 07, 2012 2:47 PM
To: Mark Townsley
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

 

Does anyone know if this a popular deployment model for = 6rd adopters?

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=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<= /o:p>

Comcast Cable

m) +1-609-377-6594=

o) +1-484-962-0060=

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

From: Mark Townsley <mark@townsley.net>
Date: Mon, 7 May 2012 20:43:19 +0200
To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
Cc: IPv6 Operations <v6ops@ietf= .org>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

 

 

It is a requirement that al= lows a choice.

 

- Mark

 

On May 7, 2012, at 8:40 PM,= Brzozowski, John wrote:



Is the below really a requi= rement or a deployment choice that an operator must individually manage?

 

John

From: Mark Townsley <mark@townsley.net>
Date: Thu, 3 May 2012 08:17:51 +0200
To: IPv6 Operations <v6ops@ietf= .org>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

 

6RD-6: The CE= router MUST allow different as well as identical delegated prefixes to be = configured via each (6rd or native) WAN interface.  

 

--_000_2D09D61DDFA73D4C884805CC7865E6110C1047GAALPA1MSGUSR9NIT_-- From Jean-Francois.TremblayING@videotron.com Mon May 7 12:08:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1EB21F86D3; Mon, 7 May 2012 12:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX32M+7Occ7R; Mon, 7 May 2012 12:08:09 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5B43D21F8613; Mon, 7 May 2012 12:08:09 -0700 (PDT) In-Reply-To: To: mark@townsley.net MIME-Version: 1.0 X-KeepSent: A24FFE93:893226E5-852579F7:00643D58; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Mon, 7 May 2012 15:07:55 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 05/07/2012 15:08:03, Serialize complete at 05/07/2012 15:08:03 Content-Type: multipart/alternative; boundary="=_alternative 00691B6B852579F7_=" Received-SPF: none Cc: IPv6 Operations , v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 19:08:10 -0000 Message en plusieurs parties au format MIME --=_alternative 00691B6B852579F7_= Content-Type: text/plain; charset="US-ASCII" Mark, I agree that: - Multihoming is probably the desirable long-term solution - This needs to move forward We seem to disagree on : - the committment of D-Link - the consensus on the list. Many participants on this list asked for the consensus to be verified for the new "version 3" text, the version in which multi-homing suddenly became a MUST. The verification of this consensus hasn't been done yet. Again, I am not willing to beat an already dead horse more than needed. However 4 ISPs have already stated they have reserves about this new text. In my opinion this is a significant challenge. That said, I have stated my arguments, I'll now wait for the consensus call (or the lack of). /JF > There are not a lot of Retail CPE implementers on list here, > but those that are speaking up seem to have committed to > implementing multihoming between 6rd and native (at least > Linksys + D-Link). We have two BCPs (38, 84) that have been > around for quite a while that we are basing these requirements > on. Even Carl whose customers really do not have the same issue > as they mostly use non-retail routers cannot say the > multihoming-based solution is wrong technically, just that he > is worried that it will somehow delay general IPv6 availability in products. > > With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was > phase one as they defined each technology separately. By including > 6rd in the Native IPv6 CPE document, we naturally bring ourselves > to phase two where we describe how the two methods work together > best. Otherwise, we might as well just publish an update to > RFC5969 for any additional 6rd requirements, and leave 6rd out > of 6204-bis entirely. > > We're back to moving in circles though. IIRC, the Chairs already made > a consensus call on the list, and I've been posting the text > they asked me to work on here. 3 versions later plus a > privately-sent tweak from Randy Bush saying I should write > "from which the packet is being sent" vs. "the packet is being > sent on" and we will have done that. At this point, we either > move forward with what the chairs asked, or continue to beat > this horse and try to get them to reverse their decision. > > - Mark --=_alternative 00691B6B852579F7_= Content-Type: text/html; charset="US-ASCII"
Mark,
I agree that:
- Multihoming is probably the desirable long-term solution
- This needs to move forward

We seem to disagree on :
- the committment of D-Link
- the consensus on the list. Many participants on this list
asked for the consensus to be verified for the new "version 3"
text, the version in which multi-homing suddenly became a MUST.
The verification of this consensus hasn't been done yet.

Again, I am not willing to beat an already dead horse more than
needed. However 4 ISPs have already stated they have reserves about
this new text. In my opinion this is a significant challenge.
That said, I have stated my arguments, I'll now wait for the
consensus call (or the lack of).

/JF

> There are not a lot of Retail CPE implementers on list here,
> but those that are speaking up seem to have committed to
> implementing multihoming between 6rd and native (at least
> Linksys + D-Link). We have two BCPs (38, 84) that have been
> around for quite a while that we are basing these requirements
> on. Even Carl whose customers really do not have the same issue
> as they mostly use non-retail routers cannot say the
> multihoming-based solution is wrong technically, just that he
> is worried that it will somehow delay general IPv6 availability in products.
>
> With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was
> phase one as they defined each technology separately. By including
> 6rd in the Native IPv6 CPE document, we naturally bring ourselves
> to phase two where we describe how the two methods work together
> best. Otherwise, we might as well just publish an update to
> RFC5969 for any additional 6rd requirements, and leave 6rd out
> of 6204-bis entirely.
>
> We're back to moving in circles though. IIRC, the Chairs already made
> a consensus call on the list, and I've been posting the text
> they asked me to work on here. 3 versions later plus a
> privately-sent tweak from Randy Bush saying I should write
> "from which the packet is being sent" vs. "the packet is being
> sent on" and we will have done that. At this point, we either
> move forward with what the chairs asked, or continue to beat
> this horse and try to get them to reverse their decision.
>
> - Mark
 --=_alternative 00691B6B852579F7_=-- From simon.perreault@viagenie.ca Mon May 7 12:23:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596C321F8657 for ; Mon, 7 May 2012 12:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGtTqM+lfAUk for ; Mon, 7 May 2012 12:23:31 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2F44721F863E for ; Mon, 7 May 2012 12:23:30 -0700 (PDT) Received: from [IPv6:2607:fa48:94:201:8da1:52bd:24aa:2520] (unknown [IPv6:2607:fa48:94:201:8da1:52bd:24aa:2520]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4DFE9400F0; Mon, 7 May 2012 15:23:29 -0400 (EDT) Message-ID: <4FA82130.3090107@viagenie.ca> Date: Mon, 07 May 2012 15:23:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gert Doering References: <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <4FA7D090.30700@viagenie.ca> <20120507182605.GS84425@Space.Net> In-Reply-To: <20120507182605.GS84425@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 19:23:32 -0000 On 2012-05-07 14:26, Gert Doering wrote: >> And IMHO we should leave multihoming for homenet, and avoid source >> routing in 6204bis. > > With 6rd included, and 6rd + native potentially running in parallel, > there is no way to avoid this particular issue. The point here is to not run 6rd and native in parallel. The "poor man's sunsetting" is to run 6rd only when native is unavailable. > (And the WG already reached consensus on this in Paris, so I wonder why > this is even discussed again) I didn't remember any discussion on this issue in Paris, so I went and looked at the minutes. Seems like it was not discussed in Paris. Here are the full minutes: > Second presentation - RFC 6204 bis > http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-11.pdf > > Ole T - DHCP fix going on in dhc WG > > > Fred B - regarding M/O bits read all discussion and take it up in 3315bis > > Francis D - w 6/7 remove them. > > Question, ready for last call? > > Answer - hum, (some in favor) (no opposed) > > Question - no one prefers 6rd to native? > > Answer - native prefered > > Fred B - My perception is that we await an updated draft that deals with > the issues highlighted and we can run through a last call and be ready > to ship. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From john_brzozowski@cable.comcast.com Mon May 7 14:04:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1DE21F84DE for ; Mon, 7 May 2012 14:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.997 X-Spam-Level: X-Spam-Status: No, score=-103.997 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlvveeYvHKWe for ; Mon, 7 May 2012 14:04:37 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id CCD4521F8557 for ; Mon, 7 May 2012 14:04:36 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.16359044; Mon, 07 May 2012 14:50:05 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 7 May 2012 17:04:34 -0400 From: "Brzozowski, John" To: "STARK, BARBARA H" , Mark Townsley Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNLIDjntw3Pp+SJEqbdUjzKcryYZa+7JeA//+9zYCAAEbfgP//37SA Date: Mon, 7 May 2012 21:04:32 +0000 Message-ID: In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110C1047@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CBCDB07927C2DEjohnbrzozowskicablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 21:04:38 -0000 --_000_CBCDB07927C2DEjohnbrzozowskicablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Barbara, My original email pertained to the following: 6RD-6: The CE router MUST allow different as well as identical delegated pr= efixes to be configured via each (6rd or native) WAN interface. >From someone who has not adopted 6rd, has no plans to, but has used the sam= e for trial this seems like it could add complexity. 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) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://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 From: Barbara Stark > Date: Mon, 7 May 2012 19:00:03 +0000 To: John Jason Brzozowski >, Mark Townsley > Cc: IPv6 Operations > Subject: RE: [v6ops] 6rd sunsetting requirements (version 3) I=92m not clear as to which of the two options you=92re asking about. But i= t=92s moot; the options are not for 6rd deployment models. They=92re for = =936rd to native IPv6=94 transition models. To the best of my knowledge, no= body has deployed either such transition. I would guess that transition is = far enough out that both options are being assessed to determine which has = the lesser operational complexity. Operational complexity includes the amou= nt of network coordination needed, complexity of network element software, = as well as the potential call volume if customers find the transition to be= noticeable. I don=92t think operational complexity of either option has be= en fully determined yet. But we might be able to influence an answer to the operational complexity q= uestion, by not including support for one or the other option in the CE rou= ter. Based, hopefully, on what is easier for the CE router. Barbara From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Brzozowski, John Sent: Monday, May 07, 2012 2:47 PM To: Mark Townsley Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) Does anyone know if this a popular deployment model for 6rd adopters? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://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 From: Mark Townsley > Date: Mon, 7 May 2012 20:43:19 +0200 To: John Jason Brzozowski > Cc: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) It is a requirement that allows a choice. - Mark On May 7, 2012, at 8:40 PM, Brzozowski, John wrote: Is the below really a requirement or a deployment choice that an operator m= ust individually manage? John From: Mark Townsley > Date: Thu, 3 May 2012 08:17:51 +0200 To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) 6RD-6: The CE router MUST allow different as well as identical delegated pr= efixes to be configured via each (6rd or native) WAN interface. --_000_CBCDB07927C2DEjohnbrzozowskicablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <41D4A826CC1C294F9663CD498694F36F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Barbara,=

My origi= nal email pertained to the following:

6RD-6: The CE router MUST allow differe= nt as well as identical delegated prefixes to be configured via each (6rd o= r native) WAN interface.  

From someone who has not adopted 6rd, has no plans= to, but has used the same for trial this seems like it could add complexit= y.

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) +1-609-377-6594
e) mailto:john_brzozowski@cable.comcast.com
o) +1-484-962-0060
w) http://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

From: Barbara Stark <bs7652@att.com>
Date: Mon, 7 May 2012 19:00:03 += ;0000
To: John Jason Brzozowski <john_brzozowski@cable.comca= st.com>, Mark Townsley <mark= @townsley.net>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: RE: [v6ops] 6rd sunsetting= requirements (version 3)

I=92m not clear as to which of the two options you=92re ask= ing about. But it=92s moot; the options are not for 6rd deployment models. = They=92re for =936rd to native IPv6=94 transition models. To the best of my knowledge, nobody has deployed either such trans= ition. I would guess that transition is far enough out that both options ar= e being assessed to determine which has the lesser operational complexity. = Operational complexity includes the amount of network coordination needed, complexity of network element s= oftware, as well as the potential call volume if customers find the transit= ion to be noticeable. I don=92t think operational complexity of either opti= on has been fully determined yet.

 

But we might be able to influence an answer to the operatio= nal complexity question, by not including support for one or the other opti= on in the CE router. Based, hopefully, on what is easier for the CE router.

Barbara

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brzozowski, John
Sent: Monday, May 07, 2012 2:47 PM
To: Mark Townsley
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

 

D= oes anyone know if this a popular deployment model for 6rd adopters?=

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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) +1-609-377-6594

o) +1-484-962-0060

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

From: Mark Townsley <ma= rk@townsley.net>
Date: Mon, 7 May 2012 20:43:19 +0200
To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
Cc: IPv6 Operations <v6ops@ietf= .org>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

 

 

It is a requirement that allows a choice.

 

- Mark

 

On May 7, 2012, at 8:40 PM, Brzozowski, John = wrote:



Is the below really a requirement or a deploy= ment choice that an operator must individually manage?

 

John

From: Mark Townsley <ma= rk@townsley.net>
Date: Thu, 3 May 2012 08:17:51 +0200
To: IPv6 Operations <v6ops@ietf= .org>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

 

6RD-6: The CE ro= uter MUST allow different as well as identical delegated prefixes to be con= figured via each (6rd or native) WAN interface.  

 

 --_000_CBCDB07927C2DEjohnbrzozowskicablecomcastcom_-- From mark@townsley.net Mon May 7 14:59:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088A121F865B for ; Mon, 7 May 2012 14:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcuBw0YkpW2b for ; Mon, 7 May 2012 14:59:34 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAF21F8659 for ; Mon, 7 May 2012 14:59:33 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3746294wgb.13 for ; Mon, 07 May 2012 14:59:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qHXwZq6hncX+Nv71/ZVLlVN8ZpYs9Kruyd+1BwjvcEg=; b=Zh+yR0uW6zhJO0JFgBNUhWJXBdxtWbS3n0rqUbSIOp26iLDiF8Ymb7fVWX7I4Qizth fg1Jl3OCt6MYau0mdeF7Q0s7X+pH8bK2lTUhHsoIxug5SLwbVxdcWPl2yl7g2U5yCbXv MLYUyAkco4Hp9vVM7ry8wRl42VB7oMyY76fimIrgpP8rGbcwdy7blVHJjhD5mFoMLfgO k7gmB5Kr7A1evVzLTJExZIYySyHfVvd+TAVDjc2mxMwzCxePHEFk9DtEOd/q2kiFmub5 sOaMTwRwc2BFDl5U5GfpZHRIwiLUiA6X6dlP0Yuu5n8mhGiw7NYiMhY3M2mvnAki1s5j qAkQ== Received: by 10.180.93.38 with SMTP id cr6mr8750687wib.16.1336427973104; Mon, 07 May 2012 14:59:33 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id bn9sm7530814wib.5.2012.05.07.14.59.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 14:59:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4FA82130.3090107@viagenie.ca> Date: Mon, 7 May 2012 23:59:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <4FA7D090.30700@viagenie.ca> <20120507182605.GS84425@Space.Net> <4FA82130.3090107@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlPC6u4a+0Q6upauv+VmDPeqQBcN8CLvWqAdZCLASa9pqacFnYtpCUYQ/pjgcpxZE3qS0Xe Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 21:59:35 -0000 On May 7, 2012, at 9:23 PM, Simon Perreault wrote: > On 2012-05-07 14:26, Gert Doering wrote: >>> And IMHO we should leave multihoming for homenet, and avoid source >>> routing in 6204bis. >>=20 >> With 6rd included, and 6rd + native potentially running in parallel, >> there is no way to avoid this particular issue. >=20 > The point here is to not run 6rd and native in parallel. The "poor = man's sunsetting" is to run 6rd only when native is unavailable. >=20 >> (And the WG already reached consensus on this in Paris, so I wonder = why >> this is even discussed again) >=20 > I didn't remember any discussion on this issue in Paris, so I went and = looked at the minutes. Seems like it was not discussed in Paris. Here = are the full minutes: I spent at least 40 minutes on it at the start of the second meeting, = before 6204-bis.=20 - Mark >=20 >> Second presentation - RFC 6204 bis >> = http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-11.pdf >>=20 >> Ole T - DHCP fix going on in dhc WG >>=20 >>=20 >> Fred B - regarding M/O bits read all discussion and take it = up in 3315bis >>=20 >> Francis D - w 6/7 remove them. >>=20 >> Question, ready for last call? >>=20 >> Answer - hum, (some in favor) (no opposed) >>=20 >> Question - no one prefers 6rd to native? >>=20 >> Answer - native prefered >>=20 >> Fred B - My perception is that we await an updated draft = that deals with >> the issues highlighted and we can run through a last call = and be ready >> to ship. >=20 > Simon > --=20 > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Mon May 7 16:10:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9CD21F8690 for ; Mon, 7 May 2012 16:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.324 X-Spam-Level: X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RKnVrY9Gm7G for ; Mon, 7 May 2012 16:10:24 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0BD21F8686 for ; Mon, 7 May 2012 16:10:23 -0700 (PDT) Received: by wibhq2 with SMTP id hq2so67356wib.13 for ; Mon, 07 May 2012 16:10:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=MBmOIJ80qoV0xU9IoBIvAHoipIDD/PwYqCsvJwTZc3c=; b=nV83zwQwxzrRTB4/zCm0tH2ZqdJe2giBxCmHZQ5CXBzFFxxzox7LIp8l5obmNH2QcR aviChjuqlMZbN/06uZSLN9I/F7JVmsogDpI8uGIJWWd7BYCZbvI5pufob3ofIWREplol W2WgqA0JGce/POsUlBfGSsQoo5+T2UwiS2YBp4KVm0/sPDz0I7XxT/A5Gky1SSLZNnlq ubYApEytEI6aHt2Q+zHJZ+iuK35WC3LWljmLaMX/H0OWyYZp/x5oecCGZsvejyZww3io v54HahvQq3Ay6XOzq5PiQJzEMnVGdl64DukJmCre+dXoKPeW42+u+C7iI41nNWD2YA94 7EYw== Received: by 10.180.101.230 with SMTP id fj6mr39417698wib.13.1336432223185; Mon, 07 May 2012 16:10:23 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id o9sm2127595wia.3.2012.05.07.16.10.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 16:10:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_AD533ED3-27F0-4412-A447-ED4EBADFD47D" From: Mark Townsley In-Reply-To: Date: Tue, 8 May 2012 01:10:08 +0200 Message-Id: References: To: Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnKCc6U1AIXihXER9UardSjIXLhfAUbgObGrM9K3BVv6RpAblfA0wb+1jDkb+BHNmYfs29N Cc: IPv6 Operations , v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 May 2012 23:10:25 -0000 --Apple-Mail=_AD533ED3-27F0-4412-A447-ED4EBADFD47D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 7, 2012, at 9:07 PM, Jean-Francois.TremblayING@videotron.com = wrote: >=20 > Mark,=20 > I agree that:=20 > - Multihoming is probably the desirable long-term solution=20 Great! I think we agree more than disagree, at least at this technical = level. So, where we are *right now* in terms of what's out there? - We have RFC = 5969 and RFC 6204 implementations on the shelves and more and more = coming. There are likely a variety of ways these are implemented = side-by-side among various vendors.=20 6204-bis gives us a chance such that by the time the 6rd is actually = being sunset, we have some level of consistency in the field that gives = operators the most flexibility. If we ignore this, then we haven't = really moved the status quo very far at all. Why let CPE vendors off the = hook here? > - This needs to move forward=20 >=20 > We seem to disagree on :=20 > - the committment of D-Link=20 > - the consensus on the list. Many participants on this list=20 > asked for the consensus to be verified for the new "version 3"=20 > text, the version in which multi-homing suddenly became a MUST.=20 > The verification of this consensus hasn't been done yet.=20 version 1 was not intended to be any "lighter" on multihoming that = version 3. I was happy with version 1 though, we got to 3 based on list = comments and text provided by Chris Donley. > Again, I am not willing to beat an already dead horse more than=20 > needed. However 4 ISPs have already stated they have reserves about=20 > this new text. > In my opinion this is a significant challenge.=20 What I am hearing are operators that either think it is not necessary = because they don't mind a user having to type in configuration, or they = have direct CPE management, or they believe forced single-homing is = easier for the CPE vendors to implement. I am not hearing it will not = work operationally.=20 - Mark > That said, I have stated my arguments, I'll now wait for the=20 > consensus call (or the lack of).=20 >=20 > /JF=20 >=20 > > There are not a lot of Retail CPE implementers on list here,=20 > > but those that are speaking up seem to have committed to=20 > > implementing multihoming between 6rd and native (at least=20 > > Linksys + D-Link). We have two BCPs (38, 84) that have been=20 > > around for quite a while that we are basing these requirements=20 > > on. Even Carl whose customers really do not have the same issue=20 > > as they mostly use non-retail routers cannot say the=20 > > multihoming-based solution is wrong technically, just that he=20 > > is worried that it will somehow delay general IPv6 availability in = products.=20 > >=20 > > With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was=20 > > phase one as they defined each technology separately. By including=20= > > 6rd in the Native IPv6 CPE document, we naturally bring ourselves=20 > > to phase two where we describe how the two methods work together=20 > > best. Otherwise, we might as well just publish an update to=20 > > RFC5969 for any additional 6rd requirements, and leave 6rd out=20 > > of 6204-bis entirely.=20 > >=20 > > We're back to moving in circles though. IIRC, the Chairs already = made=20 > > a consensus call on the list, and I've been posting the text=20 > > they asked me to work on here. 3 versions later plus a=20 > > privately-sent tweak from Randy Bush saying I should write=20 > > "from which the packet is being sent" vs. "the packet is being=20 > > sent on" and we will have done that. At this point, we either=20 > > move forward with what the chairs asked, or continue to beat=20 > > this horse and try to get them to reverse their decision.=20 > >=20 > > - Mark --Apple-Mail=_AD533ED3-27F0-4412-A447-ED4EBADFD47D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On May 7, 2012, at 9:07 PM, Jean-Francois.TremblayING@videotron.com wrote:


Mark,
I agree that:
- Multihoming is probably the desirable long-term solution

Great! I think we agree more than disagree, at least at this technical level.

So, where we are *right now* in terms of what's out there? - We have RFC 5969 and RFC 6204 implementations on the shelves and more and more coming. There are likely a variety of ways these are implemented side-by-side among various vendors. 

6204-bis gives us a chance such that by the time the 6rd is actually being sunset, we have some level of consistency in the field that gives operators the most flexibility.  If we ignore this, then we haven't really moved the status quo very far at all. Why let CPE vendors off the hook here?

- This needs to move forward 

We seem to disagree on :
- the committment of D-Link
- the consensus on the list. Many participants on this list
asked for the consensus to be verified for the new "version 3"
text, the version in which multi-homing suddenly became a MUST.
The verification of this consensus hasn't been done yet. 

version 1 was not intended to be any "lighter" on multihoming that version 3. I was happy with version 1 though, we got to 3 based on list comments and text provided by Chris Donley.

Again, I am not willing to beat an already dead horse more than
needed. However 4 ISPs have already stated they have reserves about
this new text.
In my opinion this is a significant challenge.

What I am hearing are operators that either think it is not necessary because they don't mind a user having to type in configuration, or they have direct CPE management, or they believe forced single-homing is easier for the CPE vendors to implement. I am not hearing it will not work operationally. 

- Mark

That said, I have stated my arguments, I'll now wait for the
consensus call (or the lack of).

/JF

> There are not a lot of Retail CPE implementers on list here,
> but those that are speaking up seem to have committed to
> implementing multihoming between 6rd and native (at least
> Linksys + D-Link). We have two BCPs (38, 84) that have been
> around for quite a while that we are basing these requirements
> on. Even Carl whose customers really do not have the same issue
> as they mostly use non-retail routers cannot say the
> multihoming-based solution is wrong technically, just that he
> is worried that it will somehow delay general IPv6 availability in products.
>
> With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was
> phase one as they defined each technology separately. By including
> 6rd in the Native IPv6 CPE document, we naturally bring ourselves
> to phase two where we describe how the two methods work together
> best. Otherwise, we might as well just publish an update to
> RFC5969 for any additional 6rd requirements, and leave 6rd out
> of 6204-bis entirely.
>
> We're back to moving in circles though. IIRC, the Chairs already made
> a consensus call on the list, and I've been posting the text
> they asked me to work on here. 3 versions later plus a
> privately-sent tweak from Randy Bush saying I should write
> "from which the packet is being sent" vs. "the packet is being
> sent on" and we will have done that. At this point, we either
> move forward with what the chairs asked, or continue to beat
> this horse and try to get them to reverse their decision.
>
> - Mark

--Apple-Mail=_AD533ED3-27F0-4412-A447-ED4EBADFD47D-- From mark@townsley.net Mon May 7 16:29:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0AC21F8692 for ; Mon, 7 May 2012 16:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8qJyehVLnSb for ; Mon, 7 May 2012 16:29:20 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7C78821F8691 for ; Mon, 7 May 2012 16:29:20 -0700 (PDT) Received: by wibhq2 with SMTP id hq2so75017wib.13 for ; Mon, 07 May 2012 16:29:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=YLo+60haDUZMmuTN8hRbIsoA5KAH2Vx0rEdyHUC3juY=; b=WCOk74V/321xEEC5VyAE43ZLJXLSJm6KgtLjkT6nGfq9j9PS6qxlPI42sGsWw+UvCH l4XTsNDWHsISQyH43sCaJih+9/o0J5yBQCR00DL66vI4H18SW6y9OA9lOZy7T76zVySn GkoC5lBoYsuG+qaCwqb6VFEFpfZBFm1vwkYNDbdTEy+8ra3SRtPDAS1eCcL/ni71nW7s gO5QuFtzWDcrJWt9TSCc/RF0KOKa04rzIgTe6+X2XgHSR6lVgpAYo9xxgZhstFKbdTW/ iRIiONeUgrRW8Czkyrc0z6DR9Igg+w7nrc2mRipvmuHo1X3ILHXC5ENtwRsh/bG3h2fp WY0w== Received: by 10.180.98.8 with SMTP id ee8mr39581173wib.14.1336433359620; Mon, 07 May 2012 16:29:19 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id u9sm25111006wix.0.2012.05.07.16.29.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 16:29:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <4FA81137.7070907@bogus.com> Date: Tue, 8 May 2012 01:29:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <4FA81137.7070907@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlyhTjvLtv44NGsLMBuv1KPqPi1ffk8YVtV/1XQwh3beO58dkO+/xtfpfbsY8bJk/xo36nw Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (for -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: Mon, 07 May 2012 23:29:21 -0000 On May 7, 2012, at 8:15 PM, Joel jaeggli wrote: > I'm sitting here waiting for an 09 version of the draft so that I can > expose the diffs to the list, test whether we need to need to = reconsider > the WGLC, and send a shepherds report to the IESG if not. The longer > temporally and the more diveregent the document gets the more likely = it > is imho that we need to reconsider the wg consensus on publication, = but > we don't know because it's not in the tool yet. Here are the latest requirements that Chris, Hemant, Wes and I finally = agreed upon (posted at "version 3" the other day), plus the specific = text changes to 6RD-5 as suggested by Gert and Randy. I believe Hemant = has the draft pen.=20 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to be = active alone as well as simultaneously in order to support coexistence = of the two technologies during an incremental migration period from 6rd = to native IPv6.=20 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that the packet's source IP address is derived from a = delegated prefix associated with the particular interface from which the = packet is being sent [Section 4.3 [RFC3704]]. 6RD-6: The CE router MUST allow different as well as identical delegated = prefixes to be configured via each (6rd or native) WAN interface. =20 6RD-7: In the event that forwarding rules produce a tie between 6rd and = native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. From internet-drafts@ietf.org Mon May 7 18:21:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC3D21F8634; Mon, 7 May 2012 18:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZFboiIF+ESx; Mon, 7 May 2012 18:21:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71ED821F84A7; Mon, 7 May 2012 18:21:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120508012117.23302.51227.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 18:21:17 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 01:21:19 -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-03.txt Pages : 15 Date : 2012-05-07 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 mobile and wireline IPv6-only edge networks without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ From kawashimam@vx.jp.nec.com Mon May 7 18:25:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F721F85F2 for ; Mon, 7 May 2012 18:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+bjWQZreRni for ; Mon, 7 May 2012 18:25:08 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 021A821F845B for ; Mon, 7 May 2012 18:25:07 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q481P7Zn020685 for ; Tue, 8 May 2012 10:25:07 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q481P7d28823 for v6ops@ietf.org; Tue, 8 May 2012 10:25:07 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id q481P6eB026696 for ; Tue, 8 May 2012 10:25:06 +0900 (JST) Received: from yonosuke.jp.nec.com ([10.26.220.15] [10.26.220.15]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-980547; Tue, 8 May 2012 10:24:29 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Tue, 8 May 2012 10:24:27 +0900 To: v6ops@ietf.org In-reply-to: <20120508012117.23302.51227.idtracker@ietfa.amsl.com> Message-Id: <20120508102426kawashimam@mail.jp.nec.com> References: <20120508012117.23302.51227.idtracker@ietfa.amsl.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Tue, 8 May 2012 10:24:22 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 01:25:09 -0000 Folks, We have published draft-ietf-v6ops-464xlat-03. Can we move forward to WGLC? Changes are: - Section 7.5. IPv6 Prefix Handling - Clarified the language. - Added new section "7.6. Relationship between CLAT and NAT44" Regards, Masanobu > >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 : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-03.txt > Pages : 15 > Date : 2012-05-07 > > 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 mobile and wireline IPv6-only edge networks without > encapsulation. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt > >The IETF datatracker page for this Internet-Draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From Carl.Wuyts@technicolor.com Mon May 7 23:05:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E17721F85BB; Mon, 7 May 2012 23:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.542 X-Spam-Level: X-Spam-Status: No, score=-5.542 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD7xh9+VrG6R; Mon, 7 May 2012 23:05:48 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 86DDE21F8581; Mon, 7 May 2012 23:05:46 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKT6i3uYwxcFQG1Okuc6YyYXIVtje0GnwB@postini.com; Mon, 07 May 2012 23:05:48 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 8 May 2012 08:03:29 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 8 May 2012 08:03:37 +0200 From: Wuyts Carl To: "Jean-Francois.TremblayING@videotron.com" Date: Tue, 8 May 2012 08:03:35 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: Ac0sYR7Q11U6FRDVTFKgcQnnb8zJrAAfFSyw Message-ID: <867F4B6A1672E541A94676D556793ACD10E2185CAF@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD10E2185CAFMOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 06:05:53 -0000 --_000_867F4B6A1672E541A94676D556793ACD10E2185CAFMOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable @ Jean-Francois. Main q seems to be: "what do l want on these "simple" sunsetting requiremen= ts/rfc6204bis ?" 1. I want to avoid reqs are being added over and over again, so draw = a line and allow the CPE vendors to become compliant with some set. I read= "delay", but the delay is there because of the adding. 2. If reqs are added, don't link protocols together. Avoid having to= do X when condition Y is met. DHCPv6 and 6rd are not linked directly. Yo= ur suggestion below: if DHCPv6 fails, then start 6rd ? But you in this cas= e even make the assumption that the ISP has something running for 6rd (from= my view, some have, some don't, but you refer always to retail, so unknown= to what ISP to connect) ? You also need DHCPv4 for the option 212, or sho= uld it launch automatically some static 6rd tunnel (to what destination ?).= This is a generic concern from my end. The company I work for is not ope= rational in retail, so deploying in a managed model, hence this issue not e= ven presents itself in reality for us, but protocol independency is very im= portant (mainly for simplicity) 3. 6204 targets single home, let's keep it like this TODAY (maybe it = needs new attention later on). Single-homed 6rd "sunsetting" is not an iss= ue at all, so let's stick to the simple requirements initially added, as it= will already be hard enough to cope with it. What about vrf and things like that. One must be careful to make compariso= n. You can hardly compare a Cisco CPE with a standard residential CPE, as = this is no fair comparison. Should/must the CPE be full VR-capable or som= ething alike it (using some labels or something to mimic it), be able to do= some source-routing things, .... In the near future ? I don't know of co= urse, maybe, maybe not, but fact is that today the crowd is shouting for an= IPV6 CPE, supporting dual stack and some popular transition scenario's, so= let's try to make sure this one can be made available as soon as possible = to allow massive v6 deployment. Besides that, price of a CPE is always a v= ery delicate subject. Who needs/wants to pay for it ? Adding reqs also me= ans adding cost .... Important thing operators are looking at today, in the v6 area, is things l= ike UPnP/PCP, etc. Lots of them are not deploying yet, hence not (yet) loo= king into sunsetting and for sure not in a multi-homed scenario. This is of course my personal opinion, looked at it from residential CPE's = perspective, which seems to be overlooked from time-to-time. I'm really p= ro-v6, also IPv6 council co-chair for Belgium, so really trying to get enou= gh attention to IPv6, to make deployment really happen on a large scale as = soon as possible. Regs Carl From: Jean-Francois.TremblayING@videotron.com [mailto:Jean-Francois.Trembla= yING@videotron.com] Sent: maandag 7 mei 2012 16:53 To: Wuyts Carl Cc: v6ops@ietf.org; v6ops-bounces@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) > Well, if you want something in short term (like everyone seems to want, > although reality speaks against it) then I think you've to stop adding > these kind of requirements as you're making your own rules, overruling > protocol independency, ... just for the sake of getting things added. > Carl Hum... not sure I follow you Carl. You're arguing against adding a "simple 6RD sunset" requirement that would start 6RD only if DHCPv6 fails, but you're also against multihoming in the CPE. What do you suggest we do with the 6RD requirements as stated in "version 3" ? As a reminder, here's the latest version of 6RD-[4-7] (version 3): > 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces > to be active alone as well as simultaneously in order to support > coexistence of the two technologies during an incremental > migration period from 6rd to native IPv6. > > 6RD-5: Each packet sent on a 6rd or native WAN interface > MUST be directed such that its source IP address is derived > from the delegated prefix associated with the upstream > network the WAN interface is connected to [Section 4.3 [RFC3704]]. > > 6RD-6: The CE router MUST allow different as well as identical > delegated prefixes to be configured via each (6rd or native) WAN interfac= e. > > 6RD-7: In the event that forwarding rules produce a tie between > 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IP= v6. Reading this with implementor eyes, it looks like support for multihoming native IPv6 and 6RD is required, with some form of source routing. This has significant impacts on an implementor because it implies running multiple routing tables. This is basically importing ipv6-ce-transitioning requirements in 6204bis. The choices as I see them are: 1. Leave requirements 6RD-[4-7] as they were in -08 (I'm fine with it, they're vague enough to allow 6RD single-homed) 2. Adopt requirements 6RD-[4-7] like they are in v3 (with multihoming and source adress routing) 3. Drop these reqs and add new simple 6rd sunsets requirements (more delays= ) 4. Drop these reqs and approve 6204bis without any sunsetting requirements. Choice 2 involves some form of multihoming in the CPE. As an implementor, how do you feel implementing this? (I am asking Carl here) This basically implies adding virtual routing tables support to the CPE (VRFs in Cisco-spe= ak) and source-routing capabilities. Not rocket science, but it is a significantly new concept to introduce in CPEs for a specification that was meant to be a short-term and incremental change to 6204. On the flip-side, as Gert just mentioned, we're likely to need it in future versions of the specs anyways. Personnally, I would be fine with option 1 and leave the requirements as th= ey were. This is vague enough to mandate 6RD without requiring multi-homing with nat= ive and 6RD on at the same time. My second choice is 3, as it fits better my needs = as an ISP, but it does add delays. I'd also be fine with a version of the requirements that do not mandate multihoming, but it sounds like what's already in -08. /JF --_000_867F4B6A1672E541A94676D556793ACD10E2185CAFMOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

@ Jean-Fr= ancois.

Main q seems to be= : “what do l want on these “simple” sunsetting requiremen= ts/rfc6204bis ?”

 

1.  = ;     I want to a= void reqs are being added over and over again, so draw a line and allow the= CPE vendors to become compliant with some set.  I read “delay&#= 8221;, but the delay is there because of the adding.

<= p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 = lfo1'>2.       = If reqs are added, don’t link p= rotocols together.  Avoid having to do X when condition Y is met. = ; DHCPv6 and 6rd are not linked directly.  Your suggestion below: if D= HCPv6 fails, then start 6rd ?  But you in this case even make the assu= mption that the ISP has something running for 6rd (from my view, some have,= some don’t, but you refer always to retail, so unknown to what ISP t= o connect) ?  You also need DHCPv4 for the option 212, or should it la= unch automatically some static 6rd tunnel (to what destination ?).  Th= is is a generic concern from my end.  The company I work for is not op= erational in retail, so deploying in a managed model, hence this issue not = even presents itself in reality for us, but protocol independency is very i= mportant (mainly for simplicity)

3.       6204 targets single home, let’s keep it like this T= ODAY (maybe it needs new attention later on).  Single-homed 6rd “= ;sunsetting” is not an issue at all, so let’s stick to the simp= le requirements initially added, as it will already be hard enough to cope = with it.

 =

What about vrf and things like that.=   One must be careful to make comparison.  You can hardly compare= a Cisco CPE with a standard residential CPE, as this is no fair comparison= .  Should/must the CPE be  full VR-capable or something alike it = (using some labels or something to mimic it), be able to do some source-rou= ting things, …. In the near future ?   I don’t know o= f course, maybe, maybe not, but fact is that today the crowd is shouting fo= r an IPV6 CPE, supporting dual stack and some popular transition scenario&#= 8217;s, so let’s try to make sure this one can be made available as s= oon as possible to allow massive v6 deployment.  Besides that, price o= f a CPE is always a very delicate subject.  Who needs/wants to pay for= it ?  Adding reqs also means adding cost ….

Important thing operators are looking at toda= y, in the v6 area, is things like UPnP/PCP, etc.  Lots of them are not= deploying yet, hence not (yet) looking into sunsetting and for sure not in= a multi-homed scenario.

<= o:p> 

This is of course my= personal opinion, looked at it from residential CPE’s perspective, w= hich seems to be overlooked from time-to-time.   I’m really= pro-v6, also IPv6 council co-chair for Belgium, so really trying to get en= ough attention to IPv6, to make deployment really happen on a large scale a= s soon as possible.

 

Regs<= /p>

Carl

 

&nbs= p;

From: Jean-Francois.Tremblay= ING@videotron.com [mailto:Jean-Francois.TremblayING@videotron.com]
S= ent: maandag 7 mei 2012 16:53
To: Wuyts Carl
Cc: v6= ops@ietf.org; v6ops-bounces@ietf.org
Subject: Re: [v6ops] 6rd sun= setting requirements (version 3)

 


> Well, if you want somethi= ng in short term (like everyone seems to want,
> although reality speaks against it) then I th= ink you've to stop adding
> these kind of requirements as you're making your own rules, overru= ling
> protocol ind= ependency, ... just for the sake of getting things added.
> Carl=

Hum... not sure I foll= ow you Carl. You're arguing against adding a
"simple 6RD sunset" requirement that would= start 6RD only if DHCPv6
fails, but you're also against multihoming in the CPE. What do you
suggest we do with the 6RD= requirements as stated in "version 3" ?

= As a reminder, here's the latest version o= f 6RD-[4-7] (version 3):

> 6RD-4:  A CE router MUST allow 6rd and native IPv6 WAN int= erfaces
> to be act= ive alone as well as simultaneously in order to support
> coexistence of the two technologies = during an incremental
= > migration period from 6rd to native IPv6.
>
> 6RD-5:  Each packet sent on a 6rd or native WAN interface=
> MUST be directed= such that its source IP address is derived
> from the delegated prefix associated with the up= stream
> network th= e WAN interface is connected to [Section 4.3 [RFC3704]].
>
> 6RD-6: The CE router MUST allow different as well as= identical
> delega= ted prefixes to be configured via each (6rd or native) WAN interface.  = ;
> > 6RD-7:  In the event that f= orwarding rules produce a tie between
> 6rd and native IPv6, by default, the IPv6 CE Router MU= ST prefer native IPv6.

Reading this with implementor eyes, it looks like support for multihom= ing
native IPv6 and 6R= D is required, with some form of source routing.
This has significant impacts on an implementor b= ecause it implies
runn= ing multiple routing tables. This is basically
importing ipv6-ce-transitioning requirements in 62= 04bis.  

The = choices as I see them are:
1. Leave requirements 6RD-[4-7] as they were in -08
   (I'm fine with it, they're = vague enough to allow 6RD single-homed)
2. Adopt requirements 6RD-[4-7] like they are in v3
   (with multihom= ing and source adress routing)
3. Drop these reqs and add new simple 6rd sunsets requirements (mo= re delays)
4. Drop the= se reqs and approve 6204bis without any sunsetting requirements.

Choice 2 involves some form = of multihoming in the CPE. As an implementor,
how do you feel implementing this? (I am asking Car= l here) This basically
implies adding virtual routing tables support to the CPE (VRFs in Cisco-sp= eak)
and source-routin= g capabilities. Not rocket science, but it is a
significantly new concept to introduce in CPEs fo= r a specification
that= was meant to be a short-term and incremental change to 6204. <= br>On the flip-side, as Gert just ment= ioned, we're likely to need it
in future versions of the specs anyways.  
Personnally, I would be fine with op= tion 1 and leave the requirements as they were.
This is vague enough to mandate 6RD without requi= ring multi-homing with native and
6RD on at the same time. My second choice is 3, as it fits bett= er my needs as an ISP,
but it does add delays. I'd also be fine with a version of the requirement= s
that do not mandate = multihoming, but it sounds like what's already in -08.

= /JF

= --_000_867F4B6A1672E541A94676D556793ACD10E2185CAFMOPESMBX01eut_-- From despres.remi@laposte.net Tue May 8 00:55:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C73B21F855F for ; Tue, 8 May 2012 00:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kXMTy3KuzYV for ; Tue, 8 May 2012 00:55:33 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5735421F8533 for ; Tue, 8 May 2012 00:55:31 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id C8D7894013A; Tue, 8 May 2012 09:55:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 May 2012 09:55:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 07:55:34 -0000 Le 2012-05-07 =E0 19:55, Mark Townsley a =E9crit : >=20 > There are not a lot of Retail CPE implementers on list here, but those = that are speaking up seem to have committed to implementing multihoming = between 6rd and native (at least Linksys + D-Link). We have two BCPs = (38, 84) that have been around for quite a while that we are basing = these requirements on. Even Carl whose customers really do not have the = same issue as they mostly use non-retail routers cannot say the = multihoming-based solution is wrong technically, just that he is worried = that it will somehow delay general IPv6 availability in products.=20 >=20 > With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was phase one = as they defined each technology separately. By including 6rd in the = Native IPv6 CPE document, > we naturally bring ourselves to phase two where we describe how the = two methods work together best. "Working together" is only a temporary requirement since 6rd is no = longer needed when DS is available. It can be done without multihoming in several steps: 1. delegate native IPv6 prefixes that are the same prefixes as 6rd's (=3D>= with ad hoc support in 6rd modules, CPE routers can still work with = single IPv6 interfaces). 2. disable 6rd (with DHCP or otherwise) 3. if desired to have IPv6 prefixes independent from IPv4 addresses, = replace IPv6 prefixes by new ones (for this, using the IPv6 lifetime = mechanism is sufficient? No need for multihoming). =3D> The MUST of 6RD-4 is therefore technically wrong if saying "A CE = router MUST allow 6rd and native IPv6 WAN interfaces to be active alone = as well as simultaneously in order to support coexistence of the two = technologies during an incremental migration period from 6rd to native = IPv6").=20 > Otherwise, we might as well just publish an update to RFC5969 for any = additional 6rd requirements, and leave 6rd out of 6204-bis entirely. Can't understand why 6rd would be left out ENTIRELY. This would be a step backward that NOTHING justifies. > We're back to moving in circles though. Keeping 6rd as a requirement (6RD-1 to 6RD-3), and leaving out-4 = multihoming (6RD-4, and 6RD-5 to 6RD-7 which depend on it)), does break = the circle (unless the WG would insist to have NOW something that = remains disputable). RD > IIRC, the Chairs already made a consensus call on the list, and I've = been posting the text they asked me to work on here. 3 versions later = plus a privately-sent tweak from Randy Bush saying I should write "from = which the packet is being sent" vs. "the packet is being sent on" and we = will have done that. At this point, we either move forward with what the = chairs asked, or continue to beat this horse and try to get them to = reverse their decision.=20 >=20 > - Mark >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Tue May 8 01:20:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3291121F863E for ; Tue, 8 May 2012 01:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NRELLwAQNwy for ; Tue, 8 May 2012 01:20:46 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id D271A21F8495 for ; Tue, 8 May 2012 01:20:44 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E6E03F8A92 for ; Tue, 8 May 2012 10:20:43 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8FEC1F8AA1 for ; Tue, 8 May 2012 10:20:43 +0200 (CEST) Received: (qmail 86940 invoked by uid 1007); 8 May 2012 10:20:43 +0200 Date: Tue, 8 May 2012 10:20:43 +0200 From: Gert Doering To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Message-ID: <20120508082043.GW84425@Space.Net> References: <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 08:20:47 -0000 Hi, On Tue, May 08, 2012 at 09:55:20AM +0200, Rémi Després wrote: > 1. delegate native IPv6 prefixes that are the same prefixes as 6rd's (=> with ad hoc support in 6rd modules, CPE routers can still work with single IPv6 interfaces). This is something which is not really implementable in a large scale deployment. If you have a 100 users, you can manually tie IPv4 assignments (and thus 6rd prefix) and IPv6 prefix assignments together. If you have 10 million users, and dynamic IPv4 assignments, I can't see any way to make this work, except "special support built into the access routers on the ISP side, to correlate IPv6 native prefix assignment with IPv4 pool assignment". 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 despres.remi@laposte.net Tue May 8 01:48:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A0921F85D2 for ; Tue, 8 May 2012 01:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcKXG2CNv4gy for ; Tue, 8 May 2012 01:48:00 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4666421F85C5 for ; Tue, 8 May 2012 01:47:58 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 89617940048; Tue, 8 May 2012 10:47:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120508082043.GW84425@Space.Net> Date: Tue, 8 May 2012 10:47:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <807FCAE6-B55C-47F9-B392-82A788CEFA90@laposte.net> References: <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> <20120508082043.GW84425@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 08:48:01 -0000 Le 2012-05-08 =E0 10:20, Gert Doering a =E9crit : > Hi, >=20 > On Tue, May 08, 2012 at 09:55:20AM +0200, R=E9mi Despr=E9s wrote: >> 1. delegate native IPv6 prefixes that are the same prefixes as 6rd's = (=3D> with ad hoc support in 6rd modules, CPE routers can still work = with single IPv6 interfaces). >=20 > This is something which is not really implementable in a large scale > deployment. >=20 > If you have a 100 users, you can manually tie IPv4 assignments (and = thus > 6rd prefix) and IPv6 prefix assignments together. =20 >=20 > If you have 10 million users, and dynamic IPv4 assignments, I can't = see=20 > any way to make this work, except "special support built into the = access=20 > routers on the ISP side, to correlate IPv6 native prefix assignment = with=20 > IPv4 pool assignment". Automatic scripts to do it seem to me feasible if IPv4 addresses are = stable (which is the case of 6rd deployments I know). Yet, OK, this can be a problem where IPv4 addresses are dynamically = assigned. My remaining objection could be alleviated if 6RD-4 would become = (asterisks to be deleted) "*For some anticipated 6rd sunsetting = scenarios,* a CE router MUST allow 6rd and native IPv6 WAN interfaces to = be active alone as well as simultaneously in order to support = coexistence of the two technologies during an incremental migration = period from 6rd to native IPv6" RD =20 >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From despres.remi@laposte.net Tue May 8 01:53:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEE721F8582 for ; Tue, 8 May 2012 01:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfD-1GuQI803 for ; Tue, 8 May 2012 01:53:32 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F3321F8575 for ; Tue, 8 May 2012 01:53:30 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 459FE9401C6; Tue, 8 May 2012 10:53:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120421192046.99723kgkv9zjcq9w@mail.drown.org> Date: Tue, 8 May 2012 10:53:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <20120421192046.99723kgkv9zjcq9w@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 08 May 2012 08:53:33 -0000 Le 2012-04-22 =E0 02:20, Dan Drown a =E9crit : > Quoting R=E9mi Despr=E9s : >> Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. >> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA = (an ID that no host may legitimately use). >> - This can be done, in compliance with RFC 5342, with a = modified-EUI-64 ID based on IANA's OUI. >> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available = range of www.iana.org/assignments/ethernet-numbers for this). > ... >> Would you agree on this? >=20 > This sounds good to me. Using IANA's EUI-64 ID would avoid conflicts = with possible interface IDs on v6 tethering (as long as a unique EUI-64 = address is assigned to clat). Since this is just a config file change, = I'll go ahead and use it. Any feedback? Thanks, RD >=20 > Thank you, > Dan From ichiroumakino@gmail.com Tue May 8 01:53:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5574C21F8570 for ; Tue, 8 May 2012 01:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=-1.235, BAYES_00=-2.599, HTML_IMAGE_ONLY_12=2.46, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEXTJicYBOpT for ; Tue, 8 May 2012 01:53:58 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF521F8549 for ; Tue, 8 May 2012 01:53:57 -0700 (PDT) Received: by werf13 with SMTP id f13so3191790wer.31 for ; Tue, 08 May 2012 01:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Jz5pHhtedPR9UcX6HC7byd1F7nrj+G+0hQNQjk7LUj8=; b=r7Ll7hMtCfXvLmywwYS+pHu5/j0P9YdOgkW7RYUy+EDh/bziN02P8cA+E78NmVr0Um zOeQ5wUnOKp4pd+0de6KLlExjaLLjIQDrvFJto7vRj56giyPHJWL0n022q8SqOqK8W0K c/0AdVh7vbEE4p/BQQhm7Baj5lqgIbx48YXMu2wd75VNNtW6+7umh85i8l4XSXYfww7a oWTL0M/Iki+uNbL805x8zPx2Lq5BHKO8U/5vqKgsIUN1ep8lfoCzgGL8cf/EDM9vWVup c9fWaOCFoozqTQAxxI0Abw1hoId+7LHmycEn9hzy0mxUrz4BgfrJ7E+UiWueUe0Nv2Sm NnTA== Received: by 10.180.85.69 with SMTP id f5mr42709802wiz.18.1336467236367; Tue, 08 May 2012 01:53:56 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff2sm43824336wib.9.2012.05.08.01.53.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 01:53:55 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_4272089B-80E3-437E-BC08-2EAF8D524AC7" From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> Date: Tue, 8 May 2012 10:53:49 +0200 Message-Id: References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 08:53:59 -0000 --Apple-Mail=_4272089B-80E3-437E-BC08-2EAF8D524AC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Forced single homing can be done. but at the expense of creating = dependencies between IPv4 and IPv6 provisioning. see the attached flow charts. first one for multi-homing, second for = forced single homing. how a forced single homed CPE is to deal with changes (link failure for = one protocol, lease times out for IPv4 address or IPv6 prefix...) is = left as an exercise for the reader. ;-) cheers, Ole --Apple-Mail=_4272089B-80E3-437E-BC08-2EAF8D524AC7 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_998752BD-94FC-41BE-93BB-3ED3E3C23C82" --Apple-Mail=_998752BD-94FC-41BE-93BB-3ED3E3C23C82 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Forced single homing can be done. but at the expense of creating dependencies between IPv4 and IPv6 provisioning.
see the attached flow charts. first one for multi-homing, second for forced single homing.

how a forced single homed CPE is to deal with changes (link failure for one protocol, lease times out for IPv4 address or IPv6 prefix...) is left as an exercise for the reader. ;-)

cheers,
Ole

--Apple-Mail=_998752BD-94FC-41BE-93BB-3ED3E3C23C82 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Screen Shot 2012-05-08 at 10.50.04 .png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; name="Screen Shot 2012-05-08 at 10.50.04 .png" Content-Id: <12B5505F-66D7-4CDD-A6CB-9EA466AAF93A@cisco.com> iVBORw0KGgoAAAANSUhEUgAAAkIAAAJrCAIAAACDZmupAAAX/GlDQ1BJQ0MgUHJvZmlsZQAAWIWV eQdUFM/Sb8/MBpaw5JxzkpxzziA5KzlnlhxUQECCgoAiAoqCiogKokRJoqAIfwQUVEQliARRMSAo IG/AcO+733fPO6/P6Z7f1lRXV1d1qNoBgO2WZ0RECEwDQGhYNMnGSJfHydmFBz8JEMAICEAASHt6 R0XoWFmZg/9avo0DaOf5WGJH1n/n+18LrY9vlDcAkBWKvXyivENRfAsApMU7ghQNAHZHnkBcdMQO Po5iBhKqIIov7GD/X7hlB3v9woO7PHY2eiieAoCM0tOT5A8A1TJK54n19kflECkBwNGF+QSGoaw8 KNb0DvD0AYDNA+XZExoavoOPoljE69/k+P9fMr3+yvT09P+Lf81lt5DpB0ZFhHgm/H+a4/9dQkNi /ozBhVbKqGBbM/TJhNot3tvTwBbFLCjOC/A1Mf9NvxQRrWvzm94eGG1it2MjFD8JiDG2/40XYoLt dVDMgeLN4HCzHX7UTjBLmNdeSxTToVjAO0rP5ZdMWDExwM7xN4+5j6++AYrRVQQ7kcJt/vAHRMXa /qEnJgbo7f3DH+RpuuNvIopzPEm7c0F1gEt8Q4x2xuVD8dWIaCu732MNhYXs/T0X+I0fydDmN/7h G7U7392xogPsjH/JR2ii0QXwSybC4RdoaPJLB0Q6gGT8h64dEbK7ptG+iB0pxmbHDgIo9vMNs/8t E8nx8dQ3+2UTpBwYAk9AAr7AC4SBLcADzIEe0P/d8qD0MLT1BuEgBK0kHuo/b7BvsSPYGewYdgr7 /C+33h8+EAh80Ocfuve/0W1BIniPSvUFUX9Gw7BhNDFqGHO01UarLEYZo/Ln3dBy8/JfrX7p6o/2 lfhN0f2tfey/a+8emEb6jz5ef3v8T50MwZtdqb85pGulF6U3//T/14xxBjh9nDHOECeKZCE3kfvI HaQfaUeaAQ/ShbQgg0jHDv6PUTx/W4W0O18zdERfELP7K+x/1SjmL8dvKlGMqABsdvmD0XeBf0dw 2NU68H9IiUGrFyopCH1n9neOfywthFpXAaOL0UDtjNoYw4RhAxIYedTiOhgt1AcKKFXvP3v9biWA 364tY3fnEgzeojg02jc+emeh64VHJJAC/QOieXTQ09J3D49JmLfkHh5ZaRlZsHP2/traX2x2z1SI 6dG/aOEyAKjsnJWH/0Xz+ABAcxB63ND9iybUDAC1LAD9p7xjSLG/aJidBgvIATW6+lnRk4MfiKB6 ygJFoAa0gQEwBZbADjgDN9S6ASAU1TgOJINUkAlywXFwEpSCClAFLoNroAE0g3ZwB/SBATAMxsAL MAXmwDuwAr6BDQiC8BAVRA+xQtyQICQOyULKkCZkAJlDNpAz5AH5Q2FQDJQMHYZyoUKoFDoP1UA3 oFboDtQPjUDPoWloEfoM/YARmBJmgDlhIVgKVoZ1YDPYDt4P+8ORcCKcDufBJXAlfBVugu/AA/AY PAW/g1cRgFAgTAgvIoEoI3qIJeKC+CEk5CCSgxQjlch1pA1di4+RKWQZ+Y7BYegxPBgJ1JPGGHuM NyYScxBzFFOKuYxpwtzDPMZMY1YwP7FUWA6sOFYVa4J1wvpj47CZ2GLsJWwjthfdz3PYbzgcjgkn jFNCV7szLgiXhDuKO4Orw3XjRnCzuFU8Hs+KF8dr4C3xnvhofCb+NP4qvgs/ip/Dr5NRkHGTyZIZ krmQhZGlkRWTXSHrJBslmyfbINAQBAmqBEuCDyGBkE+4QGgjPCLMETbIacmFyTXI7ciDyFPJS8iv k/eST5J/oaCg4KNQobCmCKRIoSihqKd4QDFN8Z2SjlKMUo9yH2UMZR5lNWU35XPKL1RUVEJU2lQu VNFUeVQ1VHepXlGtE+mJkkQTog/xELGM2EQcJX6gJlALUutQu1EnUhdT36R+RL1MQ6ARotGj8aQ5 SFNG00rzlGaVlp5WhtaSNpT2KO0V2n7aBTo8nRCdAZ0PXTpdFd1dull6hJ6fXo/em/4w/QX6Xvo5 BhyDMIMJQxBDLsM1hiGGFUY6RnlGB8Z4xjLGDsYpJoRJiMmEKYQpn6mBaZzpBzMnsw6zL3M283Xm UeY1FnYWbRZflhyWOpYxlh+sPKwGrMGsBazNrC/ZMGxibNZscWxn2XrZltkZ2NXYvdlz2BvYJzhg DjEOG44kjiqOQY5VTi5OI84IztOcdzmXuZi4tLmCuE5wdXItctNza3IHcp/g7uJe4mHk0eEJ4Snh ucezwsvBa8wbw3ued4h3g0+Yz54vja+O7yU/Ob8yvx//Cf4e/hUBbgELgWSBWoEJQYKgsmCA4CnB +4JrQsJCjkJHhJqFFoRZhE2EE4VrhSdFqES0RCJFKkWeiOJElUWDRc+IDovBYgpiAWJlYo/EYXFF 8UDxM+Ije7B7VPaE7anc81SCUkJHIlaiVmJakknSXDJNslnyg5SAlItUgdR9qZ/SCtIh0hekX8jQ yZjKpMm0yXyWFZP1li2TfSJHJWcod0iuRe6TvLi8r/xZ+WcK9AoWCkcUehS2FJUUSYrXFReVBJQ8 lMqVniozKFspH1V+oIJV0VU5pNKu8l1VUTVatUH1o5qEWrDaFbUFdWF1X/UL6rMafBqeGuc1pjR5 ND00z2lOafFqeWpVas1o82v7aF/SntcR1QnSuarzQVdal6TbqLump6p3QK9bH9E30s/RHzKgM7A3 KDV4Zchn6G9Ya7hipGCUZNRtjDU2My4wfmrCaeJtUmOyYqpkesD0nhmlma1ZqdmMuZg5ybzNArYw tSiymNwruDdsb7MlsDSxLLJ8aSVsFWl12xpnbWVdZv3WRsYm2ea+Lb2tu+0V2292unb5di/sRexj 7HscqB32OdQ4rDnqOxY6TjlJOR1wGnBmcw50bnHBuzi4XHJZdTVwPek6t09hX+a+8f3C++P397ux uYW4dbhTu3u63/TAejh6XPHY9LT0rPRc9TLxKvda8dbzPuX9zkfb54TPoq+Gb6HvvJ+GX6Hfgr+G f5H/YoBWQHHAcqBeYGngpyDjoIqgtWDL4Org7RDHkLpQslCP0NYwurDgsHvhXOHx4SMR4hGZEVOR qpEnI1dIZqRLUVDU/qiWaAY0yB2MEYnJiJmO1Ywti12Pc4i7GU8bHxY/mCCWkJ0wn2iYeDEJk+Sd 1JPMm5yaPH1A58D5g9BBr4M9h/gPpR+aSzFKuZxKnhqc+k+adFph2tfDjofb0jnTU9JnM4wyajOJ maTMp0fUjlRkYbICs4ay5bJPZ//M8cl5mCudW5y7edT76MNjMsdKjm3n+eUN5Svmnz2OOx52fLxA q+ByIW1hYuFskUVR0wmeEzknvp50P9lfLF9ccYr8VMypqRLzkpbTAqePn94sDSgdK9MtqyvnKM8u Xzvjc2b0rPbZ6xWcFbkVP84Fnnt23uh8U6VQZXEVriq26u0Fhwv3LypfrLnEdin30lZ1WPXUZZvL 92qUamqucFzJr4VrY2oXr+67OnxN/1rLdYnr5+uY6nLrQX1M/dINjxvjDWYNPTeVb16/JXirvJG+ MacJakpoWmkOaJ5qcW4ZaTVt7WlTa2u8LXm7up23vayDsSO/k7wzvXO7K7FrtTuie/mO/53ZHvee F3ed7j65Z31vqNes90GfYd/d+zr3ux5oPGjvV+1vfaj8sHlAcaBpUGGw8R+FfxqHFIeaHik9ahlW GW4bUR/pHNUavfNY/3HfE5MnA2N7x0bG7cefPd33dOqZz7OF5yHPP03ETmy8SJnETua8pHlZ/Irj VeVr0dd1U4pTHdP604MztjMvZr1n372JerM5l/6W6m3xPPd8zYLsQvui4eLwkuvS3LuIdxvLme9p 35d/EPlw66P2x8EVp5W5T6RP25+PfmH9Uv1V/mvPqtXqq2+h3zbWctZZ1y9/V/5+/4fjj/mNuE38 ZsmW6FbbT7Ofk9uh29sRniTP3VAAQSvs5wfA52o0b3EGgH4YAHLir9zod0HQ4ANGn3g0UjBFI4BZ SAy9t7thVjgankBMkLsYI8wTbCiOFteDTybTJOAJL8lbKcop86mqiZM0NLRmdNn0/Yy0TPuYr7Ji 2DzZOzh5uI5yr/P68E0I7BXsF5YSyRN9J26yp0Lim5Se9DGZYTkqeV2FKMVypW7lKZUtNWZ1cQ0V TQMtG21vnSjddL1T+rUGXYaPjRaNt00ZzfaY61m47g20jLXKsC60qbCttWtGd/2A46jTc+fXLrOu C/ve719wm3Qf8ujyrPM6633MJ9HXz8/aXy1AIJAY+C3odXBfSE3osbCIcNsIpUi2yE3Sq6ju6KqY jFi/OJN48QTyhKXEwaT65JID6QfjDkWmkFIT03IOn0/vyHh9hJClnh2RU5U7fow8Tz0/9PjZgqHC rRN7TroW55xqKpkqpShTKHc/k322oeLFeUylRJXDhUMXL18aqV6v4bliXpt8teHapzrV+vwbH2+6 3nrUZNn8pFW9Lfp2TftkJ0WXXLfDnciejLsF94p7i/sK7mc9ONx/5OGxgWODGf9EDzk+kny0Mdw9 kjSqOPrt8dMnrWOl4weeuj/TfS44QZh4/2JksvFl6asDrz2m9KdFZ2hmvs++fTM+1//2zvzthdbF 1qWL7/KWY9+7fTD4KL5Cs7L6aeJz55fzXzNWA76ZrUmt06+vfZ/80b1RuZm+5ftTf5tvexv1Pw6w odFhPOhFIzpz6Dj0GpZDY68viDsyjkZNL7EROCKuGe9LxkY2QSgn96fQpdSgsiMGUKfQnKO9Q7fI wMioz5TAXMfykU2SncTRzkXB7cBzhXebX0cgVbBLaFNESTRI7Iz4wJ7PkoxSctLGMq6y/nKR8gkK BxQTlYKUXVXMVTXUpNX5NBg1yTR/aL3XntYZ032o16l/06DasMQoyzjOJMDU2czYXNlCeC+jJcby q9WM9YhNt2293Vn7LIcoRzcnE2c5F05XnOsH9KTvcKtyz/EI97Tzkvem9J7xafXN9/PzVw+gDXgb eDuoINg3RDWUOnQ2rDk8K8I5UhxdF0NR56JJMXqxjLHzca3xRxPcEqWT4KSnyXUHcg+GHrJP0U9V TVM5rJFunOGUGXbkSNbF7Ls507k/j3HkqeQ7HI8qOF54taj/xNti+BRHieJp69LQstzyq2eGz347 x3feqvJwVeuFT5ckqyMv36pZq1W5mnytsw7U69w43NB7C9to1JTVfL8V32ZwO629o+Nrl1C37Z2k nrN3b98b613sW3uA6ad/yDsgNajxj/mQy6OA4biRzNGTjyuf1I21j/c/HX829/zrC2SS4aXgK+XX 5lP+01Uzi2+E51zeZs5fWbi/OL20vkx8L/hB66PrSsqn4S9yX4tWv6zZrN/6wbKRsbn+M27X/xhA C8TAXpACutG4XhWKhpphGLaAz8EbiBvyEKOOacIqY3twVrhZfBIZO9l9wjFybwp1SnbKn1QzxAHq RpqLtCV0efRZDBmMmUy5zEUsFay1bC3sHRwdnJ1cXdydPLd5G/lq+c8I5ArGCO0T1hbhEwWiL8Sa xXP3OEjwSCxJNkqlSJvJMMlMy9bKxchrKRAUHiueUQpQlldeV+lUzVAzU6dTn9Co1AzSktXa1O7T KdDdryemt6Z/1yDf0NVI2OizcadJjqmDGa/ZO/Mmi5S95pZMltNWtdZRNmq2sO1Du0J7Fwceh3nH 604xzmousEu/a/4+2/1M+5+7lbnv9+D0eOl5xmu/N4f3hE+Jr4Mfvd8j/9wAg0CArpfYYJng5ZDq UK8wjrCn4UUReyPJIu+QEqPkopajL8a4xTLHPoo7Eq8Vv55QnxiYxJP0PPnEAbuDrAfnDrWknEhN SPM7vC/dOcM10/dITFZGdnHOpdymo33HxvLm8r8WIIX0RXwnpE+qFuudMi2xPu1c6lUWXn7oTNHZ qxUD5z5WClYlXBi+JFx98PL4FYna9KsvrsvUZdW/alC8mXvrdZNc85GWyTa52zntM53qXSXd33rs 7jb2CvddeCDR3zsQ/I/A0PLw/dEbT2rG65/dmXj5EryWnq5+kzmfs9T8gfpT1irLeuOm447/f/1H tlNwigBcnAXA4TwA1q4AVIsDIFgGAJEBACsqAOxUAKybD6DnpwFkdP3v/UEFhIEhmg0fQTPHfvAO IkIykD2UCJ2B2qEX0Caa32nBXnAmfAV+BH9F2BEdJAA5jrQiMxgKNMP2QDOyFswbLB1WCxuGPY8d w5HjdHDxuAbcMl4E74+vxi+SSZLFkHURKAguhKvkELkTeQMFkSKMYpRSmfIcFRkVieoV0ZTYSi1C XUpDRZNKs0YbjuYr3nSv6b3o5xlCGb4xpjIRmc4wSzHfZXFlWWUtYJNhe8wex8HJMcx5hEuXG3Df 4cngteBj5Vvgvy1QIBgkZCgsKEIpsio6IzYqfm9Pm8RNyXqpOukGmRbZbrkB+VcKn5Qwyowq/KoS ajLq0hpimjxadNqw9kedF7pdepX6WQbhhk5GusZSJlym1GaI2br5isXS3jnLGatp6zc272y/2G05 EByZnYSdVVwsXL33Je0/6VaP3mPvvYjecj7Ovof8qvx7A2YDt4LpQnhDxcIkwyUiRCP5SExRhKgf 0YuxbHEW8ekJXYk/kw0OFB18l2KRevuwfHprpsmR2ewjubxHr+dp508VFBQ5ndQ4ZXI6rqz3LPs5 YiVc9f3i5+oPNcu1y9c+1q3e2LpF1sTeItWm3+7cGdgd23PwXkrfgQexD0MGPYZyh1tGl8Z4n+5/ XvHi7SuZqdSZsTnx+azF+WWjD1c+0XxJWn2/7vdjfiti9/ygBpLAGsSAUtAF3kAUkCzkCqWjGf8A 9BHN7lVhDzgLroefIwiaszsjGcgN5DWGCj1VgjFlmH/Q/FsG64MtR/1OjTPHZeMe4MnxFvhC/ASZ IBmJrIfARAgh9JHzk6eRz1GYUrRRilNWUDFSHSXiiGnUgDqVBqHJoiXSnqLjo6uj16YfYwhlxDFW MukwzTBnskiwjLOmskmzTbEXcRhzYjh7uA5zG/JQ8ozzVvJF8RsKcAmsC44LNQufEzklWiCWJ563 p1CiVPKSVKP0A5lXsmvyjAqqit5KecodKh/VBNXdNco0X2hz6fjo1ultGBgY5hoNmGBNlcy8zDMt Lu29YzlhtWKDsWWyE7PXdnB2jHLKd77uMuT6aT+Tm4a7n0eBZ6fXBx9+Xye/fP++gK0g+eDAkLOh I+FwhGykBykv6nb0Qix1nFK8R0JuYkvS/AHmgyaHDqQ0pC4d5k/fn1Ga+SyLOds552zum2MSefH5 fQUsheFFgyeli8tKiKezyyjLT54Vrrh/PrCK8kLDJZfLmJr6WvdrNNfv1sc3SN1caKxuDmyVaPvc 3taZ1m3ew3x3trf+fnK/6QDr4PCQ/aPZkcTHXE+GxnOf2U4ITUIvZ173TdfO5s+R5m0X2ZcqloXf 3/iouTL02f3Lx9WUNer10z+4Niq22H7m7/qfGeiACFABHoFt1Pd+0GmoF/oC88E2cDrcDC8jvIgT ut/7MQhGE5OIacasYhWwsdgOHBZniSvDLeHV8MfxC2T6ZBcIZIQIwiS5OXk3hRLqaV3KQSpnqiXi QWpG6noaS5pPtMV0mnSL9GcYbBmpGB8yZTObs9CxTLBeZCOx63DQc7zj7OO6wJ3JE8xrx6fDLysg LMgtxC7MJsIjKi6mIm62x1MiWbJUqkP6jSxRTl2epHBd8aOygkqq6qi6iEa65lttc51mPXH9C4a8 RlUmoqaN5voWzywjrClt6u1c0f3a4RzrKr9v3a3b45iXm4+iH6X/88DSYJOQxbCE8M3IaNJctFXM zTjaeFLCkyTV5PMHKQ7Fp8ynOR0ezNDNbMuSz27K1Tjan+ec/67gYBHticpiqVOtpzVLu8rVzzRV YM+Znz9Z+fqC2MW4S72XGWv8rrRdJV7zud5ez3gjomHglgia+bxvsW5tvs3Vntnxocux+06P+N2T 97b7gu4/6dd+WDvI9E/U0MNh9pGA0auPl8b4xx2fpj27/PzhxNyLzZc0r7hfi08pTKvOaM5qv9Ge 03yrOq+0ILMotsT3jvhucbn1fdwHhQ/LHy+uOH8i/9T+2e8LzZeWr/tWwWrlN91vM2uH1jnWW7/b f1/5cXRDeKNn021zfavop9TP/m2fHf9H+cnJ7l4fEKUuANhX29tfhNCkohCArYLt7Y3K7e2tKjTZ mASgO+TXd5fdu4YGgPKq//b94/8AmJfCLqRoihwAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURB VHic7N1/QBR1/j/w1yDIDwVFBRVS/IVh5VB6qVlqC2Z6qUv+6Jd4XXYH9Evg7srwTr+Fn8ugOl2z XO2upRQvhc+da9fRx1pIrFzqlnIwl2xJuFyrRRddkF3chfn+MQiIKCwMzCz7fPwFy87sa3aW93Pe 75l9D8PzPAEAAHgmH6kLAAAA6D7EGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDE GAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGECrS5cuSV0CALgHMQZA //3vfx9++GGWZYcMGcLI0qhRo375y19mZ2c3NjZK/W4ByAtiDLzd9u3bp02bdscdd2g0mrq6Ol6W SktLk5OTdTqdr6/v6dOnpX7PAGSE4XH3Z/BiW7du/fOf/3zkyJGYmBipa+mS119//dlnn/3iiy9Y lpW6FgBZQIyB98rJycnIyDh27Fh4eLjUtbghLy8vLS1Nr9ePGTNG6loApIcYAy/1zTff3H333V9/ /XVkZKTUtbhNrVbv3r37k08+8fPzk7oWAInh3Bh4qfXr1//hD3/wxAwjoqSkpLq6ugMHDkhdCID0 0BsDb/TRRx+lpKQYjcaBAwdKXUs3HTlyZNWqVd9++21gYKDUtQBICb0x8EbZ2dmbN2/23Awjojlz 5kybNu29996TuhAAiSHGwOucOnXqq6++SkhIkLqQnnr88cffeustqasAkBhiDLzOX//611/96lce 3RUT/PKXv6yqqvrmm2+kLgRASogx8C48z+/ZsyclJUXqQkQwYMCA3/72t++++67UhQBICTEG3qWi oqKxsXHy5MlSFyKOuLi4oqIiqasAkBJiDLxLYWFhXFyc1FWIZtasWUaj8cKFC1IXAiAZxBh4F51O Fx8fL3UVohk4cODs2bM/+eQTqQsBkAxiDLyLXq+fN2+e1FWI6e677z569KjUVQBIBjEGXsThcPz8 889jx46VuhAxTZo06bvvvpO6CgDJIMbAi5hMpgkTJvj49KuP/eTJk0+ePCl1FQCS6Vf/zwDX9+23 3954441SVyGy6Ohok8mEWeXAayHGwItUVFSIEmNlOclX3Js5YVNZjcudFbiqykrKqmp7XgkRBQUF hYeHm81mUdYG4HEQY+BF6urqgoKCRFhRw89EGYbKSpPJZDQUpJ3ayC7f404ouT5kZ7H7RDuhFRQU VFsrTigCeBzEGHiRurq6wYMHi7EmGykms1FREydOjJm2MPlJBRXZXERENR9ua+6opW8rFILFVV26 KSFW6LXllJwhovK9GSlEtG76+vxyMYqhwYMH19XVibIqAI/jK3UBAH2ntrY2ODhYjDWFUNHRA4UT h5Gz7r+fbUgpStSoQolKti1flHouV2+adunIlLnxx8hQuHb4xvDpm5VZBtM/LB+8sGhW5ECjbcnM JYm0dY8ya8Vsce52hhgDb4YYAy9y8eLFkJAQMdYUTLRrZbqeJeI4jojG/3Cq1kGbU4syiy2PzAwj mmjK1U3K+vRHhf9mYvW7n5sWTLR2m+pve7IOfvfIc7PjFWRetGhahCiZSkOHDsWgIngtxBh4l8bG RjFWYyZWbTuWLKTQmZKdkbOURcu/IKKW/6nIaXcRV1rdeDPRqsnNaRUYwRIFEJGzgYganGJUQkTk dDr72bcIALoOH33wIsHBwSL2Wvwu/xARe6uCqNJ60UY0ZGhzjJmPf0rszWFNRFT28+XLGM/1zuWE 4p3zA/A8iDHwIuKdQwohrvzLsvKysrKy0sJNv5xVRErFL2IfVFDqBk2Vg1w1pdtX7mFX3DZ6zC0s 7dm5v9RFdObIrpQielIRTeSic3TugkWsREWMgTfDoCJ4EdFizD+YaOtcdmvzr4o0XWXm1IDgKXuK P42cOy4wlYhImWV6dg4F0D+0mZOU07euIiJKUusfnxpMRLc/mcilLLrL33DsuWk9L0e8S1cAPA+D L/+D93jttdd++umnV155pTdfxFF9xuqkwPCI0JaDRFdtjaXW7hc4LCw0oPV5DodvQIAoB5I33HDD F198ERERIcbKADwMemPgRSZNmtT79zQJCLsqTnyDQyOCQ9s/LyCAxFBbW1tTU4MMA6+Fc2PgRfrl LLonT57sNzezBugGxBh4kYkTJ1ZVVblcbs1/KHeIMfByiDHwIgMHDoyMjKyqqpK6EDFVVFRER0dL XQWAZBBj4F1mz55dWFgodRVi0ul0d955p9RVAEgGMQbeJT4+XqfTSV2FaOx2+5dffjl37lypCwGQ DGIMvMv8+fN1Ol2/+Z7Jp59+ettttw0aNEjqQgAkgxgD73LDDTcMGTLk+PHjUhcijsLCwrvvvlvq KgCkhK8/g9f5n//5H7PZvGPHDqkL6alLly7dcMMNR48enThxotS1AEgGvTHwOmvWrHnvvffq6+ul LqSnDhw4MHXqVGQYeDnEGHidiIiIu+66Ky8vT+pCeurtt99+/PHHpa4CQGIYVARvpNfrly1bZjKZ goKCpK6lmz788MNnnnnmxIkTfn5+nT8boP9Cbwy80axZs+Li4l566SWpC+kmp9O5du3abdu2IcMA 0BsDL/Xdd9/Nnj37888/98QpMLKzsw8dOvR///d/AwYMkLoWAImhNwZeKjo6+q233po3b15lZaXU tbgnOzt7x44de/fuRYYBEG7UAt4sISHBbDZPmTKlqKho1qxZUpfTJVlZWc8//7zZbA4PD5e6FgBZ GPDCCy9IXQOAZGbMmHHLLbfcc889PM/zPB8REeHrK8dju9OnT3/44Yd/+MMfOI47evRoZGSk1BUB yAXOjQFQdXX1xo0by8rKDAaDw+GQupwOjBo1aubMmXFxcc888wzDMFKXAyAjiDGAK2zbtm3Lli3F xcVjxozp+1dvbGy85557ZsyY8fLLL/f9qwN4IlziAdBK2gwjogEDBuTn5+/bt++9996TpAAAj4Pe GEAzyTOsRVlZWVxc3KFDh2677TZpKwGQP/TGAIjklGFENHXqVLVanZCQUF1dLXUtAHKH3hiAvDKs xYYNGw4fPlxYWCjPiycBZAIxBt5OnhlGRDzPL1myZNy4cdu3b5e6FgD5wqAieDXZZhgRMQzz97// /eOPP/7rX/8qdS0A8oXeGHgvOWdYC2Hux4MHD95xxx1S1wIgR+iNgZfyiAwjoujo6HfffXfFihVm s1nqWgDkCDEG3shTMkywaNGitWvXJiQkNDQ0SF0LgOxgUBG8jmdlWIsHH3wwMDAwJydH6kIA5AW9 MfAuHpphRJSTk/PVV1+pVCqpCwGQF/TGwIt4boYJ/vvf/86YMSM3Nzc+Pl7qWgDkAjEG3sLTM0xw +PDhBx54QK/Xjx8/XupaAGQBg4rgFfpHhhHRvHnzNm7cuHTp0osXL0pdC4AsoDcG/V+/ybAWjz/+ +IULF/Lz86UuBEB66I1BP9f/MoyIduzYcfr06T//+c9SFwIgPfTGoD/rlxkm+Omnn37xi1/s2LFj yZIlUtcCICXEGPRb/TjDBF988cV999135MiRmJgYqWsBkAwGFaF/6vcZRkQzZsx49dVXlyxZcuHC BalrAZAMemPQD3lDhrVIS0v79ttvP/jgAx8fHJWCN8LnHvobr8owInrttdccDscf//hHqQsBkAZi DPoVb8swIhowYEB+fv6+ffvee+89qWsBkAAGFaH/8MIMa1FWVqZQKD7++ONbb71V6loA+hR6Y9BP eHOGEdHUqVPVarVSqTx79qzUtQD0KfTGoD/w8gxr8ac//enIkSM6nc7X11fqWgD6CGIMPB4yrAXP 84sXL54wYcLrr78udS0AfQSDiuDZkGFtMQzz97///dChQ2+//XbLg2fOnJGwJIDehhgDT9LY2Hjp 0qWWIQRk2NVCQkLef//9559//ujRo0SUnZ09d+5cDLpAP4YYA09SUlLi7+8/c+bM+vp6ZNi1TJ48 +Z133lm2bJlSqczMzPzpp590Op3URQH0FpwbA09yzz336HQ6f3//kSNHEtGRI0eQYR06c+bM3Llz T58+3dDQ4OPjk5iY+M4770hdFECvQIyBx/juu+9YlnU4HETk7+8fGxtbVFQUFBQkdV2yU1ZWNmfO nIsXL7pcLuGRwYMHnz9/fsCAAdIWBtAbMKgIHuOll15qaZcbGho4jrvjjjvq6+ulrUqGPvroo/r6 +pb3ioh8fHw++eQT6SoC6EWIMfAM1dXV7733Xtum2dfX99y5c+hhXO2JJ544ePDg6NGjBw0aJDxS V1f37rvvSlsVQC9BjIFnUKlULT8PHjx4woQJO3bsqKqq8vf3l7AqeQoMDFy4cGFVVdUf//jHoKCg gQMHNjU1/eMf/2hsbJS6NADx4dwYeAC73T58+PCGhgZ/f//bbrvtxRdfnD9/vtRFeYYff/zxmWee +fe//83z/L/+9a/4+HipKwIQGXpj4AEOHTpkt9uXLVtWUlLy2WefIcO6bvTo0fn5+TqdbujQod98 843U5QCID70x8AxnzpyJiIiQugoP1tTU1NDQEBgYKHUhACLD/KFex8fHp18euzAM09TUJHUVfQf7 EUCAGPM6PM/31+ZP6hL6FPYjgADnxgAAwIMhxgAAwIMhxgAAwIMhxgAAwIMhxgAAwIMhxgAAwIMh xgAAwIMhxgAAwIMhxqBjjprqM2fOVNfUdnPxWoer82dBr8N+hH4PMQZXcVXlpMcFDguPjIwMHxbC JGSX1bjVlNXkJMcGhgS+WVaRE8tsKq3prTrh+rAfwTsgxqCd6m0Lxj22NVJrqLTZ7RZTccapdezd b1Z3fQWu0+/u4jJ15rVTo2Zt160cH9x7tcK1YT+Ct0CMwRVqSv+eWkR5Js3SaVHBAQFhE+dkHtQq 6NRPtURU8+G2ZIZhGIZJ31ZYS0SuiuzVCeu3Za+OZRiGSc8pcVFt/rOpRUQb09d9WFVz5ujHJ60u Iqoq3JnAMExsQva2TcnJ26pcVL43PX1vmfCi5XvT0/eWE1F5/vrk7Jzs1UzCtlIiV+neTbEMwzCx 6TsLuzko5q2wH8GL8OBlrr/TDSoFsSprR3/SqxREbK7eZCzWEJFCZeBtBiUREakLigvUSUSkMdpN OhURq9IWW+xWNUtZequN0xBRorrAoNMQEZFSb+MNKpay9JdftPlnTq0kIkrM1BosprwkIlJp9Qad moiUaq4n29X/YD8CCDDDPVzBz5+Ic3TwB0fZ5tSizGLLIzPDiCaacnWTsj6tTbqLiDIKzMkLI8gV pkzZZau3T5yrUNCBuxbMCQuobSAiP/quYAsl5WmSF/oSWfWWYbM+9CMiGs6SX/OLtv5sI4Xatjs5 mGq2PbZLoTKsXTqNaKZBXTD9zaKa5KmhffMueD7sR/AeGFSEK/mHENEVVwK4qvZu21lWLbSJzcc9 kdPuIu4bi4tsRKMig4mIfCMXseQgIpeTiJzOluXrvszl2JsnCEv6Bg25+jWrfyoSfnA2ELvw9mAi cpz+kqOi1OnC2Nf0FC0N9xd1O/s77EfwGogxuEL0rASidf8oaz2FcebjnatS36ynATaiIUObmz/z 8U+JvTlc+M3Z3Fo2dLzKgKg44i5cbg6dbZ4VIBy51373AQ0PuHIh36AgoqQ8o9Npt9ntFqO+4MV5 uMag67AfwXsgxuAKATH3qRSUwir3llTUOmorjuyMXLSZkjZNHzP+QQWlbtBUOchVU7p95R52xW1d a498p9yZRBuT8suqHdUlf5ieShQitIXc3w5U1LqqCnekcBTSfqGo+5Jo16aDVfaAYGfllimzFu2p xAh412E/gvfAJwraCVurNTqefHDVrEnC78rMvLc2LPUlenxP8aeRc8cFphIRKbNMz84hKosk8vdr /hT5E7U7G+NPROQbteLVgqwnF7HhRKRgibibRgRS+H1pilTlpJCNRIpEloReg1/ror5LX+Uy7mIn hawjImIzjaqFvbnV/Q/2I3gLhu+P90GH62CYLu302prqWrvTL3BYWGjbcSJH9RmrkwLDI0K7fgRU XfbhR6fCly2dFkBUfWR9+NxRNn5tMBG5aqtrXMGhoQHXXJerptri8g0ODQ3u9OW6uF39BvYjgACf GK/T981ETWn2sOnrlBnqB6LKV6VsTcrldj4yVfRX8bbmD/sRQIBPjNeRpJk4U1b4fsFn5T/ab1+W /MicqN54CW9r/rAfAQT4xHid/tpM9Nftupb+ur39dbug9+BKRQAA8GCIMXCDq6aipLTCRVRbms0w 2d2Y89xRnsMwCaW1RI7S1cwV0nNKrj0Bu6Mkf9vqhLi4hOS9R6p6sAVAJOV+FNTsTU/YdLCiW7UD tIcL7sEdp/931nSy888Fjl+q01E3vsfqdDYQ2YSfa4nScvVPzxzidNKZ0rz4VbMCR5lfWhhx9VKl Ox+alXJKpd2ysnKfcu64S0b7r2MCrn4adJVE+1FQlrN21VatYvzGDd0tH6At9MagwwnOiYjKD26L YxiGYWIT1peccTnK8xew64jW/TJ9b4315Pufnawpz0+ITS9pPpivzU9PSN9b3vUZzW1E46fGTpwY ExMTE/dIhkZBH3A/lO9dH5e+t3mpmpLkuNUHT/4nM0Wr4krWLo1bunanXqMa5ee89lq9mMz3Y5WD iBzlOexje4goBJNSgVj6diZikF4HO72jCc6dplwiSsstrjQZVIlESk2trVKrSiJK1OpNNYYsIpXV ziUSJeWZeJ7nrcUskZqzXX9GcxunJlIYbDxvNyiJsorNvNNut9vNhlyWKENntuqziFidhed5vjIv iSitvCKPiDLVWYkssYrEXL25q9vVr3ncfjQ5ed5pTCLKLOZyE4lVGbq6XQDXhU+M1+mgmbAblEQZ BWae53mnUUmkMlidVqNWq7fxvNNu1WU13/XDaVQRqe08b+NURCobz+syiJQaO89XapOIMsy8VcWS 4nILZVAr290upG3zl9jukEqZZbLzvNOURJSmreR5u0ZBbJbexqmJiEih0RZoMpRElKW3dGm7+jWP 2488b9cmEaUV8DyvUZDiGnds8bb9CD2Hc2NARO0nOL9A5Ovr92NRRoiyec5yUjzoS2R3ElFD2xG9 2Q+riX33hGN5+du7FGouomVG89TLz1AsutaL1hJlaLn0X4TUO4koKDIqzJeIaGJiJjv37S83K8Zs KaINmulk+5qIco3/fiQmgJbe2fBByJuHv39uZpjob0I/IOf9eObDjcpdlFUQXl5WeOwcFX1aVDp/ 1LSJ2I/QUzg3BpddOcF5+f/+PmVrdHGlxcnz5oI0OtfxvOcBUxdmUNHuXZq/ailtyRS3ZjS3EY0a Py4sIioqKiqque0jIrp9ZTpp97yjeZtjVfFRvn5+/kQ0rHnudD//4XTFpH3Qjlz3o81qJ2LXLZo+ hY3fyhHtSZ3+wke4GTT0HGIMOuZsIKLhYyPDXGdKXly0lYaTg4icRPSTpbbtBdVRK9TKrampRUq1 IsLX7RnNnR1cmx0QsyCT1aak7kracF8oUUCMIoNo3Zb8Mw5Hddm/thTRijvGiLqt/Zl89mPMI1t4 /hjP8zxvUyuIVRn43Y/gpi3Qc4gxICK/dhOcE1H0/DUK2jzOjwmMnBWUkURFqfO3lfoNiSDaPCnk zfNExDYvzC5cwxJlpCwUBrOWvspl0LpJIQwTMmXzVTOa+/n50+W7eYS0edErRSSkJxIpE+MnEhFR VIZRO3zzysjAwHB25fhM7dNzMBLVIZnvx1b+ROP90aUGcWDeF6/jxmQ/rtpqiyNgWFhwALlqa12B wQG+5HI4XL6+Ab7XP6vqxozmXeVyVFus1H6m9lbeNomRp+7HznjbfoSewyfG6/TXZqK/bte19Nft 7a/bBb0Hg4oAAODBEGMAAODBEGMAAODBEGMAAODBEGMAAODBEGMAAODBEGMAAODBEGMAAODBEGMA AODBcKMWr8MwDMMwUlchvn65UdeB/QggwLwv0ItWrFjx0EMPrVixQupCoEc2bNgwcODADRs2SF0I QAcwqAgAnfDx8WlqapK6CoCOIcYAoBOIMZAzxBgAdAKzzoOcIcYAoBPojYGcIcYAoBPojYGcIcYA oBPojYGcIcYAoBOIMZAzxBgAdAKDiiBniDEA6AR6YyBniDEA6ARiDOQMMQYAncCgIsgZYgwAOoHe GMgZYgwAOoHeGMgZYgwAOoHeGMgZYgwAOoEYAzlDjAFAJzCoCHKGGAOATqA3BnKGGAOATiDGQM4Q YwDQCQwqgpwhxgCgE+iNgZwhxgCgE+iNgZwhxgCgE+iNgZwhxgCgE4gxkDPEGAB0AoOKIGeIMQDo BHpjIGeIMQDoBGIM5MxX6gKgH6qrq/v888+J6Oeffz527FhISEhwcPAdd9whdV3QHY2NjU1NTY2N jQ6Hg+f5gIAAhmGkLgqgFYa8QXzJycm7du0aOnRoY2Ojj48PwzDnz583GAzTpk2TujRww7Fjx269 9VYhtBiGYRimsbHx2Wefzc7Olro0gFYYVATxPfroo4MHDz5//nxtbe2FCxfOnz8/YsSI2267Teq6 wD3R0dGBgYE8z/M8L3TIQkJC0KsGuUGMgfhmz549ePDgll/9/f1/+9vfYiTK4wQFBS1fvtzHp7WV aGxsXLx4sYQlAVwNMQa94oknnggICBB+ZhjmN7/5jbT1QPc89dRTQUFBws8DBgx46KGH/Pz8pC0J oB3EGPSKxx57rOXnmJiYCRMmSFgMdNusWbOGDh0q/BwYGJiUlCRtPQBXQ4xBrxgzZkxsbCwRDR48 +JlnnpG6HOi+Z555JjAwkIiGDBkyY8YMqcsBaA8xBr3lmWeeGTx4sNPpfOCBB6SuBbrv17/+dWNj Y0BAQHJystS1AHQAMQa9ZdmyZXV1dffee2/byz3A44SHh8+ePdvhcPz617+WuhaADuDrz9BbAgMD 8/LybrnlFqkLgZ76/e9/P2DAgDFjxkhdCEAH8PVnAADwYBhUhN5SW1ubkpLyt7/9DYdKnu6rr75a uXIlx3FSFwLQAcQY9AqHw7Fs2bKzZ8+++OKLO3bskLoc6L7jx48vWrTorrvuuvfee0+cOCF1OQDt 4dwYiM/hcCxZsmTkyJHvvPPO6dOn586dS0RPPvmk1HWB244fPz5//vxt27Y98MAD4eHh8fHxOp3u pptukrougFaIMRBZ2wwbMGBAVFRUcXExkswTtc0wInr44YeJCEkGcoMYAzG1yzDhQSSZJ2qXYQIk GcgQYgxE02GGCZBknqXDDBMgyUBuEGMgjutkmABJ5imuk2ECJBnICmIMRNBphgmQZPLXaYYJhCSL i4srKiqaMmVKX1UH0AHEGPRUFzNMgCSTsy5mmODhhx/meT4uLq6wsBBJBhJCjEGPuJVhAiSZPLmV YYJHHnmEiJBkIC3EGHRfNzJMgCSTm25kmABJBpJDjEE3dTvDBEgy+eh2hgmQZCAtxBh0Rw8zTIAk k4MeZpgASQYSQoyB20TJMAGSTFqiZJgASQZSQYyBe0TMMIGQZHPmzGEY5oknnuj5CqGLRMwwAZIM JNEXMcbzPMMwDQ0N/v7+ffBybnG5XL6+yPKuEj3DBEKSzZs3j4iQZH1D9AwTIMm67tKlSwMHDpS6 in6B72UFBQWLFy+OjIyUYYYRkZ+f3+TJk1esWFFUVNTbb4Wns9vt8+fPX7Vqlcvl6o31nzp1auzY sW+++WZvrBzaKisrGzly5L59+3pp/bm5uaNGjTpx4kQvrd+jVVVVPfTQQ1OnTg0ICJC6/evYyJEj Fy1alJWV1Uv/6aLrxRhzOByrV68eP358Xl7e999/33sv1ENlZWW7d+8mojvvvNPpdEpdjkz1doYJ kGR9oLczTIAk69Drr78+fPhwlUr1n//8R7YhYTabDxw4sGDBAiL64YcfpC6nc70VY8IQ4oMPPnjx 4sVeeglx1dbWrly5cvbs2Xa7XepaZKdvMkyAJOtVfZNhAiRZO1u2bBkxYoTRaJS6kK7atm2bv7// sWPHpC6kE70SY42NjUuWLFm0aFFvrLz3NDU1Pfzww8uWLWtsbJS6FhnpywwTIMl6SV9mmABJ1kKj 0YwaNernn3+WuhD37N+/PyIi4r///a/UhVxPr8TYSy+9lJ6e3tTU1Bsr71VNTU3z58/fvXu31IXI Rd9nmABJJrq+zzABkozn+ePHj48YMeL06dNSF9IdO3bsmD179qVLl6Qu5JrEj7Hq6urhw4d7UMe5 nW+++WbEiBFnz56VuhDpSZVhAiSZiKTKMAGSbOnSpS+//LLUVXRTY2Mjy7L79++XupBrEj/GkpKS 0tLSRF9tX0pNTU1OTpa6ColJm2ECJJkopM0wgTcn2aFDhyZMmNDQ0CB1Id1XXFw8ZsyY+vp6qQvp mMgxZrFYQkNDL1y4IO5q+9iFCxeGDRtWXV0tdSGSkUOGCZBkPSSHDBN4bZLNnz9fDu9/DymVyrff flvqKjomcoy9+uqrjz76qLjrlMSjjz766quvSl2FNOSTYQIkWbfJJ8MEe/bsGT16tFcl2ffffz98 +HCP7ooJDh48eMcdd0hdRcdEjrHJkyd/9tln4q5TEp9++umNN94odRUSkFuGCZBk3SC3DBN4W5Kt X78+PT1d6ipE4HK5IiIijh8/LnUhHRAzxvR6/S233CLiCqV1yy23lJSUSF1Fn5JnhgmQZG6RZ4YJ vCfJmpqaxo4d++2330pdiDj+3//7f88995zUVXTAR8QpTD755JO4uLguPLE2J4FhmPQyx+UHHKVx TFxJbRcWjGMScsqIaveujmXaiEveVuG45mLVZR+uX50QFxe3fmdhTZc2hYgoLi6uqKioy0/3eL00 X6JYxo0bd/jw4ZdffnnHjh1S1yJ3vTRfolhWrVr1yiuvxMfHG41GqWvpXRUVFY2NjZMnT+70mWU5 yQzDbCupvvxAbU4Ck7CzrPMFdyYwcTtriWrLdrZtEpnY1fll1ddftuLgrNuLVAAAIABJREFUpoT0 /M7b3ctk2ySKGWOFhYVdizHB1sRXjrj7Eg1Ep2xOIqo1c2xGntFkMhqNnF4bvSt1Ump+h0HmqMgP ZxedmJr44p9+pU+JH5Zd0sXXEqY3dbdCDyXzDBMgybpC5hkm6GaSOcrWJySvT05gGCYh+0MHEdWW ZyfEMgwTm5Bd1vVD1L7iRpPYUE9EqbNeqnBdfsBGpxqcXVjSRudaf9HojSaj0WjUq+O4lezvyq59 cO+qyp+k3Kg9ds51zae0N2vWLKPReOHChS4v0VfE6tY1NDQMHjz4/PnzXXiuTaNsfnWN0cbzPG83 KEiht/E8z1cWaxRERMQmZnHWdjMc2tQKUqgMl3/gWv5gVCmIVZ0x5inZNL21+cl5acq03K9zlUSZ xcJDVkNulkbfxcmmzp8/P3jwYA84N2vnMpRJGUlKIlJmFdh5nrcZs5QsEbHKLM7ahRXIeCzxahhd vA45jyVeze3RRbtBQZSWx1kqdQpidRZnXiJRRoHNaSvIZEmZK7cZUR944IGcnJyuPJNTJwpNoiJL z/N8m7aOd1oMmUqWiIiUGr35qgUVxKptPG/j1ERKrqV1s2iJKOeDvVc1icI3eiszhNdTqm3ubNGC BQsOHDjgzhJ9QbTeGMdxN95445AhQ7ry5AYbKTXF2gx6bMrWM20ery3PGTf3sWi1rtKkX2Fexw7b fOaa66BzjvMucjkcjtrqsoOFRTR+ROi4G4O5rW/rKoiIar7etFUbMzX8ko1Y69FNq+MYJu6VL0c9 8euZXZxWesiQITfeeCPHcV17uoSceu0u+z2bLJU627p1n1e78p+csu6mLJvTljU9l31s7/WPtjyi H9aW0CfbvHmzWq2WuhZ58Yh+WFtu98mczhA2a+OKqWFRsx9kuc+Mn765h9VnLAz2DV747C6FtsB4 7c6HJPR6vXD7oS4wkzLXqFcVrZuVX9H2X7ZqY/j0jbTKYDIVqIIfmxW5t/w6o4Cnqq0Ol8PhcNQc +ccHRIqps2+5qkmMJKLC9eM2p+XpcxPplHtbdPfddx89etS9ZfqAWHm4d+/eBx54oGvPtakVpFAb hWOrxFwTz3NCb0yf1eaQylrMtnTX2i6oMrTtz12myOOsPM/rMoiUGjvPV2qTiDLMTpNw0JGkyivI zSIiyijo+iHbgw8+mJub2+WnS8SmV7JZVp7nebuapczDRQpiha4tb9crKJG7dvfTs/phbZ06dWrM mDE7duyQuhC58Kx+WFtu9MlseqVCZeV5nrepWMr6vEhJCoO9+U8KSqvs1ULdZLfb/f39uzhBq9Cp svPO3EQiVmXj7RoFKVQGG6emln9n3qpiic0yXL3g5d7YFZLUeufVTSLPm3WZRIkmnjdplMSq3ZoK ff/+/cuWLXNnib4g2h0jT5482ZUzma0a6ilg2lt5SZNW/jZp5uZIIqLarz/kFA9Oba4pcOh4Ikt9 x32JBhuxmdqClF84653kopDIqNAAIqLZD6uJffeEY3n527sUai7C5TxHpMjS71w7k4hMAysmrSw2 v7Qwqms1Tp48+eTJk25slFSGCz1MZwORvx+F0HA/P+EBIhoRco3up4j9MEdNtdXuJPIbFhHWxc6u y+FwkW9AQDc/gePGjSsuLp47dy4RpaSkdG8l/YZ4/TBX9RmLk4gCgyNCg7u4iMPh6v6OJFq1ahUR xcfH63S6zu+0ea5Nh8t/4iK2KP/zM9PiIire317E3jWsuzX0BpPJNGHCBB8fN0a8nOT7yF90WeHx mw/OvCVSOOfVQLRqcvOuCIxgia77D5bHVc4OISe5/IIihf/F9k2io3x1/EbKyHNWlB4+qiVu/Cel 5XeyMcFd23/ybBJFG1T89ttvb7zxRneXmrjif1SKornLkvZQiB/5jY6mIsv55r85608RhQdd890d PuSGiLCIqKioqInNGUZEAVMXZlDR7l2av2opbckUCoicpqAiEhp1Ch8z0a3y5LnPOtDR/zYRVby/ vYiN6fB/W7QMc53JSY8LHBYeGRkZGRkeyCTkN59qr82Ja3OpVW3Z+liGYZJLa4hcVTtXx/oFBgYG +sWt33um66eYryQk2UsvveTlo4tiZZijojCZ8RN2ZOSwkNjkbRXC8NWVFxJXl+xkGCZ2/Ycuotry gwmMX2BgoB/DZB8s7/ZLuzG62HzERv5EATT0gT25m+MjGYaZtMqct++RLgZv3+hek0hhcfs0iZuV s1btofH+wpFo2c+X/0fOma+/sGJCdJTQJrYcT7ZvEskZxBL7wcopk6an7CKirYum//k7e1eri46O NplMPM+7vV29Sqxu3YwZM7744ouuPdemVhCrau4a2015RESkNNj4Sm0aEas1Wnneps1gqf0oQcuC rec/r2ZQK4laT13qsxREScWVNqfNlKUgSszr+qDiF198MWPGjC4/XSJtRlrULKkMNiuXe3n3KvKM HZzBFW8s0aJWEJEit9hotdmsZk6dxBKRhrNdsZdtXBoRUaLewvO8syCDiDI4q91q0imJ0gp6NBTk 5aOLYo0lOs0FLBElZukrLTabrdKQl0hElGFyXnEFlqVYRUSUlmfjed5pSiJSqnRWu43Ly6DLz+m2 bn6fzG6zWCw2uV3dwfNZWVnr1q3r4pNbxgZ5nud5cyZLRKRUGXiLjiVKyzU4ed5crCIiNWfrcEEb p77WLmjXJLawcyoilbs7bezYsXK7l6ZoMXbTTTd1+QveNrWClOrW6wz1KqUQYzxvzU1jW5vg9pfZ 2dQKUmo44dzYtWLMWalliTJaGkdnpSrx8irZDIPFjc/7N998M2XKlGv9tbq6+o033pDpDaOv/b8t 4vkwS3EWEeWa2o6uW1QKosRce+sZUC6JiCjt8n+fPTeRMnUW4WeNgqj50qzu89okE+98mLMgjYgy r7gMzqwloqQ8kxBjnLM5wxSZBc37284pWy6NsxVT+zPZ3eFZ34zevXs3x3HX+uuGDRtefPHFLq6K 0yhJ0RozdmMuESWqOZ7nTdrMll6HcLrrigXVzQu2v1KxjfZN4mU2TkWs2zEWExMjtx0kWoyNHTu2 slKcM6w2i7my0izu4ZXNarVY2l+/36mqqqoxY8a0e9DpdB44cGD+/Pn+/v5EpFarxSqyD4h7TYdB pSBW1e5Yg1MriVVZeZtaQZSYkaQgokRDR/8rxrwMItJ05TsBnfHCJBP1mo4Ohzcu96ftBgUp1MIV Uh1f1G7VJBJRhij//56SZGfPniWioKCgSZMmbd269eqZxNPT01977TVRXstps5rNZotVFjem/8Uv ftHlgbc+IlqMhYaGnjt3Tqy1ycS5c+dCQ0Nbfj127NgTTzwRHBwcEhIiHBwFBQV5UIyJfl2iUZPY ZiSkGadWEmVUOq+4mjQtr/3956x6FRFlaE2iVMJ7WZKJfF2i05hGHcSYRhj8sBsSW/ekUmduF2RO XQZLpCx2Z5zj+jwiyc6ePRsQENDSDvj7+99zzz1arbZleOY3v/nNrl27pC2yN9x9992FhYVSV3EF 0a5UrKur6+KXxjzIkCFD6urqiOj06dOxsbEOh+PSpUsu1xXXJOTn53vGZSBEx48fHz58+LvvvuvW 1VPXUW8zE3fBQdT21LqzwUbsqGG+1EBEiixz4e/K10+PX/mgotKwNKrl81a7PymVMnUvLXXvopvr GDdu3KeffrpgwQKXy/X000+LtVoZMhgMy5Yt27Fjx/333y/OGn0jYxR01Yw1lmNFZFtYT+RXS5So Nux+PCjZb0p84puWwrVhLc+qNaRv5jTGT+eEidaYrFq1ys/Pb8GCBadPnxZrnb2BYRjhh/r6eiL6 6KOPSkpK6uvrn3/++U2bNl28eLHleLc/GTp0aG1t12ew6guiffIYhnG5XB7x/dmuc7lcwifVz89v zJgx5eXlfn5+7WJsyJAhEREREhXonh9//PHs2bOXLl1qOYrsoTG3LSRa94+yJ5KntgRZVX5qEZv5 YjAR2Ujx4KII8o3YuC9p8xTl0r+Yjz13+Z3yi1qRof3VbFHKaHH+/Hmr1eopu6PbwsLCfHx8RG3i A6NmEZe6u+LJaRMvNwm1ZUe2Eqnn30T0nY0UGx+dRr70sl61a1bq73betTt52uVFR6xKU82ZJPJF gmazeeDAgT/88MMNN9wg7prFcu7cuRtuuMHhaL1IeMCAAY2NjcOHDx89erTwSGNjo0TV9SKn0ynW cbBoxOrWDR8+vP/dZ/Ls2bPDhg1r+fXHH398+eWXx4wZM2jQICGwPWtQsbGx8eGHH77nnnvsdrEG 2S1ZLBGxmmKjzW63mg1ZCiJSFFv4dtejWg1qIlKqWq7msBu0Gq3BIlIZPM/zx44dCwsL+9///V8R 1ylbVVVV48aN27Ztm1grdFZqiYiUmfpKi91ur9RrWCJSamz8FVcq8jyvy2SJKNfY/BFyWrlcjbb9 QGPP/OUvf5kwYYLcLodrp+2gYnBw8KBBg9asWdP2pFFSUpIHNQ5dN2/evKKiIqmruIJoMRYVFXXq 1Cmx1tZVdoOCSGUQ4RqBDlVWVo4dO/bqx7/44os1a9YEBQURkWzviNoh8ZPMblIlsa2HRWySrrL5 2rV216MWZymJKM90+a9sa8j1nFdlmED0JLNyeW3nxlFk5DYfZVwZY7zTlMESsc2XNV45zYQIPCLD eJ4/d+4cEfn7+8+ZM2f//v0Oh6PdE373u99JcutdQxZLmT29+vc6pk+f/uWXX/be+rtBtBi7+eab y8rKxFpbl1kNBTqj21cgdlVZWdnNN998rb86HI7333+/l1669/RCn0y4uLSy0izeWX53eGGGCURP Mp63N+9JiS6K85QME3z88cc//vjjtf66cePGF154oS/rEViMxcWcmOMc7UyePLm8vLz31t8Nog1x hoSECFdDdJ3jTMmmBOG2YQn5pcKtcVylezfFMgzDxKbvLBROI5bnr0/Ozslezcx/dE1c+t7mc4s1 Jclxqw9WVH/6f+9XWl1EVFW4M+7yvcfKa4iIaso/TI5rfqSspjtzRdTV1V3nJK2/v//ixYu7sVpp +fj47NmzZ8SIEUuXLm07st8TwcJ0KhHineXvMo7j5s+fr1arly1b1ucvLrGxY8cePnz4tdde2759 u0irDGjek6HinD11y5YtW7Zv33748GHZng9rJz4+ftSoUdf6azeaRHJVH8xOFu4Xlp5zRPjnvLod a2kSl/zxlYTY9JLmO9TU5qcnpO8tt508+sm354jIVV2yXmhgY1fnl54hInJU5aQnCI/sLbnOvOvX c/HixeBgWc2XIt65sdWrV2s0GneWsOcqiZRqo9mkzVQQsQY7b8pLIiKVVm/QqYmah6Q44SvoiZm5 ORuJWOGLs5V5SURpphqDgijLYLVxGiJKUuuMnDaRiDKLhW+/KzLzOGNxhoKIzerG8YlGo1m9erX7 y3mA3uiT9T2v7Ye1VVVVFRUV9frrr0tdSI94Vj+sKw4cOLB48WK3FrHoMoiUBZyJ06mIKKPY2mE7 1tIkaj8/nCh8RZ1vnktdzdkMKpay9M23YlFmGUycJomI0kxOq1pBxKbpOE6blUhEeZVuj57YbLag oCB3l+ptosXYpk2bMjIy3FnCpmaJktQmi513Wjk9Z3VaVWzrl1cMzd+i5Tm1ovn77U5TElGatlKY /YHN0recGzNksaTQCOPzlmJVUmbBl2ply6wE9so8ItK6v88yMjI2bdrk7lKewtOTDBnWwtOTrP9l GM/zJ06cmDx5sluLGDWJRIkFnNnJO82cnqu0ch21Y61NYkcT2BtUCjZLmBqfLs+Ww2UkZn75tYZa T06bM+mKU9dd9J///OfWW291d6neJlqM7du3b/ny5W4tYtE33yGTiM1Q66x2LpGupFBbL+8VYZHi TJaUeXabnhUOJZpj7L9qBSmu3CUtt6FroepwJonrWr58uSfe+aLrPDfJkGHteG6S9csM43m+oaHB 39/fvcnqbFzm5ctsFEkqg8XZYTvWtkm0c2oihcFuy1U2t4GXY0wlpFoLO6dptyql+9dYuXNDrr4j 2rkxYeZjd5aotQ2Zo3U6rWajLnfF5pT4/eVNQURJeUan026z2y1GfcGL89oNwd6+Mp20e97RvM2x qvjW79L6jo6moirh7BrVlOZn7zxS12AmVmVxOm02u91aqSsofph1ezzXZDJFR0e7u5QH6Y3zZH3A m8+HXcvYsWOLi4tfffVV8c6T9QWPOx/WdQMHDoyMjKyqqur6IrVWv0fesjttFq44L3pX6mMaztlZ O3bVBPaXOYnoxDnhkgBHxc5NO0/W2YhYndnutNnsdhtXXLBR6XbjVlFRIccmUaw8dLlcISEh7nx1 zJREpFQLd+nWsURqzqpNImKzTDaetxkziCipgL+yN9Yy93PzcPDlQUVzQfPU+E5hwYxiS3EmEZvL WXjeXqxSECmNbo4pnj17Njg42OPuJ9kNntUnQz/sOjyrT9Zf+2EtEhMT3ZqPSp9JxKrMTp7nrbmJ xGYZOmzHrmwS209g3/xXa7EwNb6dtxWrFERJphqDkkipKrbzvMWgIaIsvdtfVbr77rv//e9/u7tU bxMtxnieX7x48f79+7v+fKM2oyVN2SSNhed5G5fR8h0kNlP4hiV35T7jNIlEymLh/bdzic13LrDm ZbSMUKYZrE6etxdktX4NRuP+N23379/v7hlaz+UpSYYM65SnJFm/zzCe5zUazYMPPtj15zvNujZf 3UvUVdo7bMfaNYntJrBv+WtlQVbLgipdJc/zFn3rnfmUWTp3Lxaor68fNGhQXV2dm8v1OjFjbMuW LcnJyW4t4rRZKisrzZa2Z62cVovZYu3OBPc2q8ViveIEmN1qMXf3XkTJyclbtmzpzpKeSf5Jhgzr IvknmTdkGM/zP/zww4gRI5qamtxZyG6urKw0W9r+E3a/HbPbLBar3XnFI+Zutq/8oUOH7rrrrm4s 2NvEjLGvvvoqOjpaxBVKKzo6+quvvpK6ij7V2Nj40EMPLViwQIZJhgxzi5yTzEsyTDBx4sTr3JPM szz//PN/+tOfpK6iA2LGGM/zsbGxH3/8sbjrlMRHH30kw+tK+4A8kwwZ1g3yTDKvyjCe5zdt2pSS kiJ1FSJoaGgICwszmUS7s5KIRI6xN954Q4aXY3bDAw888MYbb0hdhTTklmTIsG6TW5J5W4bxPG82 m4cOHXrx4kWpC+mpffv2xcXFSV1Fx0SOsZqamqFDh549e1bc1faxs2fPDh06tKamRupCJCOfJEOG 9ZB8kswLM0ywePHinJwcqavoqXvvvTc3N1fqKjomcozxPP+HP/xhzZo1oq+2Lz3++OO///3vpa5C YnJIMmSYKOSQZF6bYTzPHz16dPTo0R7dISsoKJg0adKlS5ekLqRj4sfYhQsXRo4caTCIdg+OPmYw GEaOHHnhwgWpC5GetEmGDBORtEnmzRkmWLVq1R//+Eepq+imS5cuRUdHy/DrYi3EjzGe57dt23bH HXd44heHXS7XHXfcIYcRGJmQKsmQYaKTKsmQYTzPnzx5csSIESdPnpS6kO7IysqKj4+Xc3veKzHG 8/zq1auVSqWct/xqjY2Nt95666OPPip1IfLS90mGDOslfZ9kyLAW//znP0ePHi3BvYV7Jisra9y4 cT///LPUhVxPb8WY0+mMj49fsGDBuXPneuklxHXu3Ln4+PjExETPit6+0ZdJhgzrVVVVVWPHjt2+ fXsfvBYyrJ3t27cHBAQcPXpU6kK66uWXXyYis9nc+VMl1VsxxvN8Y2PjihUrGIZ566235Pw94q++ +uqtt94aNWpUamqqe9NRe5O+STJkWB+orKyMiorq7SRDhnXon//8JxFt3LhRp9M5HA6py+nYDz/8 sG/fvoULF86ePfv06dNSl9O5XowxwdGjR1etWjVlyhQ/Pz8RZjIWm5+f35QpU1atWuVBh0hS6e0k Q4b1md5OMmTYdVgslpSUlDvvvDMgQIJbbHfFqFGjlEqlSqVycxotyTA8z0v9poHHaGpqWrVqldVq 1Wq14v4T4t4rfayqqmrevHnPPvvsU089Je6a+/G9V0CeRLvfGHgDHx+f3NzcYcOGKZVKEe9Phgzr e1FRUYcPH37llVfeeOMNEVeLDIO+hxgD94ieZMgwqYieZMgwkARiDNwmYpIhw6QlYpIhw0AqiDHo DlGSDBkmB6IkGTIMJIQYg27y8fHZs2fPsGHDEhISupFkyDD56GGSIcNAWogx6L4BAwbs2bMnNDTU 3SRDhslNt5MMGQaSQ4xBj3QjyZBh8tSNJEOGgRwgxqCn3EoyZJicuZVkyDCQCcQYiKCLSYYMk78u JhkyDOQDMQbi6DTJkGGeotMkQ4aBrCDGQDTXSTJkmGe5TpIhw0BuEGMgpg6TDBnmiTpMMmQYyBCm BgbxNTY2JiYm1tTUHDhw4OTJk8gwz1VVVTV37tx169Y9+eSTyDCQJ8QY9AohyX744Yfy8vJdu3Yh wzyXkGQrV6785z//iQwDGcKgIvSKAQMGvPXWW/Pnzz906FBCQoLU5UD3RUVFabVaq9V66NAhZBjI EGIMesvgwYOPHz/+/fff+/jgY+bZBg0adOTIkYkTJ0pdCEAH0L4AeIOanasT9pbXEpGjIj9hdU4t uUpy0hmGYWJXHyyvIXKV5W+KZRiGid1WWCV1tQBuQIzB9dSU7oxLzncQETkOpifsLK1xVZekxzEM w6zedLCGiGpKNyXEMgwTu3pblWj30QTRhd40WZt18AQRnfjgTe2YiY7CjbMeCzTa7ObtU5VT1pbX GVNXbtxQ6bSbNqTGP1Z65a7keZ5hGGkKB+gMYgyuJ3R8dNGuN4/VEjlObN16Knq8fXP4rMA0o9Ne OTVfuXZvefn+P2wM3uTk7ZuCUpfuKpO6Xrim21dquHWHaqjm49Qi9a9uL//sA0ocerLo0H9qhrDE VTuDoolW/mnjv74bY7JopwVcsSxiDOQMMQbXFTpboyjSfl1Te+KDIkX6bCrPJxpad/Lfh46Fx7Fc xQW/4dG0R7lx579GPm369MmpUpcL1xQQo0ij/ILCglxKWxhDP5/kFCMC6qxWq9U/XbNpbOBElcVY ED9Uu27WpPDVpbVXLIsYAznzlboAkLmABc+lPfaPgmmB+UlpB8n6GUeKxy9ZrVai2PQNU8ZMnKky 6u8/+F7urJSVSjV3IBlJJltRq1Xjp8evUqj0URRgv0tRVD658NcLqeZI3LBdt86jcROOWfkNC3/9 2Bgm/Hura1pwa+OAGAM5Q4xBJyLufEi5aNZKUuhtUQGBNiUVjVtQuDSCjmTHvdYwfeDbkfoHrS9t WfjYkjHhmlOEGJMxVplIqdrf3BdLRDGPvpkxc4qQTWl5xlvHD1cnKocxG4mIEtWWqCtaBsQYyBli DDoTPH1NEmnrn4wNJqKpr2kzJkUKLVqG0T515K1q5axhm1kijtR6i7SVwvXZbeeIshZNDCAiCoh5 6Zjz2eoa3+DQ4ABfIkrezT/wlzN2Co4IC5a4UAB3IMagU3brd5S5OV446z9x6UtO+7M1dt/Q0GBf IpqZzNsfOGO1Bw+LCA64/npASmU7V7Mpe1R6a2jrY76hYWFtnxMaFhHafjki9MZA3hBjcF2OsoRA VqtQW2e2tm++AaFhbRMrIDSi49YPZGTq42/aHtEEB3fnXx4xBnKGGIPrCpiy22bzC0ZHy/P5Bgd3 d7AQMQZyhhiD6+tB4wf9BWIM5AzfGwMAAA+GGAOATqA3BnKGGAOATiDGQM4QYwDQCcQYyBliDAA6 gRgDOUOMAQCAB0OMAUAn0BsDOUOMAUAnEGMgZ4gxAOgEYgzkDDEGAJ1AjIGcIcYAoBOIMZAzxBgA AHgwxBgAdAK9MZAzxBgAdAIxBnKGGAOATiDGQM5wvzEQ37lz53Jycojou+++e//996uqqsLCwn71 q19JXRe4LS8vr6qqqrKy8scff/zLX/7CMMzy5cvHjh0rdV0ArRie56WuAfqbNWvWaDSagQMHtjxy 6dIljuOmTp0qYVXgrp9++mn06NF+fn7Cr0KHbMaMGUeOHJG0LoArIMZAfCdOnLj99tvr6+tbHhk/ fvz3338vYUnQPbNnzz569GjLr8HBwQcOHIiLi5OwJIB2cG4MxHfTTTeNGTOm5degoKCnnnpKwnqg 255++ung4OCWX/39/RUKhYT1AFwNMQa94plnnhk0aJDwc2NjI06Meaj777/f5XIJP/v7+ycnJ+Na D5AbxBj0ikceeaSl+bvzzjvDwsKkrQe6JzAw8P777/fx8SEihmF+85vfSF0RQHuIMegVoaGh8fHx DMOEhIQ8/fTTUpcD3ZeSkiJ0rG+++eZx48ZJXQ5Ae4gx6C1PPfXUoEGDmpqaFi9eLHUt0H1z5swJ CAgICgpKTU2VuhaADiDGoLfce++9dXV1y5Yta7liGzzUmjVr6uvrly9fLnUhAB3ABffQi6xWa1BQ UEBAgNSFQI9cunSprq5u2LBhUhcC0AHEGAAAeDBMRuV1fHx8+uWxC8MwTU1NUlfRp7ArAQgx5oV4 nu+vbZ/UJfQ17EoAwiUeAADg0RBjAADgwRBjAADgwRBjAADgwRBjAADgwRBjAADgwRBjAADgwRBj AADgwRBjAADgwRBj0G21OXFMQk4ZUe3e1bFMG3HJ2yoc11rKUZK/bXVCXFxC8t4jVX1ZLlxL2c4E Jm5nLVFt2c62+5GJXZ1fVn39ZSsObkpIz6/tm0IBOoIYg+5rIDplcxJRrZljM/KMJpPRaOT02uhd qZNS8zsMstKdD81a+bfb1/wpLY5WzR2XU37NuIM+ZKNzrb9o9EaT0Wg06tVx3Er2d2XX3kWuqvxJ yo3aY+dcfVAjwDUgxqBHhrf8MOrGmIkTY2Jips5cmq5SkP7Msb3r49L3Nh+n15Qkx60+ePI/mSla FVeydmnc0rU79RrVKD+nVJXDNSinx8ZMjImJiZmZvH4T0Z7Swr98FIkGAAAgAElEQVQnxKaX1Ah/ rc1PT0jfW05ERFUbx60kIgrB3KwgJcQYiOOc47yLXA6Ho7a67GBhEY0fETVxaNHWrC+riYiqdG/v Khpxo2+llujC59tWxzKxcasrpqxYODFY6sKhnVPVVofL4XA4ao784wMixdTZtwRzW9/WVRAR1Xy9 aas2ZmokERWuH7c5LU+fm0inJK4YvByOokAE/iHErZvrt67lAUUet2jUFGsSrXv/aFXc0pFFb+5i s/QRF78moo0pH2q0BfF69apZkaf1ludmhklXOFyNi48MbPklSa1nh059LIPi9xxRrZj485E9HGUs mRp8pnBT/OZEE7+CcvYQEW7vDRJCjIEIGmzEZmoLUn7hrHeSi0Iio0IDiCg0MZOd+/aXmxVjthTR Bs10sn1NRLnGfz8SE0BL72z4IOTNw98jxuQmj6ucHUJOcvkFRUaEBRDR7IfVxL57wrG8/O1dCjUX 4ShfHb+RMvKcFaWHj2qJG/9JafmdbEwwmhOQAj53II7hQ26ICIto9+DtK9Np4553NCM5VhUf5etX 7k9Ew4YHEBGRn/9wwnG8/CgmREdFBFzxUMDUhRmUsnuX5piW0t6cQmQMYon9YOWUzcLfty6aftZg 2z0NI8QgBcQY9Mi56/41IGZBJvtYSiol5ZlCiShGkUG0bks+u3Gx33f/2lJEK14c0zd1Qtc5nUQB 7R6LWqFWTk9JJaVaG+FLNHXnsebbdTrKtgWyZOPXIsJAKrjEA3pkfIgfEfmHXOvvEQnpiUTKxPiJ REQUlWHUDt+8MjIwMJxdOT5T+/QcjCjKQUjrJacUEtRRD5lduIYlykhZ2C6unETE9mptAJ1g+uVN 0OE6GEbqne5yVFusFDgsLLT9MX9PSL9dfa6/bnJ/3S7oJfi4eJ3+2kb01+26jv66yf11u6CXYFAR AAA8GGIMAAA8GGIMAAA8GGIM+khpdiyzqUTqKqCnakuzGSa7RuoyAFrge2PQR8Ys3V7snCB1FdBT geOX6nSEb4mBfKA3Bl3gqj6YnSzcgio954hw446a8g+T45rvLlZW4yKi8vz1ydk52auZJX985eo5 0W0nj37y7TkiclWXrE+Ibb6dVekZIiJHVU56gvDI3pIzEm2kV6j4cGdc863EtpULdx+46s13VOSv Tt+Zn5POMPc++1Bc9ofNt4U7U5gdl5xTbT35/mcn7URENZc/FbHrmz8VrtK9m4Rdm76zEDchgz7C g5fpxk636DKIlAWcidOpiCij2MpbdCyRIjOPMxZnKIjYLAvPc2olEVFipvbzw4lESXkmnud5azFL pOZsBhVLWXqer8wgImWWwcRpkogozeS0qhVEbJqO47RZiUSUV+nsm+3ydG5vst2gIMrUGipNxRlE lJjn5Dt4822cmoiIlKrcQ++tJVJobDzP8zaNgihTZzNkEamsPK/PUhCxuXpOn5dJRGrOZspLIiKV Vm/QqYlIqeb6aLvAu+Hj4nW60UYYNYlEiQWc2ck7zZyeq7RyaiVRppnneZ63V+YRkbbSyakVpFDb eJ7neV0GkVJj5/lKbRJRhpnnDSoFm2UQmkidRViSy0jM/PJrDRHlmew8z/O8ObO7zZ8Xtn1ub7JN ryDKzNNb7bzdYtIbTLXGDt58G6cmYnVWnud5m0FFxBZbmw9Hck12G6ciUtnsXCJRRkHzR0CbmaQx nFSxpFAZhJcyqJXEqqx9s13g3TCoCJ2LWf5cpnLPIjbSj/FL3F7iDAomCibaGMkwDMMEjltJRJXn 7M4GYhfeLpw1mf2wmrTvnnDUfvb2LoX64TZzBjcQZcQIU1AFTH1p94ZbfIiIVk4KZBiGYSI3ElED 7qXZO4Jvek6VtHHlrGGBTOD8Fyou+vo6iTp+84cP9SUiCp52XxpxBV9VV5f8g6PMeyZennjF6TQT jQoX9nbA0g07f32T40uOilKnC4PP01O0NNy/7zcRvBBiDDpXa/V75C2702bhivOid6U+puGcDWZi VRan02az262VuoLih9krzvoHTF2YQUW7d2n+qqW0JVNa/+AkohPNN713VOzctPNknY2I1ZntTpvN brdxxQUbldF9uXXew1VrHXff//BOe6VRr7nPvGru1pOOTt/8iQ9lKTZrNBr1VqVmZfsZMJtnX3Qd 2Zl9sMIZRJSUZ3Q67Ta73WLUF7w4D1eCQB9AjEHnTrw7ZdL8XZbAsKlz4uclEhGNuU1B3N8+MtYE B9OXux+LX/TaVVPdR61QK7emphYp1YqI1gtig8ffxpL27f2lDqo9suu3KRtLB025S0nctvwvXcHB tSf+l5276OOfXH24cV7EVamdMin8YJUzKmamYu4sIhoSc803v6VHPH35k7Rn3Totu/a+mNZ1BUf/ SkmpGzQVta7q0j1zU9ZVNo2/L4l2bTpYZQ8IdlZumTJr0Z5KXAkNfUHqUU3oa93Y6U6zTtn6kUnU Vdp53l6Q1fqYxmDheZ5TKdgsQ+tSlVqWKKOgUvi15a+VBVktC6p0lTzPW/TqlkeUWbruXODhlSdU 3N9kiyapdTr6jDwj39Gbb+PURErO3rpUloIoMVc462njVMSqbDzvtOiTWhbM1Np4nrdxGS2rZzON 9o6L6IXtAq+GKTi9TnfnXXWcqfrZ6Rc0UrgfsPBQTbXVRcGhYW7f9tdRW13rCg4NDfBtfeSM1REY HBra3VsIe+F8st3b5JrqM7Z6ChkW3vpWd//Nd9RU11JA2wVdNdUWl28PdqRX7kroCXxcvE5/bSP6 63ZdR3/d5P66XdBLcG4MAAA8GGIMAAA8GGIMAAA8GGIMAAA8GGIMAAA8GGIMAAA8GGIMAAA8GGIM AAA8GGIMAAA8GKbu9DrCfTSkrkJ8/XKjrg+7EoDQG/NCTU1NfTZl5/Lly/Pz8/vmtZqamqR+a/ta n+3Kjz76KD4+vm9ei/fKXQk9gRgDgE5gkkOQM8QYAAB4MMQYAHQCvTGQM8QYAAB4MMQYAHQCvTGQ M8QYAAB4MMQYAHQCvTGQM8QYAAB4MMQYAHQCvTGQM8QYAHQCMQZyhhgDAAAPhhgDgE6gNwZyhhgD AAAPhhgDgE6gNwZyhhgDAAAPhhgDgE6gNwZyhhgDgE4gxkDOEGMAAODBEGMA0An0xkDOEGMAAODB EGMA0An0xkDOEGMAAODBEGMA0An0xkDOEGMAAODBEGMA0An0xkDOEGMA0AnEGMgZYgwAADwYYgwA OoHeGMgZYgwAADwYYgwAOoHeGMgZYgwAADwYYgwAOoHeGMgZYgwAOoEYAzlDjAEAgAdDjAFAJ9Ab AzlDjAEAgAdDjAFAJ9AbAzlDjAEAgAdDjAFAJ9AbAzlDjAEAgAfDQRaI74UXXnjxxRf9/f2dTqeP j8+AAQMaGhqOHz9+8803S10auOHnn3++/fbbL1261NTUVF9fP2jQoMbGxkWLFu3evVvq0gBa+Upd APRD0dHRgwcPrqurI6KmpiaXyzVgwICoqCip6wL3hIeHX7hwwWazCb9evHjRz89v0KBB0lYF0A4G FUF8y5Yta2xsbPmVYZj77///7d1/WFt1gu/xz6mJhGqwUEEX2mnpj1mq24NTxtvOrD8mQTutXRus /WULs1YdqKMr4Fztg4/yPEt3phd21jY464bu4033WjptwSo6M1R3gCt1dujjhhmDNqzCSp3SnYJN xqS3CT1n59w/DtBAw+/85vP6i+aX3+PJk3e+5yTfPHTjjTdGcEg0DYIgPPXUUwkJCcOXaDSa4uLi CA6J6FrMGAVfYmLiww8/PGfO4LPrxhtvfOqppyI7JJqeJ554QhCE4X9+7WtfW7FiRQTHQ3QtZoxC 4sknn5w7d676d0JCwr333hvZ8dD0LFmyJCsrS/37hhtuePrppyM7HqJrMWMUEt/+9rf1ej2AhISE wsJC/3f0FFuKi4vVA8KyLO/YsSPSwyEajRmjUHnyySd1Op0gCE888USkx0LTt2XLFlmWAdx7770p KSmRHg7RaMwYhcquXbt8Pt+f//mfZ2ZmRnosNH033HCDyWRKSEjgEUWKTswYhcqCBQtycnL42hcH nnrqqYGBgQ0bNkR6IEQB8OvPREQUwzgbo1CRZfmrr766dOkS3yrFOp/P53K5BgYGIj0QogCYMQqV V199NT09fcGCBWfOnIn0WGj6Ll26ZDAY1qxZs2PHDkmSIj0cotGYMQqJ6urq/fv3d3Z2Hjx40Gg0 fvLJJ5EeEU3HpUuX1q5de8cdd3z88cdXrlzZvn07S0bRhhmj4FMb1traunDhwq1bt77yyissWSxS G5adnf3qq69qtdoTJ06wZBSFmDEKMv+GqZewZLHIv2Hqt9dZMopOzBgF07UNU7FkseXahqlYMopC zBgFzVgNU7FksWKshqlYMoo2zBgFx/gNU7Fk0W/8hqlYMooqzBgFwWQapmLJotlkGqZiySh6MGM0 U5NvmIoli06Tb5iKJaMowYzRjEy1YSqWLNpMtWEqloyiATNG0ze9hqlYsugxvYapWDKKOGaMpmkm DVNt3bq1uro6NzeXJYugmTRMxZJRZDFjNB0zb5hq27ZtZrOZJYuUmTdMxZJRBDFjNGXBapiKJYuU YDVMxZJRpDBjNDXBbZiKJQu/4DZMxZJRRPBnM2kKQtGwYceOHSsuLm5qarr99tuD/uDkLxQNGyZJ 0qZNm7Ra7fHjxzUaTXAfnOhanI3RZIW0YeCcLFxC2jD4zcm2bdsmy3LQH59oFGaMJiXUDVOxZKEW 6oaptFrtm2++OTAwwJJRGDBjNLHwNEzFkoVOeBqmYskobJgxmkA4G6ZiyUIhnA1TsWQUHswYjSf8 DVOxZMEV/oapWDIKA2aMxhSphqlYsmCJVMNULBmFGj9wT4FNo2Gyx+XyyRqNPjlZF6xh8FP4MxTZ hg2TJOmhhx5KSEg4duwYP4VPwcXZGAUQuGG+9gLBX15Nc/fwdc3VRdqklLS0tJSURCFvb3v/6Pfd HdXG7Kp2+NqNglDd7oLsaj/V7pro3TnnZDMxvYb1d5x8oSDPaDS+UNPsGu+Gnppsoap93JsM4ZyM QocZo9HGmYd5gMLa1q4uh8Nhr6vU785dVlrfDeD8yYrc4rbati6319vX1VrSUJ6z7bBv5H0HF3XQ Zf6ksWltph74POeenM8n8YLGkk3P9Brm665PE9efWZn/ty9+r213bkrV6bFvq53SeFgyChWFyI/Z bF68ePEXX3wR4DqvzQCY7e7hC9oqDUBhl6TYzAaI5uErvI7a/EJLrzTi3jazQay0KVKPuaSksfOT CgMAQCyxuxXF22MtMQGAmF/b1htwYEePHr3llls+/vjj4GxnvPN4PN/61rd27979pz/9aSr389aa gIpW9R9OW22ltc0rdVXm51dazCbAbHNKfW1lJhFAYaW5EDDbnFMa2JUrVzZs2LBp0yZJkia+NdEk cDZGV03qfJh09X109vptwGdfenHrXxhgL04yFlUfebu986y0bMfrNUXpAc+AeC++deCA/f/p8543 ixDNe7cvSHTVPLB4V3Nmk93esBM712TUnw3wVl2dkxmNxjNnzsx8S+PbDM6HSVfcEJ2/2VtgFATj 339465OPrtZ5v/q3w4f37C7OrLQa/qz3qbQ1+9wbmtpal3YUH5z62Dgno+CLdEcpWow3D1OpszG/ d99uuwUw2NyKoihdTbUlJsPw86qszq4oUq/Dbrfb7XZHn3doNjb8IJLdAIPNq3gdVgB1XV5FURSl twIwWexjDeFnP/vZLbfc8sknnwRts+POdOdhiqIoitRVBgAoNNc11lYCQFmj5LWZgJKGHkVRvHYL ILap827Jbpr6bEzFORkFEWdjBEz7s/XSAAAJ8PT3p92zY/9bzYrk7e1qs5QY9m0pPu3xHF4hiqIo iiusZ675IIAsAZCkwZNmW5YlCoIgCBnlAAbGXBx9+/btBw4c4JxsLDP9XKIsXQQMlW01z2xet+P5 rrpC7GvtBdxAZmYKAAkDwM4legCAZvF6Eb7xH3AMnJNREDFjNMWGaYePFfrerSkGDEv0rn9KS0t6 uR0ANLr0pauLyl8EWi449c+4Bz27Kjnwg2khSW5AbOr1Sm631+u2tzaWm5aP899nycYShM/W6zJW GdAy9NmNtIVLr16lHkyWAHRcHOxOX7sd0/5qBUtGwcKMzXZTalgS8Intw87Ojo72U4deeGDLQVS2 Pp6K5HsrDdizq+ZUt0+WPa6z9X//d4Ap8xaNTj8owGkyCUBL52f9+uV3mWCvrv9Q1us9Z94Q71n/ qz9M8KLGkl0rSN8P09+xzoA9NafOemRP9z+V7UH+qgz/qxf+hYjDNcfbfZA76l+bxrkxfywZBUek j2pSJE18Psyf15bv/9QRTZZGx9B1vbUlBr/rDNZrPnBoHzw3Zs8HLHa3InWViVBPtPS1WYbvaaps muTZEp4nGzaj82GjSD3m4d0sltn6JHWXDX9CtauhYvhqABabe/zHmxDPk9EMcRWP2Svoa035XP0X 3Je1c5PSUpMnt06D7PNBp9MAgM9z3ulL1CcnB5q5jeXo0aMlJSXNzc233XbbtIYcD0KxTofH5fLJ SB5jP8qe/j4PUtJTg7VYy5UrVzZt2qTT6Y4ePco1PmiqmLFZKrLrJQbRLC9ZlKw1NXMsGU0bz43N RnHTMMzu82Rx0zAA119//YkTJ3w+3/bt23mejKaEs7FZ5+WXX37ttdfee++9jIyMiW8dI954441n n332rbfe+sY3vhHpsYTJxYsX8/LyUlJSGhoaIj2WoJEkaefOnQCOHz8e6bFQzOBsbNZZsGDBl19+ +cc//jHSAwlI9vl803gr3tvbO2fOnJtvvjn4I4pWSUlJ8+bN02g0kjTm1+wiSfb5fFP+UtnAwMC5 c+fmz58fihFRvGLGZp2tW7e+8sorRqMxFCvtyq7u0+3dMuBprxKEqkktfj7E0/l2nqBNTEzUCkLV 252Tv2M8HSOdPK1We+LEiStXrmzfvj34JRv+/YHhXySYyp3bj5QK2sTExEQhu/TU2cnGzP8Y6TSG TLNXhD8pSRFy7NixtLS0oK+0K9krgUqvokhOR1OTYwofoJa6CgGTucnpddvrygBD2+Q+yD217wzE nStXrvzVX/3Vpk2brly5EszHlWwAbF5FUZy2xiaHcwp70m23ALDaer3uHmshYLJ6J3GvYH5ngGYZ zsZmqanOyeT+9r152erPjB06fR6Ar7u+qKiqZm+BIAiCsfTUWZ+vs36tuAfY80DpEZfz03d+/akX AFwnq4vUHygrrW72AJC7qwryXqiuKsgWBEEoPXRaBiBfvgDT3kJjsk6/8rvrgRZHr2fCUc3OeZi/ qc/Jrtkdvs69RS8cqa82CoIgGKtPdkLu3rs2B0DO6tIOl/uDd9/pccoAzp46ZBQEQRCyC6o6XDKA zvoXCvZWVxUZBUHILqju9gFAb0c7TNbtq9J1+kWG+/PR4PZONKZ4+qwKRUCkO0qRNOk5WU8ZAFOl raur0ZwPoNbhVt90I9/i6LJVGgCUdLp6GsyFQH5DW5fLVgmYnYrSZjYAYm1bl6PVCsBgtilumwkA YGlsbbQUArA6/N+vO635AMp6JhrTLJ+H+Zv8nCzA7vCqu8PUYO9qshQCsNjP2xvNIkRzQ5vTZTMA lTan22EFUGhp6ulqqzAAqOhVFLvFBMBU2dDWZDWoj+ZH6m0yAGLFBN9n5zyMZogZm+0mUzK3/7rm itMsQqy0ue1moHDwuGFfkwiYbW7JYQYsXkVx282A2e21m4CK1j71nl21+RDNbq/NBJQ19iqKokiO kaukS01lImBq7ZvgKBYbNsqkSjb27hi6cHDnDv/+wPAvErRVijDVDu4VZ6sIWB1uu9mA/Dr1Qlul KFb6ZczrKARQWDv+AvhsGM0cDyrOdpM7ujgA7Py6uq45EtNFDK4IK67KUL+oqp+XCQCyV8KIBeoH D3MNfps1Y9VdsH/SJ8MN3JqhBwBNxohV0j220n12q+P1u1PH+wIsjyVea1JHF8fcHYa1d6QCAJIN jxsAv98fGHTpdyfthvUrB++ZOC8T6LssS4B45xL1Qq1uxMcLz75XcxAlXTU7Aq8JrT4ojyVSMDBj NImSSQA6Lgx9EP5i79Dl9q+Gb+IGhl8f/bmBm+YNXt778QcQb09T/zX085sD/rdOvHlnifnuZfpx RsuGjWUyJRtjd7R0O9Xd4bO91TL42zmAVjt8P82fLUdL39CXNKTLnwNpc9VVxIYuGzWY5KySyu+O 881ENoyChRkjYKKSDa9rLgPnTx3c3YIfGJYDCcCeffWdgOdkdUUL8tfepocE4A99nqHi6TO3GVD8 kvWsD7Kr/adbDoubvzFOo2TP5QXZixPHvgEbNr4JSjbG7kgCdr54uB84f/rorhZs/ubC4d8fGLqn LntDCcqffrvTBXje3ldoR4kha7x3G9p5i7Kz0sa6lg2jYIr0UU2KIuOcJ/Nb1xyFljZp6HPVw8xN vYqieLvq1H99YTdDNLsVReptvbouvqmyy6tcXeReURTFbRFROXRubORJuNF4PmySxjlPFmh32EyA Yej3CQxlDV5Fufr7A33DO8tZWyIO3dNQZ3cqw79aoCij/lb/qX7G51o8H0bBxcWoaITjx4//zd/8 TXNz8+233z7qKtnj6vN4tYkpqck6AJ726qRdCe6PHvedd2kGLwMA2eeTNRrdiNVdff3nnRIS09In ufJ9AJyHTYkkSZs2bbr++uuPHj2q9Ts4CGD07vC1GxP/50+8zbd5+z3QpSYPz7H8fn9giKf/vPMy UjLSp/I7BCNwHkZBx4zRaMeOHSsuLm5qarq2ZP487VVJOXAqz49zDj9Y2LBpGLdkfjynhaQ1rW7l 7vGOEQYHG0ahwHNjNNq2bdvMZnNubu7434xOXHhfXeN945zHChY2bHom+83oxCVNdY1LQ78j2TAK Ec7GKLBJzslCjQ2bocnOyUKMDaPQ4WyMApvknCyk2LCZC+0KwpPDhlFIcTZG44ngnIwNCyJ1TqbV ao8fPx7m31ZmwyjUOBuj8URqTsaGBdfwnGzbtm3h/G1lNozCgBmjCYS/ZGxYKGi12jfffHNgYCBs JWPDKDyYMZpYOEvGhoVOOEvGhlHYMGM0KeEpGRsWauEpGRtG4cSM0WSFumRsWHiEumRsGIUZM0ZT ELqSsWHhFLqSsWEUfswYTU0oSsaGhV8oSsaGUUQwYzRlwS0ZGxYpwS0ZG0aRwozRdASrZGxYZAWr ZGwYRRAzRtM085KxYdFg5iVjwyiyuBgVzcixY8eeeeaZlpaW2267bUp3ZMOiiiRJDz30UEJCwrFj x6a0WhUbRhHH2RjNiDonMxqNZ86cmfy92LBoM705GRtG0YAZo5navn37gQMHJl8yNiw6TbVkbBhF CWaMgmDyJWPDotnkS8aGUfRgxig4JlMyNiz6TaZkbBhFFWaMgmb8krFhsWL8krFhFG2YMQqmsUrG hsUW9ffJBgYGtm/f7l8yNoyiEDNGQXZtydiwWHT99defOHHC5/MNl4wNo+jE741RSBw9erSkpKS5 uflXv/oVGxa7rly5smnTJp1OZ7Vav/vd77JhFIWYMQqVN954Y/PmzVqt9vPPP8/IyIj0cGiaJEnK y8v75S9/uWHDhp///OeRHg7RaMwYhcq5c+e+853vdHV1RXogFASPPfaY2WzW6/WRHgjRaDw3RqEi y3Lofl+Ywuydd97x+XyRHgVRAMwYhcp///d/X3fddZEeBQWHIPDIDUUpZoxChRmLJ8wYRS1mjEKF GZs92muKSo90AoDc/YKxqN2D86cPGQVBELL3vt0JwNVRn5ctCIJQUN3MQ5MUXMwYhQozFk/Gn40t vG3BgZ3veQCf/Rf7WhYs9J3MWLO/xOH09u5vMa040v3l8fwt+pd6FKnr5uLcgx2ecI6c4h4zRqES KGOumoK8I50eAL7u+ryCQx7Ipw+VCoIgZBe83ekC5I76vdmCIAjZ1c1nIzJsCmj8jKV+K8+E4t95 cOYXrxksW9D5ISBe+vTUe//uzAa6v5Tmizi85cXqtz57rKvvByv5cUcKJmaMQiVQxpJv+3pD5dtn AJz5xasNC5f6msvX7Ep0uL29P11pWvFM5yVH8Zbyl3okb9dLxbm72nn4KWpMcG5Ms3J3IU68e7K+ HCUPLnP//hwMN1+55HQ6L2VbrWsXJm/+5762xtzPG/aIy9Je42yMgmoKP/NKNCUBDyreucVqX/Ge 6/mv/6q4xeL4ZWfd08jf+WnLe8BNIuz90tzlwJYXy+t2mrr6GpbqIjJwCmDCj3j8ZZF5fc56GMzO dE3iqlVoObu2+dF09Fdlpw3k/I+jGY886Pxo/7pHH7xZsP6Hs4gTMgoezsYoVAJmTJdlKEF9Y3Nj LUrWZeHCp3bDzbpLTqfTmVBq3fu1xKXmPkdj7ryGPWuWpRW081171JgwY3pxQwmQ/8SGZECXtaOh rC1DEAQhrdZYt2PlbQUWMTdFyBaE3AP5T+cuCtuwaTbgbIxCZYyPeCwqMGfm5O40mNsWQee9y9DS +fXmR9fBdcqYcvCOe7F4yUdO5aV1j+5aKKT9p1NepedTNEbIlz+H4YcPLgUA6Df+uNn7nMurSUzW 6wCsKnrdu/Vlpxcp6amcY1Nw8TWCQmWsTyqKpnwUNzyxIRtA1l+/WrZ6hbrSbEmd447M+ZZ8U4pQ DgD5lr5FfH5Gi/FnY56OmiRxt8ncdrffwUJdcrJ/sXTJqenJIRwhzVp8maBQkWVZownwBPO6LwKV 69UTX7qsH38kPdfv0uiT9ToNgKLXla0vn/dCn57K0ydRZPyM6Vf+tdu5Q5/MXUYRwIxRqAScjXXU FIi7D5vbnH7vyzXJqan+t+G79ig00bkxnT6ZBwspMvgRDwqVgBlb+firbrf0zGp2KsZwMSqKWpyN UagEPjem4W99EFEwcTZGocLFqOIJZ2MUtZgxChVmLJ4wYz8x/wAAABLnSURBVBS1mDEKFWYsnjBj FLWYMQoVZiyeMGMUtZgxChVmjIjCgBmjUGHG4glnYxS1mDEKFWYsnjBjFLWYMQoVZiyeMGMUtZgx ChVmLJ4wYxS1mDEKFWYsnjBjFLWYMQoVZoyIwoAZo1BhxuIJZ2MUtZgxCpWxfm+MYhEzRlGLGaNQ 4WwsnjBjFLWYMQoVZiyeMGMUtZgxChVmjIjCgBmjUGHG4glnYxS1mDEKFWYsnjBjFLWYMQoVZiye MGMUtZgxChVmLJ4wYxS1mDEKFWaMiMKAGaNQYcbiCWdjFLWYMQoVZiyeMGMUtZgxChVmLJ4wYxS1 mDEKFWYsnjBjFLW4cisFmcfjeeWVV6677rrf/va3Fy9elCRp3rx53/ve9yI9LpqOnp6eN998U1GU CxcuHD58+P3331+yZMmmTZsiPS6iq/gOi4LsxRdf/NGPfqTRaARBmDNnjiAIPp/v1KlTd911V6SH RlP2zW9+s729XavVDr9QSJLU19eXmpoa2YERDWPGKMjOnTu3fPlyn883fElqauqFCxcEQYjgqGh6 3n333a1bt7rd7uFL7rnnnvfffz+CQyIahefGKMgWLFhw++23D/9Tp9M9+eSTbFiMuv/++/1PcCYl JT399NMRHA/RtZgxCr6nnnrqxhtvVP9WFOX73/9+ZMdD0zZnzpwnnnji+uuvV/8py/LGjRsjOySi UZgxCr6HH35YkiT17zvvvHPBggWRHQ/NRGFhoTohu+6667Zu3ZqQkBDpERGNwIxR8CUlJd1///0A 9Hp9aWlppIdDM7Js2bLly5cDSExM3L17d6SHQzQaM0YhUVRUpB5XfPDBByM9Fpqp4uLiuXPnJiUl rV69OtJjIRqNGaOQWLdu3aVLlx555BGtVhvpsdBMbd269fLly48//nikB0IUAD9wT6HidDpvuOEG nkqJD19++WVSUtLwZz2IogczRkREMYyLUc0uc+bMics3LoIg/OlPf4r0KMKNe5MIzNhsoyhKvL7w RXoIEcC9SQR+xIOIiGIaM0ZERDGMGaPJ8BwyCnmHOgJf114lCFUuQHZ1n27vlv0uCWj4ZhQpHTV5 grHGE/A6X7tREKrbXZBd7afaXbLfJYFwb1LE8dwYTcoA8LlbCnhVYubGpiboAZx7Y00OvMrzVy8J aOhmfPJFjhsXx7hGl/mTxqa5mXrAnnNPjs2rJF+9JBDuTYo0zsZosuYDkLurCvJeqK4qyBYEQSg9 dFoGZOen7/z6U1dn/VpxD7DngdIjLuen7/z6Uy8A+fyRvQWCIAiCULC3vh/w+d3MA7g6TxYZBUEQ jEXVHS6+pw+3zvoXCvZWVxUZBUHILqju9gGy+4N33+np+3Tv2hwAOatLO1zuD959p8cpA+h8u9oo CIIgZOe9cPq8zL1JUUGh2WS6e9xtMcBgtilumwkAYGlsbbQUArA6vG5bJWDuc/c0mAuB/Ia2Lpet EjA7FcVuFgFTg83haKszAWVNvZLfzaS+JhEwVNTZHa1lBkCs7Av3dsW2aW+13WKAaHErit1iAmCq bGhrshowuIsNQKXtC3ujWYRobmhzutRLnFJXLYCS2taeLps5HzBZPdybFAV4JICmQgsAZY29RevS Iaeadh90X/ZCqwOg0y96YO3tQMLa1UulDh0ADXCrYX+jLWvdqjSPCzki6v/99z82rh6+maPmh3ZU 9L60OR1Ybq3bt3jLb84+u3ERn5NhNOBGfl398xs1wE8q9+/yDe5iHW5ceZ9hPt66a+3qZLQD0AFI WdXQ0GbYuDrR5/qLlQbUuiW/nc69SZHCg4o0NW7g1gw9AGgy1ovw+V3llQAMjDyBdunNXRmCoE1K WVFuR+ZN2pE30wPlGYIgCELi4i0Aei56w7MVpJIA8c4lamq0uvkjrpMlAJLf7tRotP/VUpYkCNrE lNw9LZifoOHepCjAjNHUSYOnPQYmuJ3nZ/mmtg0NvU6vonitBrhH3kEa6IVo7pMkt9vrdfY0NbY+ Io75uRAKlaF3IgE/wOO/sHPnGz/cfWB5a0+fpCi9jSW4OGJ3cm9SpDBjNFljfbTtKgnAH/o8w+f2 ZQCZX1+Qlqzpbj64qwXwSf43W/gNA+yv/avDpdfjw9d35a7/h4n/ExQ2EoCWzs/6r14wAGD+1zJS 5fOn/3b9AcyHD9ybFHk8ck2TlZmkBZABJGgHnzYJw2/lRQDQ3pQOFC9LuvULu3pJ8l2lJcW7crS7 ADG/osRQvqfw9JMfZQ/dzKk811hpWy+m7QQAWG19WXw+hkkS5gODJ8IGDf2tHdzFiTetEbFTvG9p 32H1kuX3PWaAabF2H4CSskLsK76v+q7TG7g3KcK4wv3sIgih3eOyzydrNDrN1Rcwn6vfI2uSU5M1 kD0eb6Jerxl5M5+r3ylDn5yqn8GrXqi3KzqFfqtlnw86nd+OkT39fT5dSqpeB9njkRP1Og33JkUY ny6zS7y+QMTrdo0vXrc6XreLQoTnxoiIKIYxY0REFMOYMSIiimHMGI0wvPa5p6NG8JddUN/RP/59 u9/em1daH3jddIoEX+chQchr9wC+9oIRu3NwPczAPN2H9hYZjca80ur2fi6NSNGOGaNRRqx9bm1z dDkcDkebxWjfIj7b4RvzbvLZ+mWm8oaPLvJlL3pI0gDgVv/2ACW1bV1dDofD0VRbcWDXmvKT5wPd 6fzepGW7WuY//7cvfvvz4py0586Gc8REU8eM0ThMOdlZS7OysrJWF72wFzjc3vyzvOzS04O/POWp L80rPdIJADhbvngLACRd+1VE18nqosEZQHWzB/B11gd6ELn9yN5sQRCE7NKaZg/U1fQLqmqq88b+ sSuaPDeQuTJ76dKsrKws444yqwG/+N2H1QXGqpODnTrfXGUsOvTZqdfKUdjT/ON1dxufr++yVGTJ I9+7nD11aHCR+4KqDpcM+ey1D+IKtNp9Z/0LRVWHqgqEvOr28G46xbtIrUlMETHhHh9e+9xttwBi U69X8nq9XmerpRAw2Fz2fKCwrktRFMXZKgIWu1tRlKYyoKSurTZfva+/NrMBEGvbuhytVqhrqHsD PEhXXSEAc0ObrckCwGSxD6+mX1JptfdJM9yuuDThVrvtFsBgcyuK12YCKlt7Fcnr9Xp7bbUiUNZ0 trEEMFjdiqIobqsBqGiymU2AqbKyRARMhWa7c+QDOqwACi1NPV1tFQYAFb2KdO2DKIFWu1dX00d+ RYNtgrXvZ+fepGnj02V2mWLGRii0tElqsUxWr6L0NBQCZb2K0ttUAeR3KUqX1QTR4vV/OK/dBFS0 Dr5sddXmQzS7AzyI0yzCYLapN7NZTBDNTq/NBJQ09ARlu+LSlDKWP2p3miq7vIrbZgbEVufg+4na Lq/dkg8A+ZUNjXUlIoBCh98ebasUYaodfE/hbBUBq8Md6EFMQEWvoiiK4u2pA9DQI9ktBhhGv8uZ 3nYR+eNyMTSeOnvPt5MgQdbOzUhP1QH49iMWiP/njO/hzv990GCxp/s6C3LLUVYndbe//5sG2DP/ b3vnX4pZg4s4DC6QPvg0y1h1F+ztffK1D3LuQztainOE4qH/sGE91ONgmSnh3uY45QHKGuyl30y6 LAGYm7EoVQNg1YYSFDf+tj/rygk7Ku5fqvvDrzxARe/rz6cDG1c3Nafkvn3mf2WtSlYf43cn7YZt Kwd3Z+K8TKDvsqwP8CDqavflw//1noveBQMQ193J1YIp6JgxGodhyfJF6boRF+lWrivD7tcPWj9q QMmrKwDHXBHiL7as2Kdef2B9zpc29+urhl6u3MBN8wafZr0ffwDxzjTNNQ+iOTsXKKxz/GPeYq8M X89Htv6b9LgMXF1Nn2bIDdyauTg1fVRHlm6vNKyxWud5DpisjlTg9wNuiGmDN9KnZgI3aYdfJbR/ thwtfX8c/Jd0+XMgb64m0IP0QjT32X6g88pa+cK/nf5ipaj//Qdh2lKadSI9HaSwmnCPjzyoaGgL dAzIpp7kMI0+QOS1mwHzyAudFgNgMvd4FclpKwHEitZADyI1FAJiZZdbUdyOMgCFjYrXZgDMtpEn Z6a7XXFpwq32P6g41v9MqasOACA29SmKongdVgCVjQ5J8bZa8gGT3e+gYk9DCSA2OJyK4m4oE4GS nkAP0tdaAYi19j5F8baaDYDJISk2s0GstAVlu4j8cTZGowyufa7+PVcb4BbiusdENGzYvW7UG3sJ g0vd+0l+/HDrBxn3LE4sBgBTZddzdwd6EM3Gn9jL7hKXJe0BALHCYV4HdGQA0PIpOn1abQKQpP6d 5PfTBP40S++tNGBPxp47UwFAl5Vvs36Us37FHgCAualnpd90fNHG8tqSZtMK9Uivoc5evijQg6Te HWC1+47QbCMRl+CcXSK06Kqv/7xTQmJaevK4UZJd/X2yRp+cPOXl0WfnYrKh22rZ43L5ZI0+NVkX 4FpP/3nnZaRkpI+/n6a92v3s3Js0bXy6zC7x+gIRr9s1vnjd6njdLgoRfv2ZiIhiGDNGREQxjOfP KQg8rn6fDJ0+VR/oVAoRUehwNkYT6zxSNGKx+7y9p88PLbTn6dibJySlpKWlpSUlCgVVJ0evcO/r KBCEmg6Pp71KEKpcgOzqPt3eza+DRSvf6frqgjyjMa/oyKnxlgW+unw+UUQxYzQxyXMBKBtcHd3W tBnlazIeaD4vA776H4jl7kp7r9PrdTsazYf3rC841DnyzlIvMCDJiZkbm5o26gGce2NNzhvMWHRq r9m+Zstrdz72YokRO+9ZfKhzzB810ACAWwrf0IgCY8ZoMtwQF92mro6+yvjSWz1laMn9aSsgXeyF mLd+ZXqyTqfPWvdMa2XhbTeOvOvQN89k56fv/PpTV2f9WnEPsOeB0iOeQOugUyT5Oip2N5jtp5/Z aNz4TE2b1XyrVvJ11xeU1tQfKlXnXmeba4yCIGQXPLd/P5AU6IuFRGHFjNE0LNpsNuAXH7ugnb8c 9mIxr3Rv/clT3edddz9f8+PNWQHvI33VeaC8Bxl3lpgLgfyS7asT+5u/s2L9Z4Y6u6N1zWfF4nde nuB3OSnE5Av/0QB89W/VBdlCtrGge8XmdUv10uWLhw/s3rLrc3PtM3p79eLc3RmVDW0/zW0+aI/0 eIkAfsSDpkeboK4Nodv8j32NqyyWV8u3HFCvyW/s+ed1t3g6P/uDBEA7f8Xi4fvoAOj0ix5YezuQ sHb1UkfND+2o6H1pczqw3Fq3b/GW35x9duMiPicjxuu+CKB890lrQ2Num2XnmoxzbX1PzgUgNjnf MiajvfrvYKq1Pr9RA3xgcyflvBXpIRNxNkbT0n+2AZk3J8LX79KsK3rprY8Ur9vpaK0tFA+v3/Uv /3XGukIURVEUVxy+9hMAXgnAgAQA6jrogiAIiYu3AOi56A3zhtC1ah2/fHTjukd//LpFRO37/wkA mD9PA8D3nx+2iMaswTca2oTIjZHoKmaMJuvqWRBPe/U+GNav1Hk+SktLOdItA9Dpk7Pu3vF8qQkX B3SrnnUPeiZ57AeU1HXQJcnt9nqdPU2NrY+I/B2PSNJqEwCkzFe/NqFNmA//3Q7gCmD/6v8N3TjM oyMKjBmjyUiC/eyHHZ0dHR2nT9UX3ZXTgPyf7FgJ/a1lwM7vl58+75FlX3/3qZ/uV2dpGv2gQN8j kwD8oc8jL/yGAfbX/tXh0uvx4eu7ctf/w8VwbxeNoMsylAF79tef9/n6O36+vwWbv7VQvUoCAN1f bilE+dP1nS74zv7Lj3YPrztMFEE8D0ET0ybcAuy7Rxz8STExv6L17edW6QEsKu9purgxd03G4FUw VditO0a2S3t1oXoRALQ3pQPFy5JudSoB1kGniFpU5mhoW2FS96epouHpu1PRgeHfOli08e9qC+/b siIFgJhvAvTgnIwijUtwzi6hWXRVdp3vdUvauUkpgVdEv/YOPp+s0eg0GsxgHXR/s3Mx2VBttezr 73Miccy96eo/L2v0qcmhOgI8O/cmTRufLrNLvL5AxOt2jS9etzpet4tChOfGiIgohjFjREQUw3hK fXZR1/aN9CiCLy43akLcm0TguTEiIoppPKhIREQxjBkjIqIYxowREVEMY8aIiCiGMWNERBTDmDEi IophzBgREcUwZoyIiGIYM0ZERDGMGSMiohjGjBERUQxjxoiIKIYxY0REFMOYMSIiimHMGBERxTBm jIiIYhgzRkREMYwZIyKiGMaMERFRDGPGiIgohjFjREQUw5gxIiKKYcwYERHFMGaMiIhiGDNGREQx jBkjIqIYxowREVEMY8aIiCiGMWNERBTDmDEiIophzBgREcUwZoyIiGIYM0ZERDGMGSMiohjGjBER UQxjxoiIKIYxY0REFMOYMSIiimHMGBERxTBmjIiIYhgzRkREMYwZIyKiGMaMERFRDGPGiIgohjFj REQUw5gxIiKKYcwYERHFMGaMiIhiGDNGREQxjBkjIqIY9v8BQdl+7yb0vNQAAAAASUVORK5CYII= --Apple-Mail=_998752BD-94FC-41BE-93BB-3ED3E3C23C82 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Screen Shot 2012-05-08 at 10.49.50 .png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; name="Screen Shot 2012-05-08 at 10.49.50 .png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAAikAAAH4CAIAAAAAe+peAAAX/GlDQ1BJQ0MgUHJvZmlsZQAAWIWV eQdUFM/Sb8/MBpaw5JxzkpxzziA5KzlnlhxUQECCgoAiAoqCiogKokRJoqAIfwQUVEQliARRMSAo IG/AcO+733fPO6/P6Z7f1lRXV1d1qNoBgO2WZ0RECEwDQGhYNMnGSJfHydmFBz8JEMAICEAASHt6 R0XoWFmZg/9avo0DaOf5WGJH1n/n+18LrY9vlDcAkBWKvXyivENRfAsApMU7ghQNAHZHnkBcdMQO Po5iBhKqIIov7GD/X7hlB3v9woO7PHY2eiieAoCM0tOT5A8A1TJK54n19kflECkBwNGF+QSGoaw8 KNb0DvD0AYDNA+XZExoavoOPoljE69/k+P9fMr3+yvT09P+Lf81lt5DpB0ZFhHgm/H+a4/9dQkNi /ozBhVbKqGBbM/TJhNot3tvTwBbFLCjOC/A1Mf9NvxQRrWvzm94eGG1it2MjFD8JiDG2/40XYoLt dVDMgeLN4HCzHX7UTjBLmNdeSxTToVjAO0rP5ZdMWDExwM7xN4+5j6++AYrRVQQ7kcJt/vAHRMXa /qEnJgbo7f3DH+RpuuNvIopzPEm7c0F1gEt8Q4x2xuVD8dWIaCu732MNhYXs/T0X+I0fydDmN/7h G7U7392xogPsjH/JR2ii0QXwSybC4RdoaPJLB0Q6gGT8h64dEbK7ptG+iB0pxmbHDgIo9vMNs/8t E8nx8dQ3+2UTpBwYAk9AAr7AC4SBLcADzIEe0P/d8qD0MLT1BuEgBK0kHuo/b7BvsSPYGewYdgr7 /C+33h8+EAh80Ocfuve/0W1BIniPSvUFUX9Gw7BhNDFqGHO01UarLEYZo/Ln3dBy8/JfrX7p6o/2 lfhN0f2tfey/a+8emEb6jz5ef3v8T50MwZtdqb85pGulF6U3//T/14xxBjh9nDHOECeKZCE3kfvI HaQfaUeaAQ/ShbQgg0jHDv6PUTx/W4W0O18zdERfELP7K+x/1SjmL8dvKlGMqABsdvmD0XeBf0dw 2NU68H9IiUGrFyopCH1n9neOfywthFpXAaOL0UDtjNoYw4RhAxIYedTiOhgt1AcKKFXvP3v9biWA 364tY3fnEgzeojg02jc+emeh64VHJJAC/QOieXTQ09J3D49JmLfkHh5ZaRlZsHP2/traX2x2z1SI 6dG/aOEyAKjsnJWH/0Xz+ABAcxB63ND9iybUDAC1LAD9p7xjSLG/aJidBgvIATW6+lnRk4MfiKB6 ygJFoAa0gQEwBZbADjgDN9S6ASAU1TgOJINUkAlywXFwEpSCClAFLoNroAE0g3ZwB/SBATAMxsAL MAXmwDuwAr6BDQiC8BAVRA+xQtyQICQOyULKkCZkAJlDNpAz5AH5Q2FQDJQMHYZyoUKoFDoP1UA3 oFboDtQPjUDPoWloEfoM/YARmBJmgDlhIVgKVoZ1YDPYDt4P+8ORcCKcDufBJXAlfBVugu/AA/AY PAW/g1cRgFAgTAgvIoEoI3qIJeKC+CEk5CCSgxQjlch1pA1di4+RKWQZ+Y7BYegxPBgJ1JPGGHuM NyYScxBzFFOKuYxpwtzDPMZMY1YwP7FUWA6sOFYVa4J1wvpj47CZ2GLsJWwjthfdz3PYbzgcjgkn jFNCV7szLgiXhDuKO4Orw3XjRnCzuFU8Hs+KF8dr4C3xnvhofCb+NP4qvgs/ip/Dr5NRkHGTyZIZ krmQhZGlkRWTXSHrJBslmyfbINAQBAmqBEuCDyGBkE+4QGgjPCLMETbIacmFyTXI7ciDyFPJS8iv k/eST5J/oaCg4KNQobCmCKRIoSihqKd4QDFN8Z2SjlKMUo9yH2UMZR5lNWU35XPKL1RUVEJU2lQu VNFUeVQ1VHepXlGtE+mJkkQTog/xELGM2EQcJX6gJlALUutQu1EnUhdT36R+RL1MQ6ARotGj8aQ5 SFNG00rzlGaVlp5WhtaSNpT2KO0V2n7aBTo8nRCdAZ0PXTpdFd1dull6hJ6fXo/em/4w/QX6Xvo5 BhyDMIMJQxBDLsM1hiGGFUY6RnlGB8Z4xjLGDsYpJoRJiMmEKYQpn6mBaZzpBzMnsw6zL3M283Xm UeY1FnYWbRZflhyWOpYxlh+sPKwGrMGsBazNrC/ZMGxibNZscWxn2XrZltkZ2NXYvdlz2BvYJzhg DjEOG44kjiqOQY5VTi5OI84IztOcdzmXuZi4tLmCuE5wdXItctNza3IHcp/g7uJe4mHk0eEJ4Snh ucezwsvBa8wbw3ued4h3g0+Yz54vja+O7yU/Ob8yvx//Cf4e/hUBbgELgWSBWoEJQYKgsmCA4CnB +4JrQsJCjkJHhJqFFoRZhE2EE4VrhSdFqES0RCJFKkWeiOJElUWDRc+IDovBYgpiAWJlYo/EYXFF 8UDxM+Ije7B7VPaE7anc81SCUkJHIlaiVmJakknSXDJNslnyg5SAlItUgdR9qZ/SCtIh0hekX8jQ yZjKpMm0yXyWFZP1li2TfSJHJWcod0iuRe6TvLi8r/xZ+WcK9AoWCkcUehS2FJUUSYrXFReVBJQ8 lMqVniozKFspH1V+oIJV0VU5pNKu8l1VUTVatUH1o5qEWrDaFbUFdWF1X/UL6rMafBqeGuc1pjR5 ND00z2lOafFqeWpVas1o82v7aF/SntcR1QnSuarzQVdal6TbqLump6p3QK9bH9E30s/RHzKgM7A3 KDV4Zchn6G9Ya7hipGCUZNRtjDU2My4wfmrCaeJtUmOyYqpkesD0nhmlma1ZqdmMuZg5ybzNArYw tSiymNwruDdsb7MlsDSxLLJ8aSVsFWl12xpnbWVdZv3WRsYm2ea+Lb2tu+0V2292unb5di/sRexj 7HscqB32OdQ4rDnqOxY6TjlJOR1wGnBmcw50bnHBuzi4XHJZdTVwPek6t09hX+a+8f3C++P397ux uYW4dbhTu3u63/TAejh6XPHY9LT0rPRc9TLxKvda8dbzPuX9zkfb54TPoq+Gb6HvvJ+GX6Hfgr+G f5H/YoBWQHHAcqBeYGngpyDjoIqgtWDL4Org7RDHkLpQslCP0NYwurDgsHvhXOHx4SMR4hGZEVOR qpEnI1dIZqRLUVDU/qiWaAY0yB2MEYnJiJmO1Ywti12Pc4i7GU8bHxY/mCCWkJ0wn2iYeDEJk+Sd 1JPMm5yaPH1A58D5g9BBr4M9h/gPpR+aSzFKuZxKnhqc+k+adFph2tfDjofb0jnTU9JnM4wyajOJ maTMp0fUjlRkYbICs4ay5bJPZ//M8cl5mCudW5y7edT76MNjMsdKjm3n+eUN5Svmnz2OOx52fLxA q+ByIW1hYuFskUVR0wmeEzknvp50P9lfLF9ccYr8VMypqRLzkpbTAqePn94sDSgdK9MtqyvnKM8u Xzvjc2b0rPbZ6xWcFbkVP84Fnnt23uh8U6VQZXEVriq26u0Fhwv3LypfrLnEdin30lZ1WPXUZZvL 92qUamqucFzJr4VrY2oXr+67OnxN/1rLdYnr5+uY6nLrQX1M/dINjxvjDWYNPTeVb16/JXirvJG+ MacJakpoWmkOaJ5qcW4ZaTVt7WlTa2u8LXm7up23vayDsSO/k7wzvXO7K7FrtTuie/mO/53ZHvee F3ed7j65Z31vqNes90GfYd/d+zr3ux5oPGjvV+1vfaj8sHlAcaBpUGGw8R+FfxqHFIeaHik9ahlW GW4bUR/pHNUavfNY/3HfE5MnA2N7x0bG7cefPd33dOqZz7OF5yHPP03ETmy8SJnETua8pHlZ/Irj VeVr0dd1U4pTHdP604MztjMvZr1n372JerM5l/6W6m3xPPd8zYLsQvui4eLwkuvS3LuIdxvLme9p 35d/EPlw66P2x8EVp5W5T6RP25+PfmH9Uv1V/mvPqtXqq2+h3zbWctZZ1y9/V/5+/4fjj/mNuE38 ZsmW6FbbT7Ofk9uh29sRniTP3VAAQSvs5wfA52o0b3EGgH4YAHLir9zod0HQ4ANGn3g0UjBFI4BZ SAy9t7thVjgankBMkLsYI8wTbCiOFteDTybTJOAJL8lbKcop86mqiZM0NLRmdNn0/Yy0TPuYr7Ji 2DzZOzh5uI5yr/P68E0I7BXsF5YSyRN9J26yp0Lim5Se9DGZYTkqeV2FKMVypW7lKZUtNWZ1cQ0V TQMtG21vnSjddL1T+rUGXYaPjRaNt00ZzfaY61m47g20jLXKsC60qbCttWtGd/2A46jTc+fXLrOu C/ve719wm3Qf8ujyrPM6633MJ9HXz8/aXy1AIJAY+C3odXBfSE3osbCIcNsIpUi2yE3Sq6ju6KqY jFi/OJN48QTyhKXEwaT65JID6QfjDkWmkFIT03IOn0/vyHh9hJClnh2RU5U7fow8Tz0/9PjZgqHC rRN7TroW55xqKpkqpShTKHc/k322oeLFeUylRJXDhUMXL18aqV6v4bliXpt8teHapzrV+vwbH2+6 3nrUZNn8pFW9Lfp2TftkJ0WXXLfDnciejLsF94p7i/sK7mc9ONx/5OGxgWODGf9EDzk+kny0Mdw9 kjSqOPrt8dMnrWOl4weeuj/TfS44QZh4/2JksvFl6asDrz2m9KdFZ2hmvs++fTM+1//2zvzthdbF 1qWL7/KWY9+7fTD4KL5Cs7L6aeJz55fzXzNWA76ZrUmt06+vfZ/80b1RuZm+5ftTf5tvexv1Pw6w odFhPOhFIzpz6Dj0GpZDY68viDsyjkZNL7EROCKuGe9LxkY2QSgn96fQpdSgsiMGUKfQnKO9Q7fI wMioz5TAXMfykU2SncTRzkXB7cBzhXebX0cgVbBLaFNESTRI7Iz4wJ7PkoxSctLGMq6y/nKR8gkK BxQTlYKUXVXMVTXUpNX5NBg1yTR/aL3XntYZ032o16l/06DasMQoyzjOJMDU2czYXNlCeC+jJcby q9WM9YhNt2293Vn7LIcoRzcnE2c5F05XnOsH9KTvcKtyz/EI97Tzkvem9J7xafXN9/PzVw+gDXgb eDuoINg3RDWUOnQ2rDk8K8I5UhxdF0NR56JJMXqxjLHzca3xRxPcEqWT4KSnyXUHcg+GHrJP0U9V TVM5rJFunOGUGXbkSNbF7Ls507k/j3HkqeQ7HI8qOF54taj/xNti+BRHieJp69LQstzyq2eGz347 x3feqvJwVeuFT5ckqyMv36pZq1W5mnytsw7U69w43NB7C9to1JTVfL8V32ZwO629o+Nrl1C37Z2k nrN3b98b613sW3uA6ad/yDsgNajxj/mQy6OA4biRzNGTjyuf1I21j/c/HX829/zrC2SS4aXgK+XX 5lP+01Uzi2+E51zeZs5fWbi/OL20vkx8L/hB66PrSsqn4S9yX4tWv6zZrN/6wbKRsbn+M27X/xhA C8TAXpACutG4XhWKhpphGLaAz8EbiBvyEKOOacIqY3twVrhZfBIZO9l9wjFybwp1SnbKn1QzxAHq RpqLtCV0efRZDBmMmUy5zEUsFay1bC3sHRwdnJ1cXdydPLd5G/lq+c8I5ArGCO0T1hbhEwWiL8Sa xXP3OEjwSCxJNkqlSJvJMMlMy9bKxchrKRAUHiueUQpQlldeV+lUzVAzU6dTn9Co1AzSktXa1O7T KdDdryemt6Z/1yDf0NVI2OizcadJjqmDGa/ZO/Mmi5S95pZMltNWtdZRNmq2sO1Du0J7Fwceh3nH 604xzmousEu/a/4+2/1M+5+7lbnv9+D0eOl5xmu/N4f3hE+Jr4Mfvd8j/9wAg0CArpfYYJng5ZDq UK8wjrCn4UUReyPJIu+QEqPkopajL8a4xTLHPoo7Eq8Vv55QnxiYxJP0PPnEAbuDrAfnDrWknEhN SPM7vC/dOcM10/dITFZGdnHOpdymo33HxvLm8r8WIIX0RXwnpE+qFuudMi2xPu1c6lUWXn7oTNHZ qxUD5z5WClYlXBi+JFx98PL4FYna9KsvrsvUZdW/alC8mXvrdZNc85GWyTa52zntM53qXSXd33rs 7jb2CvddeCDR3zsQ/I/A0PLw/dEbT2rG65/dmXj5EryWnq5+kzmfs9T8gfpT1irLeuOm447/f/1H tlNwigBcnAXA4TwA1q4AVIsDIFgGAJEBACsqAOxUAKybD6DnpwFkdP3v/UEFhIEhmg0fQTPHfvAO IkIykD2UCJ2B2qEX0Caa32nBXnAmfAV+BH9F2BEdJAA5jrQiMxgKNMP2QDOyFswbLB1WCxuGPY8d w5HjdHDxuAbcMl4E74+vxi+SSZLFkHURKAguhKvkELkTeQMFkSKMYpRSmfIcFRkVieoV0ZTYSi1C XUpDRZNKs0YbjuYr3nSv6b3o5xlCGb4xpjIRmc4wSzHfZXFlWWUtYJNhe8wex8HJMcx5hEuXG3Df 4cngteBj5Vvgvy1QIBgkZCgsKEIpsio6IzYqfm9Pm8RNyXqpOukGmRbZbrkB+VcKn5Qwyowq/KoS ajLq0hpimjxadNqw9kedF7pdepX6WQbhhk5GusZSJlym1GaI2br5isXS3jnLGatp6zc272y/2G05 EByZnYSdVVwsXL33Je0/6VaP3mPvvYjecj7Ovof8qvx7A2YDt4LpQnhDxcIkwyUiRCP5SExRhKgf 0YuxbHEW8ekJXYk/kw0OFB18l2KRevuwfHprpsmR2ewjubxHr+dp508VFBQ5ndQ4ZXI6rqz3LPs5 YiVc9f3i5+oPNcu1y9c+1q3e2LpF1sTeItWm3+7cGdgd23PwXkrfgQexD0MGPYZyh1tGl8Z4n+5/ XvHi7SuZqdSZsTnx+azF+WWjD1c+0XxJWn2/7vdjfiti9/ygBpLAGsSAUtAF3kAUkCzkCqWjGf8A 9BHN7lVhDzgLroefIwiaszsjGcgN5DWGCj1VgjFlmH/Q/FsG64MtR/1OjTPHZeMe4MnxFvhC/ASZ IBmJrIfARAgh9JHzk6eRz1GYUrRRilNWUDFSHSXiiGnUgDqVBqHJoiXSnqLjo6uj16YfYwhlxDFW MukwzTBnskiwjLOmskmzTbEXcRhzYjh7uA5zG/JQ8ozzVvJF8RsKcAmsC44LNQufEzklWiCWJ563 p1CiVPKSVKP0A5lXsmvyjAqqit5KecodKh/VBNXdNco0X2hz6fjo1ultGBgY5hoNmGBNlcy8zDMt Lu29YzlhtWKDsWWyE7PXdnB2jHLKd77uMuT6aT+Tm4a7n0eBZ6fXBx9+Xye/fP++gK0g+eDAkLOh I+FwhGykBykv6nb0Qix1nFK8R0JuYkvS/AHmgyaHDqQ0pC4d5k/fn1Ga+SyLOds552zum2MSefH5 fQUsheFFgyeli8tKiKezyyjLT54Vrrh/PrCK8kLDJZfLmJr6WvdrNNfv1sc3SN1caKxuDmyVaPvc 3taZ1m3ew3x3trf+fnK/6QDr4PCQ/aPZkcTHXE+GxnOf2U4ITUIvZ173TdfO5s+R5m0X2ZcqloXf 3/iouTL02f3Lx9WUNer10z+4Niq22H7m7/qfGeiACFABHoFt1Pd+0GmoF/oC88E2cDrcDC8jvIgT ut/7MQhGE5OIacasYhWwsdgOHBZniSvDLeHV8MfxC2T6ZBcIZIQIwiS5OXk3hRLqaV3KQSpnqiXi QWpG6noaS5pPtMV0mnSL9GcYbBmpGB8yZTObs9CxTLBeZCOx63DQc7zj7OO6wJ3JE8xrx6fDLysg LMgtxC7MJsIjKi6mIm62x1MiWbJUqkP6jSxRTl2epHBd8aOygkqq6qi6iEa65lttc51mPXH9C4a8 RlUmoqaN5voWzywjrClt6u1c0f3a4RzrKr9v3a3b45iXm4+iH6X/88DSYJOQxbCE8M3IaNJctFXM zTjaeFLCkyTV5PMHKQ7Fp8ynOR0ezNDNbMuSz27K1Tjan+ec/67gYBHticpiqVOtpzVLu8rVzzRV YM+Znz9Z+fqC2MW4S72XGWv8rrRdJV7zud5ez3gjomHglgia+bxvsW5tvs3Vntnxocux+06P+N2T 97b7gu4/6dd+WDvI9E/U0MNh9pGA0auPl8b4xx2fpj27/PzhxNyLzZc0r7hfi08pTKvOaM5qv9Ge 03yrOq+0ILMotsT3jvhucbn1fdwHhQ/LHy+uOH8i/9T+2e8LzZeWr/tWwWrlN91vM2uH1jnWW7/b f1/5cXRDeKNn021zfavop9TP/m2fHf9H+cnJ7l4fEKUuANhX29tfhNCkohCArYLt7Y3K7e2tKjTZ mASgO+TXd5fdu4YGgPKq//b94/8AmJfCLqRoihwAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURB VHic7N17fBNV+j/wJ7Sl6SWFXilULMjFcukUqQgLiE7r8gJ1SUEQ1LArIgHxQtAVjK64lv3KhnVX ws9LQDTs2uKlLEtUrK6kxQJrQFIhdUktQQJrQFJJYVKY1El7fn9MW9pSek0yk/R5/wXpXJ5JO/nk nDlzRkIIAYQQQiiA+gldAEIIoT4HswchhFCgYfYghBAKNMwehBBCgYbZgxBCKNAwexBCCAUaZg9C CKFAw+xBCCEUaJg9CCGEAg2zByGEUKBh9iCEEAo0zB6EEEKBhtmDEEIo0DB7EEIIBRpmD0IIoUDD 7EEIIRRomD0IIYQCDbMHIYRQoGH2IIQQCjTMHoQQQoGG2YMQQijQgix7rFbrRx99lJGRIRGf/v37 Z2dnP/fcc3a7Xej3CSGERC1osud///vf3XffPWvWrPfff3/37t1EfH755ZdNmzZFRERMmjSpqKhI 6DcMIYTES0IIEbqGzplMpjvuuOPFF1/8wx/+IHQtnSsvL8/Ozl63bt3LL78sdC0IISRG4UIX0DmT yfSrX/1q//7906dPF7qWLpk4ceLPP/88ZcqUG2+8cenSpUKXgxBCoiP27Dl58uTcuXNLS0uDJXh4 iYmJpaWlt9122+jRo2+//Xahy0EIIXERe5/b/fffP378+HXr1gldSE+89957b7zxxtdffy2RSISu BSGERETUYw2++uqrQ4cOrVmzRuhCekihUDQ0NOzYsUPoQhBCSFzE2+4hhGRnZ+fn5997771C19Jz ZrN57ty5P/zwQ3i42Ls3EUIoYMTb7ikvL6+pqbnnnnuELqRXsrOzU1NTv/zyS6ELQQghERFv9mzd unXZsmUhcKVk2bJlb7/9ttBVIISQiIi0z+3KlStpaWnff/99SkqK0LX0Fn8sVVVVycnJQteCEEKi INJ2z759+2655ZYQCB4AiI6Ozs3N/eKLL4QuBCGExEKk2WM0GnNzc4Wuwmdyc3ONRqPQVSCEkFiI NHtKSkpycnKErsJncnJySkpKhK4CIYTEQozZc+HChdOnT0+ePFnoQnzm5ptvBoCTJ08KXQhCCImC GLPHarVmZGT06yfG2nps/Pjxx48fF7oKhBASBTF+vldVVY0ePVroKnxs9OjRVVVVQleBEEKiIMbs +f777/lOqlCC2YMQQs3EmD02m80n2VOxfXmrB4vmra+o8XZjfW9N+f7ybq3RgYyMjBMnTvhmWwgh FOTEmD3nzp1LTU31wYbqzgOozXa7zWazmotVp9ZR9xW4u7H+qewZ2ad8lD2pqannzp3zzbYQQijI iTF7amtrY2NjfbElBujRVHr6iBEjMibOWr6ShlLGCwBQ8/nmxibR6s0lfBp5q8vX52Xx7aPth86C 9+T6mdkAkD15dUV38up6ZDKZ2+2LDSGEUPAT4+TKbrdbJpP5YktxUPr17pIRCcDVnjn44opShV4b D3Bo832zV10oNNkm/rJ/zIzcY2AueSpxXUr2BrnGbNvl3PPH2VPS+lvP5q3R7ix9Z+n6RTdE+aCU 2NjY2tpaH2wIIYSCnxizx3ftHhnA1gWrTRSAxWIBgOH/O+X2wIZVpfllzgcnJwOMsBUaR2oOnKMj NwBlem/NRBnAU5u17xRoPj537Gk6EXZPnzk53hdvEmYPQgg1E2n2+Kjd4wBKxxxbzm/r7KEtaVPk pfcdBoDmA0+bOB0s5dX14wAeGt24z6ghFIAUwMsBAMcBSH1QSnh4eHh4uMfjkUp9sTmEEApmYrze Exsb68NLIxFN/xiSNYEGsLsuMwADBjZmj+O7A0CNS24AgIrzTcMKLjharB4BPuH1er1eLwYPQgiB OLPHd5fl48BS+U1FZUVFRUV5yfq7p5SCnL41ayENq17Un/aAt6b89QUF1PxbBg8dT0HBlo/KvQBn 929dUQor6VHAAUBp5YlqX1Tiw45EhBAKemLsc/PZpZFIGcCmGdSmxv/SKqM9P1MqG1NQdiBtxrCo VQAAco3t2dtBCrsM+SPl2ZseAgBQ6kxLM2XgHTCFgoeou0Ywxyb3ugvQdwMoEEIo6Inx2XFTp059 9dVXp06d6s+deKrPujiIShlydSSB113jdLMRUQnJ8c09Y16PB6RSHyS01WqdN2+e1Wrt/aYQQijY ibHdM3jw4J9++snPO5EmDxnS5qVwWfwQWXyb13x1geann34aPHiwb7aFEEJBTozXe0aOHPn9998L XYWPVVZWjho1SugqEEJIFMSYPTfffHPoZU9ITs6NEEI9I8bsCckpnzF7EEKomRizZ+zYsZWVlQ0N DUIX4kvffffd2LFjha4CIYREQYzZk5CQcOONNx4+fFjoQnyG70IcMWKE0IUghJAoiDF7ACAnJ6ek pEToKnzGaDTm5uYKXQVCCImFSLMnNzfXaDQKXYXPlJSU5OTkCF0FQgiJhRjvLQWAy5cvDx06tKqq KikpSehaeuvKlStpaWlVVVXJyclC14IQQqIg0nZPTEzMvHnz3nnnHaEL8YHCwkKapjF4EEKomUiz BwAeffTRbdu2CV2FD7z99tvLli0TugqEEBIR8WbPbbfdFhkZuXfvXqEL6RWz2Xz+/Pm77rpL6EIQ QkhExJs9/fr127hx4xNPPOH1ejtfWpQIIY899tgrr7wS4aunACGEUEgQb/YAwN13352env7WW28J XUgPFRQU9OvX78EHHxS6EIQQEheRjnNr9u23386ePXv//v1BNxHnjz/+eNttt3344Ye333670LUg hJC4iLrdAwC33HLL66+/npub++OPPwpdSzdcuHBh6NCh69evx+BBCKFriT17AGD+/PkqlWro0KH7 9u0TupYuOXbs2NixY1944YWlS5cKXQtCCImR2Pvcmn355ZcKhWLJkiUzZ86kaVoikQhdUTv279// xRdfbNmy5W9/+9vixYuFLgchhEQqaLIHAM6dO6fVavft21deXs5xnNDltBUREZGZmTlz5szly5cP GzZM6HIQQki8gil7/CEqKqqmpkbqqydjI4QQ6oIguN6DEEIoxGD2IIQQCjTMHoQQQoGG2YMQQijQ MHsQQggFGmYPQgihQMPsQQi1Ul9fP2/ePIlEkpOTU1dXJ3Q5KDRh9iCErqqvr1+0aFFdXR3LssnJ yXl5eRg/yB8wexBCjfjguXLlyq5du6RS6Y4dO+Li4jB+kD9g9iCEAFoHT2RkJACEhYVh/CA/wexB CLUTPDyMH+QnmD0I9XXXCx4exg/yB8wehPq0joOHh/GDfA6zB6G+qyvBw+PjRyaTzZ07F+MH9R5m D0J9VNeDhxcWFvb+++/HxsZi/KDew+xBqC/qbvDwMH6Qr2D2INTn9Cx4eBg/yCcwexDqW3oTPDyM H9R7mD0I9SG9Dx4exg/qJcwehPoKXwUPr4/Hz9mzZ//0pz8tWLBAJpNJxKd///5jx45dunTpkSNH hH6r2ofZg1Cf4Nvg4fXZ+Hn77bezsrIuXrw4d+7cn376iYjPL7/8UlhYmJ2dPW3atBUrVhBChH7P 2pKIsKZAioqKqqmpkUqlQheCkB/5I3habvyBBx6ora3917/+5fONi9Cjjz76xRdfFBcXjx8/Xuha Oud0OufMmZOcnLx79+6wsDChy7kK2z0IhTi/Bg/0sdbPK6+8UlBQcPz48aAIHgBISUk5cOBAXV3d U089JXQtrWD2IBTK/B08vD4SP7t37962bZvT6ZTJZELX0g3h4eGffvrp4cOHt2zZInQtV2GfG/a5 oZAVmOBpubsQ7nzzer3jx49/9dVX7733XqFr6YlDhw7NmzevqqoqJiZG6FoAsN2DUKgKcPBAqLd+ Xn/99WHDhgVp8ADA5MmTc3JyNmzYIHQhjfpouyczM/PUqVNhYWEMw8TFxQFAQkLCd999J5JvBAj1 UuCDp+WuQ6/14/F40tPTDx48OHLkSKFr6Tmn0zlmzJiTJ08OHDhQ6Fr6arvnhhtuuHLlCsMwAMAw DMMwsbGxGDwoNAgYPBCirZ9PPvlk3LhxQR08AJCSkkLT9Icffih0IQB9Nnueeuqp2NjY5v/KZLLn nntOwHoQ8hVhg4cXevHz9ttvL1u2TOgqfGDZsmVvv/220FUA9Nk+t/r6+sTExEuXLvH/jYqKunDh QlRUlLBVIdRLYggecRbTG2fOnJk0aZLD4QgPD/f5xj1uj1Tmo7FOXo8bpLLOahw5cuSuXbsoivLN Tnuqj7Z7wsLClixZEhERAQD9+vWbN28eBg8KdmL7rA8LC/vggw+io6PnzZsX1K2fkpISmqavFzwV 25dLJJLNh6qbXnBvz5PkbanoypZrDm2MittaA1CxJU+Ss8UN4K7Y0mpunKzFOyuqO97IyY/X563e 6QbwOj6Ni1h9urOd/vrXvzYajV0pz6/6aPYAgFKp5P+YoqOjV65cKXQ5CPWK2IKHFxrxYzQac3Nz r/vjuisAsGrKKye9TS8wcKqO68KGT+dPWas1L4kHAGDgwtUf6E1Wm9VqtZp0OZYF1NMVnutuwnt6 50j5OsOxC16A8PT5xapNczaXd7zX3NxczB4hjRkzJj09HQBkMtnUqVOFLgehnhNn8PBCIH46yZ5G m5b97VDzfxIBAMBbXb4+L0sikUgkedsPnW2zwsmdf9hEaRdPvPY2VXl2VsaIjIyMjMnLn18PUFBe 8n5e1upDNfxP3TtX563eUQkAAKfXDVsAABAHfKPsLlWRZVV++fWzCgBomi4rK6uvr+/siPyr72YP ADzxxBPR0dErVqwQuhCEek7MwcML6vix2WxRUVE33XTT9RdxgLzQatKWrp2ys7ntAwBwel1K9jp4 yGyzFWtlS6ak7ah0t/ip51BBAbV0enw7GzxV7fJ4PR6Pp2b/rj0AdObU8TLLpneNJwEAao6u32TI yEwDgJLnh21QFZkKFXCqcc3w9KlqMOw9XtPBESUmJo4ePbq8vJPmkb/16exZvHjxlStXlEql0IUg 1EPiDx5eF+LHvXP14tXPL5dIJJK8jSc9AOD+fONiiUQikSz+uLKjD1O/OnHiROdDq0+5h01eWaiA BfPedEME/2twV3y+ASjTe2smjhgx66nNWgo0H59osQ7nPgVUUnR7m7PkpkVFREVFRSXMWLFVqdtA DcxcooatBfs9AKf3F1hA/ZtM2dmS9bkbFLbX5if94gaAiMZ1ZaNp+PzAqfY2e9XIkSNPnDjR8TL+ 1qezJy4ujhCSmpoqdCEI9USwBA+v0/i5UFKwif21w2XTnFr7zn+qT+9cOXvtaBvD2opHy8c8Vem9 do1AqKqqGj16dKeLcRD+4N+MlGXVho+P9U/jr93UATw0urFHLWoIBdB6OFsdwKTMtHa3VmSxO+x2 u93mcLJblk8OB5j6gA4M/zjucR98dyute2CIp3Jt7jpQy7mT5Xu/NoClcl95pdvbuNlOjR49uqqq qgsL+pHvhwz2Xr9+/UJy5LdEImloaBC6ChQifBI8nppqF8sBRCQMSe7iOF+vx+OFcKm0Jx8dfPws WrRo3rx515TtrUukjfnzh8hgzkp6zMHv0ncWaMzMCJkUZqm0VNxXtrczMgSYd7GqqiojI6NLiybn fKhXjJFPAQD5dAAOACrOeyE+HADgggNgUqvFIwHKv3dC5rXXe+ibRqUPaX2s0sxZaljx3lb9MQOo 3hwDYI2mgNqzYEzjFDmbZmf/bGbea+fiUXtGjx792WefdWlRvxFju0fABy75m9BvLQoRPgge79nt q3OiElLS0tLS0lKiJHk7K/h+Lff2nBZDhN0Vz2dJJJLl5TUA3tNbFmdFREVFRUXkPL/jbI8aIh22 fuL4jqMrdUBFRkAiSBs7krweoBKjhPmiXFVVNXbs2C4unPGwJp+/baYOZEPHU1Cw5aNyL8DZ/VtX lMJKelSLZSNkw8F09lK72+HaGSWXPl8n37RqValcRw8JB2nmlmPk2DFCCGEtWgAtQ/jg8daVwqzp wzuuc8yYMYK3e8SYPQihDviixVO9ZWbakk1QWGZ1MYzLYdEpTy2gErZXuAGgDpqGCLsrVsdRGywK k3PLxHjv5+uGrSi4x+JiXTZj3IaH/rK30ztJ2te1oQfRU/PoVe9/AwCek8VrLYk3DfJL9ly6dOmR Rx7p4ML7pUuXOnliQmRc47A2AIAhz35YCACyyAhIztllyN/0UHaERJI2Y5VSZ1raqokjnXy/wlJS 2TQkreVG4qIj4FrUrEcoAPWKWW2q4QCg+T7R6m9XAdwwoJO7FePi4prvrBeM0C2Bdoizqt4L1eNC PpSVlUVR1IcffujxeNpdwOv1zp8//+67777eAl3hLNMAQKGNbfmalgZQFLKE0dFA66yEtSgBAFQW hl+ALVRAvtHJ/1tPA2hMPS6AtHMgLi0tL2MIIcSipWmtmTDm5lFA6iJrb/bVgR07dsTExMTExNx0 002bNm26cOFCmwUyMjKOHz/e4+1zjMvhcDhdbDs/Y8w0QJGd6/HGr2XR0qAwdLrFc+fODRo0yIf7 7QExfhqG6md0qB4X8qGkpCQAiIuLi46OXrJkyeHDh1v+1CfBQwgxa2mgtK7WL1p0cqC0LsLoaACF WkkDgMLMtLO6tUgNAHqLq52fdUcXDod1Op0uxpefzm0UFBQ0N2uio6MjIyPvvvvu4uLi+vp6foEb brjhzJkzftq7rVAO8qL2cqlHGBMFYHB0/na53e6YmBhf7bZnxDjWAKE+SyKRAAA/w/o//vGPjz76 KCEhYeXKlUuXLk1OTl60aBEA9H5UW3RcGkBkOye/5SfGC5FxAAUbtgIAFLz3xQsT57e60l5zaPOY BRvUBtvDme3dmtIdzUMPpk2bduzYsX5NJBJJvxY6/m8vlz979mzzCKArV64AQHFxcVlZWW1t7Xff fTdu3Lja2tqW8w771ogH9abUU1zbEXA95PVEv2ay5wzp/FM9JibmypUrhBD+700QmD0I9YqvhmX2 69evoaGh5SN06+vrL1++fPny5T/96U9qtZoQ0q9fPz6WeukK4wDLJQ9AyysHXB0DVGpCONQBAK1x lDxd+Xx27oKFtN08J735g8L9kXIV5BtfmTOi92U0GzRoUE1NTURERENDQ0NDAyGkoYWO/9vL5ffu 3dvmqntMTAzHcb/+9a/5h9x4vV5/jl+Pn5zT2whvFp6cmZPcpSUlEkn//v29Xi8/p6UwhGpwdUCc VfVeqB5XH+fbX2ty8tUPj7CwsJiYmKFDh/75z3+urq4mhHi93vvvv3/WrFm97HPjr/foLC071Oxq ACq/jDRe77EQQghrVQIApXFcXYwtzlcb7L7pJfJVF2JvvPvuu/yDu6RSqVQqnThx4rvvvsswV9+Z 1NTUs2fPClWen7AsGxkZKWwNOM4NIRHh+39kMllMTMzvfve70tLSM2fOrF27lr8OFBYWtmPHjri4 uLy8vN5MTpN8+xINBSuo6dv3V7o9npqz5Rtzhm0A+vUVt/MLXODHuUkz/mzWgWXtys1XZypLyRoN F9ztbrZbRHJj7MCBAy9fvjxkyBC1Wv3999+bzeYlS5a0HNgWGxtbW1sb+MLKN2ZJ1h/qfLkecbvd nQzeCwBho69d4qyq90L1uPo43/5aJ0yYMHXq1I8++qiDpoBvWj+sTats8QQXSmlsbM0wOhrkfLuH EEJImUYOAEW2pp9SQGnNPd8vIUQcLZ5mR48e7eCnt9xyi9nc2+PtAae1rMzi9NPGf/jhh2HDhvlp 410kxk/DLp7MrMvpcDicrvYG4nRldYb14+iZ9mD2hCRBfq2+6nxjnA673W53OAN5LogqeDp1++23 79+/v3vrcE6DpnF8uEpfxoe2y1qspAEAaKXW4uIIIdYitVKj1yjg3uc3yimVqXHYIFOkkqsKrTaD Jr/ISgjhnCa1nAIAoBRFZgchhLB2vUrOv1JoclyniI58991348eP78GKPhScfW7e0823ZKckxEny NlbUdOse65rty7Oi4qLerDi5PUuyvlywaQoR6hlfdb7Jkoekp6enD0kO2KAjkXS1dd2wYcNsNlu3 Vqkue02+9nyxxWYxajctmZG/vwaqS+4cM/sEXWSxlk05sYq682/VANyF41vXLlkL+cvunXztNNWX 7IXrfrgEcHpdypQN8JDZZtFPKViQ/ZeT3potdw9bUjLcaLEYHoKHpqTtPN3tGSZOnDgxfHgncx/4 nbDR167OqnJqaQBQGMx2hmWdtjI1BUBpu9E65Sw0QL7RQQhnLTNaXQH6zifOdxv1koC/Vl+1fgIm uFo8vPXr1/ODDLvOqlcAKIotDo5wDovJYndZdHKAfL6FwtqLAMBg5yw6Gmgd329jVAPI9SwhdoMS QO0gxKylKY2ZsegAoOmOXotakf/NUT1c7QJ15EOrDtIu0mg0zzzzTHfX8q3ga/fUlL+/qhSKbPo5 E9NlUmnyiNvzPzbQcOonNwDUfL55Of+o2dWbS9wA4D25cXHe85s3Ls6SSCSS1dsPecG989lVpQDr Vq/9/HTN2a/3Vrm8AHC6ZEueRCLJytu4ef3y5ZtPe6Fyx+rVOxpntarcsXr1jkrwnty4ePHGLZvz JJLN5TXgOb19dR7/XNsd1zwYCiF/41s/Mpls7ty54n8uTtC1eHg9mPI54741+fKC2VRahCRC8foh LloGIANYlyaRSCSSqGELAMB+geXqgJo1ib/i33aa6qsbqwNQZ/CDH6WZr7z34vh+AAALRkZJJBKJ JG0dAHTpGamtdHFybv8SNvra1XFV7d6SzTNpaQCq0GSzlukBgJ+WQw4AALrismKdEgD0VtZm1AJQ WkOZk3XpKNCYXIxFDwAKXbHZqAcAALmJIWYt1TxrSOO/m7am0ugtTqeOBqBURovFoFFAF+bGEOe7 jXpJ8F+r1+tdsGDB7NmzxdyYCMYWD+/bb7+dMGFCt1Zh7Fabk+UYp6WsSAlAacz8p5aT4xiGZV12 Y3GZk2ts2TStZFcDqLRaumligsZ2j1kLILfwHy2sTZevO/YfLQBldLAcw7AsYykrNtu7fc37jjvu KC0t7e5aviXGT8OOT2aLjgbQtJM9rEUOkF/W2PdmK1QApWVYsxxAXewghBDOKgfQml2Es9BAm1lC CKOlQGN2mTUUKIv436/LpAGgzUyrvwwL/2/WLAdQGeyEENba7Zav4B9SyB/E8GsVefwEb/AQQurq 6mJjYy9evNj1VUz5AJTWwRFCXIUKoDRmZ1k+AFVocRLClmlpALm1bfYQs04OACBv7IVr/KmrjAJQ FZpZwpRpaQClrcYsB5Bry1hCnGY9AGhM3ZvcqAdH5A/B1+cGkXEA0Orimvf0js1bKqr5CWEbL5qm TZwOlv86vcAApKbJAADC02ZT4AEALwetZimv/abQQo27iV8zPHrAtfus/qmU/wcDMHx4AgA/eWxv W74I+URYWNj7778fGxsrws63IO1qa9a/f/+pU6fu27ev66tkLzXKLavSIiQSScJDBYrXFo5Nvv3Z Ys3wh6gUiSRqxqpSvfntjHBoM6NAm2mqG38af/vHxZpND2VHSeJmrCrVGp8fMXDi2yadYdWMKIkk JXuJXGN8enL3Zkb4+uuvx44dO2BAOx90gRR8c+qMmpIHsGRXxWPLmyYkP7t3y0Or9pjm6hmAAQMb j8jx3QGgJqXw/+Mao+o6J6U0PQcsl5qSg2uxVOPzQ9wn9kDi0qYXOS8AcBwDQBkdh2bIOG8EnPjm IHdjy4dzIBRQfPw88MADc+fO/de//iWST/lgDx5ebm6u0WiUy+VdXD58SM5uwp49fZ6LiB7U9FC+ WWt2s8uqXV6QxSfLwgEAMp8qOdZyrfQ5x1pMztT80/RZawj7WLXbK4uP55/Ylzx5OWEfPOvyRMni 42Xd/gw3Go25ubndXcvngq/dI824R0vDCkq+49BJt8d9cv+WtNkbQLk+e+jwhTSselF/2gPemvLX FxRQ82/p2p274WOmKWGdcmdFtaf60O+zVwHE8UFkeWf3Sbf3dMlbKywQ13od2ajpcrBs3vmNVyZz H/8nNWP23p8EeqgvQgAgvtZPaAQPANx5553davcAAIB0SHp6euunwUrjk4ckJ3c/LACksuTk+FaP ipXKhgxJ7kHwAMC+ffvuvPPOHqzoY8J2+bWr86oYq0Zx9ZZseX4Rf5GHc5Qprr6qsbGEsBbF1Xmr GB0FGrOLsGYaaBPT+IrWzBDCFGsaV6UpAFDbOMLYDHTjtmgFBXKtmd+atmkWLKdJ12Jvxk5Haovz 3Ua9JLZfq0iu/QT1NZ5rjRw58uuvvxa6Ch+orKwcNGgQxwX4xvp2SIj4HuQskXSpKndNtZvlIqIS kuNbfrfwVJ91cRCVMiS+618Jqis+//JUyrw5E6UA1fufT5mRypCnZADgdVfXXG3qtsPj7nrL93rH Zbfb33nnnT/96U8mk2ny5MldrhqJQhf/XAOpvr7+gQceqK2tFarzLWRaPM3+8pe/WK3Wd999V+hC euuZZ56JjIx85ZVXhC5EZF/ZeIGvymXWAIBcrSvUqQBAWdjte7W6os1x1dbWbt++feLEiVKpNDIy Mjw8fNOmTf7YL/IrcZ5EArZ+QqzFw3M6nQMGDLh06ZLQhfSKx+NJSkr64YcfhC6EkKAc5+YH8RPX OCzG2QOd31RGFZbZtzyY6b991dfXf/XVV4sWLUpKSnriiSfKy8s9Hk9dXV1YWJj/dor6GqGu/YRe i4eXnJw8d+7cP//5z0IX0itarXb69OnCz6YDAACi6y4AUXZi+AR/XD/++OPQoUPDwsLq6+tb/jQy MrKuro5/gJhQFfpP8+9UIpGE2AGK+c81wJ1voRo8vPPnz48bN+7rr78eNSooR7SePXs2MzPzyJEj IskebPcE2uDBg/ft2zd//nypVNrmWbybNm1qfkp8iOEfFskT6p33EwGfOtypQLZ+Qjt4AGDQoEGr V69++umnhS6kh9auXfvII4+IJHgg9LLHW3PyUPlJL4C7fKNEsrEHM1R7Yjc+0AAAIABJREFUKrdL JHnlbgBP+WJJK6u3H7ruMGr3ye3rl+fk5OSt3lxe3dFg67CwsDvuuOODDz74+eef33jjjezsbP56 T/crRaIg8jQNTPyEfPDw1q5dy3HcsmXLhC6k25YtW3bq1Kn169cLXUgLwn0Vvq7eVMVZNAAalhDO ZTUarT0YSMhYdPycOo0z6BSabDar1Wo1FuZD8/Q8bTnyAYBWF5cZNXIAUNnbW+h6x2W321988UUA MJlM3a83yIjzT643guKI/Dr0ICQHF1xPbW3trbfeumTJkitXrghdS5fU1dU9/vjjACC2gRJiPG3a OZk5m0YhV2sb7+pR6U18qFgNWv4WHEquNjk41lrE/5dWFTptBlW+wWktuvahTIRw5sJ8/mFMKp2x zTx8LbOHBtBamh9Nz+lpoDbs1ipoTXFjuDiMGlqpryrLB1Dam0rV5ets7T3PPig+pPwt9N6EYDki P8VPnwoeXl1d3ZgxYwBg9+7dgs+K1oFLly7t2bMnIyNjzpw5brdb6HLaEuNp087J3N501JytEABU hWV2m1mrAJDr3YzdoFUCKAwmW41ZA6B1sRYFgLLIRgjhZ+XTWRhbkRIAtAaT2aiDa+YAbdPu0ZQ5 CMeyLOswF1IAauPpYhUArWcIIYTR0wD5RrNWDiDXaFQUgFyptVxnZr9g+ZDyq9B7E4LoiHweP30w eJp98cUXubm58fHx4hyhGhYWFh8ff+edd+7atUvot6p9Yjxt4NqTub3pqDmX1WAwMYRwrMuoaXyw AmfVAuhYQhiLFkDLtPNQJpeWArrpgfNmnbzNExlaZo+ize9TrrGxhDFrAagyV2OYFdpYi04BAKDQ GIqLVBQAKK3Y7rmO0HsTguuIfJgWfTl4UO8FzViDa6ejDg+POFeqjpNIIqIScteWQmJkOADLQZsJ pds+lMnz4zcWKF2VzQ8fyF5hgMTrXhp1A6gNFv6R9na7k9u9ZoQUZBPvUYGl+Nvq6kO7LJD/6xFS ADdAvuO9NXNmzX9tn5GCrR8fx+dwIzEKCwv74IMPoqOj582b15uhB31kcAHyn6DJHoC201FX/vOZ FZtGldmdHCGOYhVcaP9EkmbOUkPpe1v12wyg+s0YCI+OBlAWWTmOZVjWaTUVv3zH9aYcZQBShw/j H2mfnt78TPsRizT0Br1er9sk1y9IBuDqGKBSGjciSx4OMCAi+CYIR31E7+MHgwf1XlBlT2tcHQAk 3piW7D176OXZmyARPMA/Vucnp7vlKOf0+Tr5plWrSuU6ekg4hKffo4St6z8+zUplnP21MVNmF9g7 CgqunQHT2fethIK1aw3UU/dkAMDYmb8Fy4q3Pq/0gmf/OxsNIJ86qmszaCMkhN7EDwYP8olgyZ6I NIDIpsYE//c+6q5HaNgwLEISlTYlWq2E0lV3bS6PGDAEYMPIuDcvAkDTVNetH8oUPudVixrWjoyT SOLGbKDyrdpZrfYUEQlND0yIa7HTlsJH3KGhARRrJyUDAEgzFGa9au3sMRGSqBkrCrRGbab02pUQ EpGexQ8GD/IVMU4H0o1JSrzuaqdHmpAsk4LX7fZGyaTh4PV4vOHh0vCOe728NdVOb3iPHr103Vpq ajzecFnrabVbEPPkKwETem9CUB9Rt7IEgwf5kBhPm6A+mTsQqsfVLaH3JgT7EXUxUTB4kG8FS58b QsgvutL5hsGDfA6zB6G+ruP4weBB/oDZgxC6bvxg8CA/wexBCAG0Fz8YPMh/MHsQQo1axo/H48Hg Qf6D2YMQuoqPn8jIyKioqJMnT2LwID8R4/DQYB+0ej2helzdEnpvQugdEe/y5cspKSmXL18WuhAU mrDdgxBqR319vTifDoBCA2YPQqgdmD3IrzB7EAplNeVbcpbv9AAAeD5enbelvMZbfWh1jkQikSxe /3ENANSUr8/LkkgkWYs3n/ZcXRGzB/mVGLNHErqEfmtRnxM/fFTp1jePuQE8xzdtOjVqOLshZUqU ysqx9syd8qd2VFZ+9Pt1svUcYddHr5qztaJ5Rcwe5FdifMxMQ0NDwPYllUovXrwoleK80yhExU/V 06WGozVjY/aU0qs/g8rVAA/VVn32b0jJoSwnL0WMGQUF8nXTi+RP2A6MGdG8HmYP8isxtnsQQr4j nblGtWFX8Rc7dypVNLh+sgAt/cXlcrkga/WLM4eOmK+1mooHVhqmUCMXv4PtHhQgYmz3IIR8aMi0 RfLZUxYAbWLSpVGMHEqHzSyZMwT2b8z5a112/3fTTAtdr7w2a8lvhqboT8HyTH4tzB7kV309ewgh eBkGhThZ9iNKMFxZmSUDgMy/GtQj0/i/ebWVzRw0QSefkrCBArCAzuRsXgmzB/lVX88ehPoA1nUC 8jfk8lc1R8x5hWOfrWHDGx+cOHk5Ye8/62JlCUNkLa57YvYgv8LsQSikeSryoigDrXNNjm9+LVwa n9xyeI00fsiQ+DbrYfYgv8LsQSikSce8xzARMll3h3Ji9iC/wuxBKLSFy2SyHqyG2YP8CsdYI4Ta gdmD/AqzByHUDswe5FeYPQihdmD2IL/C7EEItQOzB/kVZg9CqB2YPciv+ug4t2PHjh0+fBgAGhoa 3n333fDw8FtuueXWW28Vui6ExAKzB/lVH82eCRMm9O/fPyIiIiIi4tlnnyWEXLlypb6+vl8/bAgi BIDZg/ysj37U/vGPf5RIJJcvX2ZZ9vLlyxzHqVQqDB6EmmH2IL/qo5+2S5YsaTmFaHh4uFKpFLAe hMQGswf5VR/NnhtvvDEzM7P5v+np6WPGjBGwHoTEBrMH+VUfzR4AeOqpp2JjYwEgJibmySefFLoc hMQFswf5Vd/Nnnnz5tXX1wOA1+t98MEHhS4HIXHB7EF+1XezJzo6eu7cuf369bvrrrsGDhwodDkI iQtmD/Krvps9APDYY481NDQ8/vjjQheCkOhg9iC/6qP39/CmTJny7bffjhs3TuhCEBIdzB7kV306 e8LDwydMmCB0FQiJEWYP8qs+3ed28ODB5ORko9EodCEIiQ5mD/Krvps9Bw4ckMvlW7duXbRo0d69 e4Uup6/AySOCBWYP8qs++kFw4MCBvLy8jz76aO7cubt3737ggQcwfgKjoaFB6BJQl2D2IL/qi9nT HDw5OTkAMG3aNIwfhNrA7EF+JSGECF1DQLUJnmYHDx7My8t7//3377rrLqFq6wskklD7kwuxIzpy 5MikSZPi4uL4FmpUVFR9fX1BQcHs2bOFLg2FlL7V7rle8AC2fhACAIDExMT+/fszDFNbW1tbW1td XV1XV9dy4l2EfCKkvrJ1rIPgaYatH38LsVYChOIRZWZmfvfdd83/TUpKOn/+PA4SQb7VV/6euhI8 0NT6WbRoEQ68Rn3WypUrY2Ji+H9HRkauWLECgwf5XKh9ZWtXF4On2cGDB+Vy+Ycffpibm+vv2vqa 0GslhN4R1dTUpKam/vLLLwAglUqrqqqGDh0qdFEo1IT+15nuBg8ATJs2zWAwLFy4EFs/qA+Kj4+f MWMG/++JEydi8CB/CPHs6UHw8DB+UF/22GOPxcXFyWQylUoldC0oNIVad0FLPQ6eZtj55nOh10MV ekcEAL/88ktsbGxYWNilS5f69+8vdDkoBIVsu6f3wQPY+vGDuLi4ixcv4uwGIte/f/+ZM2fOmzcP gwf5SQh+ZQMfBU8zbP10188//3z06NFjx44dO3bM5XJdvHjxUpPa2tqBAwdevHgxJiZmwIABAwYM GDhw4IABAxISEiiKmjBhwoQJE5KTk4U+gm4IyXYPQv4WgqeNb4OHh/HTMY7j9u7du3//fj5yLl++ PGHChKysrFtvvTU+Pp5PF15cXBz/Ye12u/k04pPJ5XKVl5cfPXr06NGjUVFRWVlZWVlZ06dPnzlz psi/eodk9lRUVPz+979/+eWXp0yZInQtKDSF2mnjj+DhYfxcq66u7t///ndRUdEnn3ySlZWVk5PD R056enpvNnvmzBm+zVRaWnrkyJHf/OY38+fPnzVrllQq9VXlPhR62WO1WnNycp5//vn169fv2bNn 0qRJQleEQhEJIfv3709MTDQajX7a/oEDBxITE/fu3eun7QcRg8Hw4IMPDhgw4I477nj99dfPnj3r px2dP3/+zTffzMnJiYuLW7hw4c6dOxsaGvy0r54JsZPo+PHjqamphYWFhJBPP/00OTn58OHDQheF QlDonDb+Dh4exs+ePXsmTpx42223vfXWW+fPnw/Yfqurq7du3Tp9+nSKogwGQ8D226lQyp6WwcPD +EF+EiKnTWCCh9dn4+ff//735MmTx40b989//lPAMj7++OOsrKzs7OzPPvtMwDKahUz2XBs8PIwf 5A+hcNoEMnh4fS1+Dh8+PGPGjJtvvvmDDz4QQ5dXQ0PDzp07x44d+6tf/ergwYPCFhMa2XO94OFh /CCfC/rTJvDBw+sj8VNXV/fSSy8lJycXFBTU19cLXU4rDQ0NH3zwwaBBg9Rq9ZUrV4QqIwSyp+Pg 4WH8IN8K7tNGqODhhXz8OByO7OzsWbNmnTt3TuharsvpdM6ZM4eiqDNnzghSQLBnT1eCh4fxg3wo iE8bYYOHF8Lx8+2336alpW3atEnoQrrkrbfeSk1NPX36dOB3HdTZ0/Xg4WH8IF8J1tNGDMHDO3Dg QEJCghgq8aH//e9/APD+++8LXUg3rF+/HgD2798f4P0Gb/Z0N3h4n376aVJS0jfffOOnqlAfEZSn jXiChye2enqpvLw8Ojpa2MFsPfPvf/87MTHx0KFDgdxpkGZPz4KHh/GDei/4ThtxftCLs6oesNvt Q4YM+fzzz4UupIe++uqrlJQUm80WsD0GY/b0Jnh4GD+ol4LstBHzR7yYa+ui+vp6mqZffvlloQvp FY1GM3XqVK/XG5jdBV329D54eBg/qDeC6bQR/4e7+CvsmEajmTlzptBV+IBcLs/Pzw/MvoIre3wV PLw+Hj8XLlzYv39/VVWV0IW0r76+Xgx3411P0Jw2wfKx3nGd1kK1QqWWAwAoim0sIcRWrAEAACrf YAlspW25XK6kpKTjx48LW4ZP2Gy2hIQEp9MZgH0FUfb4Nnh4fTN+ampqli5dOmDAgNtuu23UqFGB nYOzS/r16xcdHT1x4sQtW7aIM4GC47QJluDhdVCtRUcDqCxOp1FDg9rI2YsAqGIbw9iLKYBCGxv4 aputWbNm1apVAhbgW88999yTTz4ZgB1BkGSPP4KH19fi58SJEwkJCStXrqyrqxO6lo7U1dUdPHhw 6NChABCY72HdEgSnTe+Dh3U5HQ6Hw+Hs+kc7x7Isy/V4j9er2ayRq8tchBDWqgPQHNDSkG9q+hEt 11t7vMde8nq9qampVqtgBfjcqVOnEhMTA/DpEBTZ47/g4fWd+Dl+/DgA7Nq1S+hCuuGNN94YPHjw Dz/8IHQhrYj9mdm9fR6P9+z21TlRCSlpaWlpaSlRkrydFTUAAODeniPJ21LRuJi74vksiUSyvLwG wHt6y+KsiKioqKiInOd3nPX2ZLfTp0/fvXv3/fffX1JS0uZHUf0BADiuDkAaBkBFRvCvcwCDEqJ6 sjNf+Oyzz8aMGZORkdG7zbi350kkz3/e+J5Vl+RIJIu3N77J7ootEknW5+29oe7yjRLJxhoAb83J Q+Une/SWtzVs2LDbbrvNYDD4YmPBjX8ez1//+tcHH3zQT7u45557tm/fPnv27CNHjvhpF2Lw008/ zZ49u7CwcO7cuULX0g0rV6586aWX7rrrrvPnzwtdSwtCh19Het3icepoAKALy6wuhnE5LDolBQB6 C0MIo6OB0poJIYSxqAAAFCYnIYQrVgOA2uJiXTajHEBVbPdh/WaNPN/kIoQwFi2A9qxFC5DvIIRw VgWA1sL0eF+d6vg76Zo1a3xycd6skwOoHYQQQhzFagAAWscflUUvB1DZ2mtMci6r0WjlCOEsGgCN r3oeN27c+NRTT/loY9cl8pPI3y2elkK+9fPoo48+/fTTQlfRQ2vXrv3d734ndBVXife06X1Xm7NM A20voji1NICikCWMjgZaZyWsRQkAoGr62GcLFZBv5PtGWT0NoDH14iDaHoVZI9c0Zw+lY4irUNn4 JYBWG/yXPEVFRQAwaNCgF1988dSpU9cuMG3atK+++qr3O2IsOgDK6CSEcAYlAE0D0HwvY6EcQGXg CGHsRrWcAgCg5NpiGyGEtRlU+QantYjm3wpVoU/eikOHDmVnZ/tiSx0Rc/YEMnh4IRw/5eXlKSkp ly5dErqQHnK73YMHDzaZevWB5kMiPW18MrjArKWB0rpav2jRyYHSugijowEUaiUNAApzex911iI1 AOgtrnZ+1h2dHgvjdDpdfmzxEEK2bdsWExMDAJGRkVKpdMKECdu2bWOYqztNT09vN5O6jbXIAfLL XITYFAB6i0UDoC5zEWJVNDYiGS0AKHQWm82oVwHQJoYwZg2A1snYDVolgMJgard11G3nzp0bNGiQ L7bUEdFmT+CDhxeq8TN9+vSCggKhq+iVoqKiW2+9VSTD3sID07PXLb29xtMkOi4NILKdI7T8xHgh Mg6gYMNWAICC9754YeL8Vpc6ag5tHrNgg9pgezgzvjc1QNO1n7y8vB07dtxwww2EkHZ/96ev8/r1 lu/W69988w1fTF1dHQAcPXpUpVI9/vjjM2bM+Mc//pGamlpTU5OUlNTLIwUAkA7Lk8NrX5969sbK ApC/kJl5KR+mFH+3bkRNAUAxlQbgpYsN5uyZmfFw9koWwDEAgAgpAEhl6XfPHAcQOXPyCJ/8XSYl JdXU1PhiS8EnANd4rqf52k9xcfGtt94a4L37SWVl5YkTJxYtWiR0Ib1y3333rV279siRI5MmTRK6 FhBj9sydO/fDDz/sZfAAwBXGAZZLHgBZixe5Ogao1IRwqAMAWuMoebry+ezcBQtpu3lOevO74f5I uQryja/MGdHLGnh8/MyZM0cmk8XGxvbr10/SHv+9brfb25R0+fLlmJiYvXv3ut3u1NRUAKivr/fF scqm5Mktuw/sG/ANyO8fCeCemQ9T9u2b6AJQU0PCAbxXXMeUKXJL4/LyiBYrsxwA1HEAUl+Uwmew L7YUZAQMHl7oxc/WrVuXLl0aFhYmdCG9IpFIli1btnXrVjFkjxi7Cw4cOJCUlPTll1/2cjv89R5d qwv4djUAlV9GGq/3WAghhLUqAYDSOK4uxhbnqw12n91tI/j9SXq9PjY2lv+Nx8TEREZGzpkz58sv v2xuId10002+mgONtRbyO1IV2QghhDHJAQCAyjcSQji7AQC0RivDEsKaab7PzaIF0DLk6j98wuFw DB482Ecbuy6xnURCdbVdK2Q63zweT1JSktjGKPfM+fPnBwwY0LK/XShiHGM9bdq03bt3P/DAA3v3 7u3NdpJvX6KhYAU1ffv+SrfHU3O2fGPOsA1Av77idn6BC3UcAIA0489mHVjWrtx8qHndlKzRcMHd m70381UXYm9IJJLa2tqoqKibb775L3/5y/nz5w0Gw1133SWRSPgFhg0bdvLkSZ/sSzpyohIAgKIn pQMAyMbOlgMAzL8zEwC8rAsAhqWnycKrP85fUgpw2d1iTDUHAD853T4ZZQ02m+2mm27yyaaCheAt npZCZuD1gQMHMjIyhg8fLnQhPpCSkjJ9+vQvv/xS6EJE9pWtJd+0flibVkldPVpKaWxszTA6GuS6 q9PYlGnkAFBka/op1TQCu3cEb/HwLl269Pjjj//3v/+93gIvvvjiCy+84KO9sUVKACq/uR1p0Sua RrsRQhxaeeNvg1aqFRQAaM9YtEBpGUJYWxEAALQdIdIz+fn5a9as8cWWOiKek0g8LZ6WPv3008TE xCNHjghdSM+p1eoXX3yxgwUsOjl/LwFj0bX6eKUURZZOJhSwGfLlqqKeNUMYiw5AYelmB82rr766 cuXKHu3Ql8Ry2rTLV51vjNNht9vtDqdPRk91nUiCpytKSkoCMBy5CedyOpwulhBCOJZpPX8Ex7Is 55tf1PTp0z/77DOfbKoDIskecQYP75NPPklKSgre+Lntttv27dvXwQIWHQ3U1ezRm6w2q9VqNelU VMfZwNmLAABoXc++bDEWHT9StFu+/fbbm2++uUc79CVRnDYd8FX8BF4QBQ8hpKGhYcSIEaH0LOSK ioq0tLT6+np/70gM2SPm4OEFb/wwDBMXF/fLL790sEzr7JFfDRunAQC279khp1SmxnhhilRyVSE/ eZVdzTeP5Lpr4sNVrG289U+lNTKEEM6mUcjVWo2CAgBQ6U1cU/b857/FckpZ1vjVuuX2r2vQoEEO h6PjZfxN+NOmU8EYP8EVPLz/+7//++1vfyt0FT6jVCo77ifxFcGzR/zBw+skfliLWq5UK+UAINcU s4QQxqqRUwBAyTW9vsuu577++utJkyZ1vEzr7KGMDpZjWZZ1lemUALS5xqIAUPJDb1xlVNMAKKMa QFVkKlTw67Zk0tIAVKHJZi3TAwCtNRPGzPdV64rLinVKANBbWT57zC6bEkDB543TCG0HWLVj5syZ AegS6FgQZA8h5MCBA4mJiXv37hW6kC4JxuAhhFy5cuWGG274z3/+I3QhPlBeXj5o0CC32x2AfQmb PcESPLyO4oc10wCqIovTbqSBMjq5IgWAupjhmOJ8CuSFAe4wb7Z9+3aFQtHxMm363FpS6kwcHzNy PUuI3aDkJ51yGPMBFDZCbHo5ULpW3XKNN2g3XiiyFSqA0jKsWQ6gLnYQQghnlQNoza7G7GGISUPx F5zsBiWAqtN5wJ544olNmzb19C3xjeDIHhI88ROkwcN79913s7OzOR9dbhFKfX39r371qzfffDMw uxMwe4IreHjXjR/GJKc0LkIIYXUU5H9VSgPVeCWDNdHdv6LuK88//3ynUx22yZ4ii91ht9vttuap 81k+JFimUA60zkJYqwIA1EVWm1mnBABVsdnKNJ92jLlpchBCGue8V9rcZvrqlI+MjgJNi+xhrXoA ysQwRXKgujAN2ObNmwUfbiDGMdbtmjZtmsFgWLhwodFoFLqW6xLDcOreWLJkyahRo5588kmhC+mV 3//+9ykpKY899pjQhfiXqIZTd8rr8Xg8XgC499579Xr9rFmzzGZz24US+VuKuTqAyAiIg8QI/sZj DgCS4nxyv3H3VVVVjR49ujtr0DeNSh+Snp6ePmJIcmPR0sxZaih9b6t+mwFUvxkDwEVTQO1ZMGZk 9oqtALBpdvb/nWCvboIBGDCw8VZ3x3cHgBqXwv+Pa7z9oK71LqUZM/PB8q5e/6YB1t6X1WmJo0eP rqqq6s5B+YGw0dddYm79BHWLp9nPP/88cuRIvV4vdCE99N577w0bNuz8+fMB26MgJ1GrFg9j0+cr aZqWq7TmDsdyWrQ0penRnQOcy1xmdnGNPWNac3cuv3B2naLxPgdaXejgCGm39XO13cNoKdCYz+go UBsdpLHT6dqr8QEybdq0TjuiW7d72h94ZtbJAdoZVsC2cz+1S0cDyLV2lnAus4q/Hb7VO8+/Ra6W u7PoFAAAlKYrD4k7fvz4uHHjurCgHwVZ9hCxxk9oBA/PbrffcMMNAeuz8qG33norIiLCVxM0dFHg s6d1V5sjHwBodXGZUSOHjvv6rboeZ48ZAMwsIcRlLjZaXV3vlb3uQ0naxg9jktP8fV2MjgKtmXFZ Cpu+IdNFVn9FT1VVVWxs7ObNmy9cuNDuAhRFHT16tOONtL6/R95u9yBnN1AA6mueycI03dzWamFH maK5fSDX2FhCWIvi6iCCln1ujbvjHMUUgEJvIV1w+vTpoUOHdmVJ/wm+7CHii59QCh7e6dOnAeDe e+8VupBueO211yIiIlyuQI+ICnD2tLnG4yzLB1A2fp5xNl2+zsYSa5FaqdFrFCDXmglxGTRKAKAU ahUNdNs7pq8Zy8ta85XqwiItDQBAa4uthLPl8w+3oFQWl12rUhXbWEKIvUzf+LJCY3FxhBBrkVqR r9UoaQCgFFobSzp+KEnnA69Zxul0Mv68/vj3v/89Ojqan2hq1qxZn3zyidfrbbnA8OHDT5486ccK rot1OhwOR5dz3l4EQBm79ufvcrkGDhzY89J8ISizh4gpfkIveHgXL14cP368SqUS+UPpCSEcx61Z syYjI0OQGbcCmT3XDi4wa+UAco1GRQHIlVp+LLKF795R5BvMZ41qCoBqHpgr17XKnnbG8rL8WF65 wWIz6pQAoLOctRRrKaC0BpOrxkwDaMwuxqoHAKXOaLeZ8mngH4HI71euMZiMehra5ly7DyUR/L6f v//9781THQJAXFxcXFzck08++d133/E3hyUnJweyC7dHWEO+AgBA3dVPIY7jwsLC/FpTp4I1e4g4 4idUg4fndrt/85vfUBRlsXSpIS+I48eP33LLLbNnz7548aIgBQQye1JTU/fs2dPylcZefoXGUFyk ogBAaWWJRUc3PS7WrgZQNzY7SLGq9UxR1x/L2/SiS0sBpTETzkIDbWavXu8xaVqMe3aVUQB6K2PR 0qAo4l80a6iW/XsukxYA1IZ2ukPLysoGDRo0ePDgVCEMGDCAf7RVS+Hh4QDAX+aJjo5mWYHG2HUV ZzbodfpiR3caiFFRUR6Px28ldU6Mz1DoIn7km1wu//DDD3NzcwNfQLCPautUbGyswWD4+9//npOT s2rVqlWrVslkss5XC5TLly//v//3/1599dUNGzYsXbq0X7+gGbTZY9u2bXv44Yf37NnTYg58N0C+ 4701QwDmTDaWJOR+fPzPd9UBNWuSDADcF0wAeU0jptIyaLjUYnMcBwDND1JJmzgdLOVO73QG6JkT kgEAIJ5eSr/jAfByjYs3PvGi9ujnFnphZuOaUQOHAziveDkAatJN/IsR0kTwNO/pug8lsVqt999/ /9/+9recnBwixAMvioqKXnjhheb/RkZGSiSSsWPHPvnkkxMmTACkWgdWAAAgAElEQVSAqKio2tpa qVSgYXZdEj5xzsMTu7NCfX19XV1dZGSkvyrqgiDOHhA0fkI+eHgSieThhx+maXrdunU33XTTM888 8+STT177PTHAWJZ94403Nm7c+Otf//rw4cN9Z7Lqe+65R6/X33PPPc3xw9UxQKU0fiOQJQ8HGBBx zUnd9MoV5wVo/WlzzVjeSSnhAFB60uWdLAsH8Jh3l8KsxsyJuPqopfDBo6DUebHxf9yVUwB50eEA 0Jw3XOsK0uerDb+d2qYuMQwTHzhwYENDQ79+/WJiYqKiopRK5dKlS4cNG9a8QGxsbG1trW+erCga tbW1LXsahSFgm8tXAt/5FtpdbddTWVm5aNGi5OTkV199VaiLQBzHbdq0KTU1df78+R1Myx1IgT+J Pv300+TkZH7yPdaqBwBNsZUjbJlOwY96Ml8dS904WtfGEsZWfM01mPbH8soBQKF3EuIw6QEg3+gg jJkGKLQ4m/vc7AYVAGWwughhDGqKH1/XYr+t/k0IazboDeZWo39FcmPs119/DQALFy7ct29fuw8C Hj9+vCB9zmYNBfmd3yXaM//73//S0tL8tPEuCoXsIYGNn74ZPM3++9//3nfffTfccMOzzz4byLlH zWbzc889l56eLpfLOx3zGkiCfIFrET+cWa9q/iqpNdpJ6/t4OIdR0eK7ZpuxBu2N5TXLAWi68TVa bWAJIZxNTQEAZXI2j/R1Faqan05CF1lcbfbb+l6itg8lEUnw8K5cudLBT6dMmSLIRFNOa1lZZ89f 6DGr1Sr4VNYhkj0kUPHTx4On2bFjx/7whz/cfPPNN95449NPP+2/k/PQoUPPPvvs8OHDR44cqVar zWYfPFTJt4TqPGjZ+uEYl9PZ+FSKdnCM0+G47k/bjOVlzfywAtbldLpa3nbCsWzba9mM02G3O7o7 BlpUwdOpOXPmGAyG7q3DOflx7QCg0pfxb7zLWqzkx60rtc1D0vmh8Pc+v/Haia5tBk1+kZUQwjlN ajkFAEApiswOQghh7XqVnH+l0NST6aj3798/ffr0HqzoQ6GTPcT/8YPBc62KioqXXnpp3LhxQ4cO ffjhh1977bXS0tKampoeb7Cmpmbfvn1arXbJkiXDhw/PyMj4wx/+IKqGThsCdly3jB+fYUwAUOa3 WQSCK3gIIc8884xGo+nWKk6jGkBebLFZjFoAUJe5iNNIAdD5RRZrmZpunH3g6lD4/3x17UTXZi0F GlPjcxbkGrPNolcCgMrGuXQ0AKUyWiwGjQIAiuzdvgFq69atjzzySHfX8i0JEWJsif8cPHjQT0MP +sjggh6rqqr66quvjh07dvTo0WPHjsXHx0+YMCE7OzshIWHAgAEDBw4c0CQhIaGmpuZSk4sXL166 dMnlcpnN5mPHjl24cIGiqKysrAkTJkybNm3cuHFCH1knJBIhT6I9e/YsWbKk9ci33vFWl+w2Z+TN GuKHcUhiGFzQXVu3bj18+PC2bdu6vkrl9sVjlkCxRXNXZoqzwnwhbjR8voRake0gLw4B8JzeGTVs gcHODf98JvXhQqZkuQyg5HlJ7nE9u/vh8x8vHyZPdJBXftqcs8Tz6oHZ38RRK4xOkpMM4Kl4ftnu eb8fOmnCkiIbO3+EFODsekmaWWfZvTyzWwf17LPPJiUlrV27tptvhi8F9zi3a/lp5BsGT6dGjx7d POUiIeTUqVN8CFVVVTUHDK+6ujopKak5ivhYSkhI+O1vf5uVlTVixAiJRCLssQSRa0e+9VZ4cs78 WT7YzjWCMXgAYPTo0QUFBd1aJeO+Nfm7qdlUAQDQSu2rf8qOABnAujTJuuZl7BfYG5qHwgNMfUAH 1D+Oe+6rfHcrrbMMAfipccE6AHUGP+JdmvnKe5meiu0AsGBkVPOm5HWtBxV2QVVV1dSpbYcdBpqw zS4/OXDgQEJCgq86x7CrzbdC7K9ODIfz6aefJiUlffPNN0IXcl1B19XW7Ny5c8nJyd1ahbFbbU6W Y5yWsiIlAKUxm7U0UFonxzEMy7rsxuIyJ9dmKKBdDaDSamkAg4MjTQMFGbMWQG7hO9VYmy5fd+w/ 2sbH0zEMyzKWsmKzvds9pKNGjTp+/Hh31/It4U8bP/FVYGDw+JwYPqx9SCSHI+b4Cd7g4Y0ZM6Zb g1xM+QCU1sERQlyFCqA0ZmdZPgBVaHESwpZpaQC5tW32tJ3ouvGnrjIKQFVoZglTpqUBlLYasxxA ri1jCXGa9QCgMXVvDsNTp04NGjSoW6v4gyhOGz/pfWxg8PiDSD6sfUU8hyPO+An24CGEPP7443/5 y1+6vjznMMqvdi0pjHaWELZYc/U1vdlJrnmkRZuJrpt/ai/WNK/Ij6F3mq4+HVWuMXZ3pMG2bdse fPDBbq7ke2I5bfykN+GBweMn4vmw9glRHY7Y4icEgocQ8s9//nP27NndXIl12O325geX8i+5nI6e TcvNMk6nq9UQd5ZxOJyuHk3x/cADD7zzzjs9WNG3RHTa+EnPIgSDx3/a/7DmHGVGoR6L3Cuiyh4i pvgJjeAhhNTU1MTFxbndbqEL8YG6urrExMQzZ84IXUjwPDO7x6ZPn7579+7777+/pKSki6vgqLYA 8mzPkWyu8ICX+fbIqW6P1+nKlvuYe+65Z/v27bNnzz5y5IiAZQTpqLZ2DRw4kB9PKHQhPvDRRx9N mjRp6NChQhcisq9s/tP1dgy2ePyt5V+drYifD0ZpcVo0+UUMYYpUCpVaAQAKjV6frwAAWm1gCCGc Q6/iH0qm4R/eyNgM/HwwinyDixDGolfpLIQQwppVSv3R5i37+WHL4jyJhG39hEyLp1lJSUlmZqbQ VfjAjBkz/vnPfwpdBSF9oc+tWVdCBYMnAFp9WLM2NYDKYOUYE01pXPzEX/nFTodJAUDnFzscZiVA oY01qgHUBhfHlGlokBeynE0JoC62cawtH0BeaGNMGpqfe5HfVPOWA3k4YiJU/IRe8BBCvF7vTTfd ZDL5a3LPwLBarampqSJ5HFHo97k167TzDbvaBCBNSadg8A1p4QBxIAWAOqBfe2JW8pCs6RQ8+tu7 hgwZO5GCkz//78geUAys3f9Z6fmULDD8WG3dsxW06lkjwqUjnjVrDNv2112d4R/iWm+5bxKk8y2U utpaCgsLe+WVVx577DESzBPBPPbYY3/84x9F8iyiPpQ90GH8YPAIynv1H4lxEeEAwNYlykckhANw dQCR/dznLJAk/cXlctVClr7ojigAoCL5uOE4gFEJ4QDAvxABTDtb7osCHD+hGjy8hQsXRkVFbd++ XehCeuhf//rXhQsXHn30UaELadS3sgeuEz8YPMLx1lmaHzTWclxAOAD80vy/sMFZNMDomQ8//LB8 hHNJgTVy1HTa8ua+s14Azxevr6XGDQ8DKP1PpQeg4oMNpSANb7Xlvitg8RPawcPbuHHjCy+88OOP PwpdSLf9/PPPKpVKo9GEhYUJXUsToTv9hNHyug5e4wmwNn91Jq0cQG4+a5LTWhdxaWl5GUMIYZr/ oaNAa2ZYm6HpmTJUkZUhhFgKlU0vqK0MIS7T1UfR0Dqmect9cqxBG/6+9hOS13ja9e67744YMcLp 9NeTdfyBYRgA+Otf/yp0Ia0EwWnjJ3zk7Nq1C4MnwK79sL72wTDt49g2d9ixjNPpdHEtFnC1euRM l7fcC0GRPcSf8dN3gof33HPPxcXFifm5Hi19//33N9544/r164UupK3gOG38ZP/+/bGxsRg8ARYs H9ZdFESH44/46WvBw+O/s7700ktfffVVu0/aFoODBw+uX78+MTHxzTffFLqWdoTa83u6S9iHr/RN IfaeB9fh7Nmz5+GHHy4uLr711lt7v7W+cI3nes6cOaPVasvKyiwWyy+//NL5CoEVERExbty4O++8 c+XKlaNGjRK6nPYIG30+4TLraGURSwghrEEl15ldnNOkogGa7jokxFmUrwAAoJRGe6ux7aHxDgSX EHvPg+5wfNX66ZstHuQroTDOLX74qNKtbx5zA3iOb9p0atRwdkPKlCiVlWPtmTvlT+2o9FTuWrAu 2sYR24uQO+fvbqELRkhA/Mi3WbNmmc3mHm+kL7d4kE+EQvZA/FQ9XWo4WuM+vqeUXj0VKncCDKyt +uzfx1JyKMvJS+ERiQBb/7huy4mhTzgOLJUJXS9Cwupl/GDwoN4LiewB6cw1qg27ir/YuVOpov9/ e/cf50R95w/8FUzcXSDI7rrUgyLiCi5ahitbC9QfdRbkoFSCP7gqhPuK1oBWIVuvYPxW7lzuiqE/ NDyszeJXwymx5+22GhED2rA0WglHs5XZalYNNbQGISvZOkEm6wQ+3z8mm132F/sryWbyfv4Bm2Qy 8/lM8plXZuYzn0H0uAC+8MtoNBrFrOpHF07Wlt8eCfjmj2/eOJebtGon7fcQ8t3vftfhcAwifih4 yPDI9kG/YSL6DADA+0TGZMEAuMKMMea18ga7EHKZYPEyxljEDZhCnd6nnjWQO1S2znO6Ort27br4 4ov/+Mc/9nN6OsdDhksON5tzyS4TYFR6HLCgy9KerZaAdM5Vh0b7OaMB5vSGI0epbJ3nenX6Hz8U PGQY5VL30D7FdlSN+9uW6KNzipXHiXhrq6QtLta3DyUZbzkWRVFJWfE54+jlVgdZdVDZOldBdV57 7bXVq1fv2bOnsrKyt2noUBsZXjnfbAAg3rSsiHPx9ui+NcUDfKsKNhw5R2XrXB3V6Tt+KHjIsFND swESsZik0+sHMTK4OjYcuUVl61w11ektfih4SDqopNkMmmo2HDlEZetcTdXpHj8UPCRN1NHHmhAy DLp0vKbgIemjnp9sg6OmH625QmXrXGXVQfvez29/+9t//ud/puAhaaK2ZjNQ6ttwjHwqW+cqq47i zTffXLhwYX19/W233ZbtshB1UmGzGRBVbjhGOJWtc5VVJ0Wt9SIjBJ3vIYQQkmmUPYSoWWPtmuoX mwEgceSRqjWNMRw7uKNKo9FoZm1+tRlAa1P9slkajUazatu+eJYLS/IIZQ8hajb5qq8+ufKNGBAX dm9p+Ork+J5Jc58wB6JS+IkGw4wXj3z2P8bl+kdDTA5evH7+9iYaaJdkiPb8kxBCclbZvGUGcO/G 1o3Z/SxvfwnNdQB36sO33sCXs4Ajn8kzOOxc/uNr6lbeHYzMKKcbjJAMof0eQlRNO3OtCb/du6d+ E8w3XyH+7RPwF395KhqNnprlcCycXHz7MxGfe/7Hro3cFROepf0ekin53pWFOvNknsrW+civTqxx 27jK9eBt0X3rippri2YcDbOfTETL1lkTLtr5XjN3583Rw1XF2FetcVwbeuH2Kcq7Rn69SE6jY26E qJyeW2LG+s++v6QYQMUKl8UwSaMBwJnr3p551Ud2rrJEwwECjL5NU7JdWJIv8v2nDf24yzyVrfMc qE68aVnR+ofEfde3n82Jt7ZK2qLi9tF3460tUQklE8s6j8abA/UiuYzO9xCiZrGmWk0RB9uW6zt1 IygsLi7uNOx7YXHZxHODh5B0y/efNvTjLvNUts5HfHXisVZZXzzgDmwjvl4kt+X714saWOapbJ2r rDopaq0XGSHomBshhJBMo+whhBCSaZQ9hBBCMo2yhxBCSKZR9hBCCMm0PB3XwGw2Hzp0SKPRALju uusAcBz3i1/8orCQLnIghJC0y9NulFdfffX777/f+ZmxY8fGYjSQYiaorPOuyqqTotZ6kREiT4+5 /ehHPxo7dmzq4ZgxY6xWaxbLQwgheSVPf9p88cUXpaWlbW1tysOCgoLjx4+PHz8+u6XKEyr7Qa2y 6qSotV5khMjT/Z4xY8YsXbpUOd+j0WgWLFhAwUMIIRmTp9kD4P7771cOu+n1+h/84AfZLg4hhOSR /N2tZoxNmDDhs88+Gz9+/GeffXbBBRdku0T5QmUHc1RWnRS11ouMEPm736PRaNasWVNYWHjXXXdR 8BBCSCbl9U+bTz75ZPLkycFgsLy8PNtlySMq+0GtsuqkqLVeZISgrxfJNJVt1FRWnRS11ouMEPl7 zI0QQki25HX2/PznP9doNJs3b852QQghJL/k6XhuAB577LGXXnrp2LFjixYt+uKLLx5//PFsl4gQ QvJFnmaPEjy///3vy8rK9u/ff+ONNwKg+EmrxsbGgwcPKn//6le/AlBZWfnNb34zq4UihGRHPp5O 7Bw8yjOtra033njj4sWLKX7SR6PR6HQ6rVYry7JOp2OMxePxs2fPKqNL5C6VnZM/fPiwz+cDsHbt WrvdDuDrX/86/UQgw05VzaY/ugePguIn3R577LEtW7akxtC78MIL161b99Of/jS7pRo6lWWP8hNB p9N9+eWXF154IWNMkqQzZ86MGpXX54bJsMuv71NvwQOguLh4//79brf74YcfzkrZVG/16tWdd3Eu uOACk8mUxfKQHm3evPmCCy44ffp0IpFQ/l2/fj0FDxl2efSV6iN4FBQ/aXXppZfOnDkz9bC8vHza tGlZLA/p0erVqzvvxul0OvqJQNIhX7LnvMGjoPhJq3Xr1injt44dO/bBBx/MdnFIDyZNmjR79uzU w8mTJ1911VVZLA9Rq7zInn4Gj4LiJ31uvfXWM2fOAJBl+Y477sh2cUjPHnzwQb1eD2DMmDEPPPBA totD1En92TOg4FFQ/KTJ6NGjly1bNmrUqEWLFo0bNy7bxSE9u+WWWxKJBIBEIrFy5cpsF4eok8qz ZxDBo6D4SZP77rvv7Nmz999/f7YLQnpVWFh42223jRo1qqqqqri4ONvFIeqkqu6hXQw6eFKo4/Ww O3PmjDJwuFarkuuaVdbHWvHOO+9ce+21r7322pIlS7JdFqJOKmw2iqEHj4Lih/RNldlz5syZ5ubm 6dOn63S6bJeFqJMKmw2GL3gU+RA/o0aNUuU3QaPRnD17Nt2LUOWqIyStVHi+Z3iDB/lx7oepV7ZX bU7y+XxlZWVvvvlmtgtCVEtt2TPswaMoLi5uaGhwu90Wi2UYZ0vICHTgwIHvfve7drt9xYoVe/fu zXZxiDqpKnvSFDyKkpKShoaG119/neKHqNiBAwduvvnmX//617fddtuuXbuMRiPFD0kH9WRPWoNH QfFD1C0VPDfddBOAuXPnUvyQNFFJ9mQgeBQUP0StugSPguKHpIkasidjwaOg+CHq02PwKCh+SDrk fPZkOHgUFD9ETfoIHgXFDxl2uZ09WQkeBcUPUYfzBo9CiZ+VK1e+8cYbGSsbUbEczp4sBo+C4ofk un4Gj4LihwyjXM2eQQRPItba0tLS2hofxmLkW/zEW1uOHTvW0hob5Ntj8cTwFogMwYCCRzFv3rxX X32V4ocMg2xfdT4Y//7v/z5jxoxIJHLOs5LfeE7NDHZPMPWax9bp3ouGGn9E7jJPwcZzVj+T/Dxg 80eZHPV7/dGuU/Xs5MmTHMc9/PDDQ65Z1pz/myCHHGa+0zq0Cv1cO0lRh4kDYBOCDg41/ugQCjsA GfiG52gjeuedd0pLS994443Bvffiiy/eu3fvsJeK5I/cazY9Bw9jTPIbAJPTGwwGAgGhzmoEYK4L MsbCbgvAOX1BUZIiQa8ZAO+Qzn23X8keFvW7PYGozGQ/AL/UdSG9yfX4Od8GNGLjARhd/pCyDi0c wNm6fQa9kwUeqPGEGZMDXk9gYLk1eJQ9PRpK8KTmQPFDhiLHmk2vwcNYcpdFEFNP+Kw8YArKzG/j wdlSL0gBp9FkD5+79Utmjxyymc3u5vdqlJ/4nFkQGZNCDrMBADij0xfurWw5HT99b0CjfhuAumDH KpNDLl5ZOSzqbt+nNNs8ImNMDlqNBovNauQAwOzwyUysU/aZOKM7FPFYLa6gxBgLeewGAJzBaqsx mWwhmQWcZrNTUBYRcJrNzgCTg1aj0Wq3GZT90f59Fv2s17DIuewZevCk5pPP8XPgwIE77rhjxowZ I3Oob51ON3369DvuuMPj8WR7VfUsl5pNX8HDWMfhstQTgh3gfSILe2oAgDfZnC5/ICT29Js7mT2i nwes/r8KbhsHzubyReWonQc4s0cQXFYjgLpQr7/Zczd+0OcGVAnvHg+T+Wy8sk8Z8DoA8DY/E/0G AIDd7XXbTQAcASnosQGczeWNSFE7B6svKgoOAEa72+9xAAAMPpH5bRysvvaFcrD6UnMzWx1CJNL/ z6I/9RoWGVjEMBqu4EnNLQ/jR5bldevWXXLJJc8999y7776b7eL0qqmp6fnnny8oKLj++utlOUNH GvovZ5rNeYKH9ZA9omAHeL/IGGNBj9Ns6DhdYakTGJPDAUEQBEEIRKT27Ok43yPw4P0SkwIOAHVB 5ehbuAYw2IU+ytln/Ih1ZqPZYgIAg1WZZdBtBQBwNa6+ZptufW9ABTsPWHvIHkkwADXe5IcSdBrB 2UTJbwAs7jBjjMkBw7nrkzHRxsHqj/qtHEx1SoOI+qzKJ9V+5JOxTmfgDIDZFWJswJ/Fees1LHIo e4Y3eFLzzKv4OXPmzLRp02666aZoNEPnLIdIFMVbb7113rx5ktTvUwgZkRv93AbZnVpuAyADsZaW CTeseOKVfUyWwkGf3cxvWb7+YCy2cwbHcRzHzXC839r1vQkZgCwDMgAsv6JIo9FoNJM2AWiT+1hm 3z3fTu7b+aR0UzgatH688dl3WhJH669Y7HQHRTFkrTdwLx4Zzj54w6lgHIBzuqgljr64rbapRSlw 8g6kk2ZfB+G9SAIicMkkPQBoJy3mEEen9Zl06pBT4K6+XHmndvRF3ZfZcrxB+UMEpk4tAQb8WZDO BtGrrT/yrefb6tWrx48f73a7c+Vu4nq9vr6+furUqStXrkz3vawGJAeyZ2DBo0vdiTm+t3Y9wF+u b/3VhAnjftEIANrCieVz1mz6MdBwIqpfJyb9cHbPXyOdDrIsApwnLMmiKEmi4HVvMkzruwi9x0+i rZT31Nw+sbh86f38lj/8JeB6GjXbF5Xr9VMWOaz8/7wVOn8Fs2Ha3GXAxt82dXStPva72pXrnz6N C0TgovHJdR7+89vgrp6gPJKTUdXW8ywLp1RB+Lw9OeROUxUqR89jH+1GaWH7k3ICGMxnQRRpCh5F /sTP008//dFHHx1o+OVdWm3VI3tSv8aad6zSVNX2cuVB4mjTwaajMQCNW2dpNh8cWhFitbM0Wxu7 /VbuTbxplUaz/c+ndu7ceerUqZ07dw5t6cNppGfPgIJnHPCe/1Bzc1NT41s7HvnO8u2weu8pQ/G3 rTw2rq5960g8kYi1Hq3/6X8Ahqlf0Rbqk7Td5yUDaGj+qEU/7ToDhG31hxJ6fez933A3LP7d8fNf o6LEz+7dux955JEuZVS2rKfbwBXogOS/ygK/UlJ03jlnRWHFEhuPtZzhxYNHYvHYkbdqJy3eAtPm yslTv8dj/aOOo3EkWhufWr6Tu/3r+n7NUjvjWhM2meqbWuItB/+1cj0wTgki4dlXjsQSR/f9aq2A cee+Z3CfBUlr8CjyIX5OnTq1efNmm812wQUXxICGLYufbc8AuS2Mk729L7GHm8u99BGAyUuf8i67 fGilGGC/BlkOA21yQqPRbNu2rbq6+rPPPhtaAYZPtg/69eX853g663J9D2ewuwPtr4Wdna9NAe/o 1kWq/eyCYATsgsjkoIUDwPlEFvHZU+80WD39P2d38uTJmTNnWiyW9ieiNt7gFRlr79ogCjagJswY kwPGczvpDbvXX3+9ra2tt1fP/00QA8mOa8p6qKlTPhU57DV2WjtBiXWsQ8YYE+0crP4ok/w8eJ+Y fMbmFxkT3dbkW3kOgCUoMzHoav+ceCMHgy35iaTWzEA/iwx8w0d4I0rHOZ4+lqXicz8bNmy46667 GEtezmEwALCEGGPKCVHOLjLG5LCzJvmtNtbURRgLOM3KQ0tdIOiy1tQFAk4Lb3Ymv9BRn4k3ukJS 3x045YjPYuAAmKw2E2DzR6WA02BKzqTj725L73IWvLq6+t57703/quqXkdtsBhY8/SBFI6FQKBzp /6UlsiS1TyuJ4XAk2mMPuT6dGz8d2SPYeN7mZyzqbL/mlbe40pc8L7zwAoAxY8Z8//vf/+Mf/9h9 gn5uQMVoJBwOR6JdTlpKkXA4HB7YNTsRwe10JS+gingtQHsneFmMRKJSH/MayGeR59mTyeBJLVGV 8SOKYnFx8YkTJxhTNugGf9hvAgx2P+uUPYKNAwwufyDgqzMAFk9YDHqMAAxWf1hUum5GfVaA80QY YyxUZwLMwb4708oBEwDe4vF5lV9rNn9U9NuAZNfT1N/dl94le2KxWElJyfHjxzO78no2QpvNsAdP FnXb++lKjEQi0TTu8TDGnn322TFjxgDQarVjxoy59NJLH3/88U8//TQ1QeY3oFG/FYDBYnfazQBM zrR088vn7Ml88KSWq774qa2tvfXWW5MPJD8P3i+ziNsCwB1lQYdByZ6I4HH7w4zJYjRQw4Gz+hiT HDx4u8A6LiIMmpJdNyUHD87q67sDpyTYlQMwjDEmC0rHUVGwpX6upf7uYendev/efffdVqs1I+vs PHo405F1WR8kdHiVlJTs37//xhtvPHv27FVXXcXat1apf7s87OPJQU/v8/mUPxKJRCKR+OKLLx57 7LF/+7d/q6io2L1796RJk9K7CnpSPHtDWPjGLvcfDjUXOb2hFddPyXwZVCwD53h6o5z7Wbp0qdPp XLhwYYaXnibPPPPM5s2bOz8jSyhbZLEbtix+eIdnXuos56mXV09aLCQfGO7XJTvSdO6QqS031nA3 PHdoCz/5iQY86qiEGACw/IqO072GTtPLaANWXq4sQXvZYg6fn1u2TqeAui+9K5PJtHLlyg0bNvS7 6ukyErPn5Zdfvvfee9URPIqSkpL77rvvqaee+stf/lJUVARAo9Gk/u3ysI8nBz39Z599lsohhSzL F1544dGjR9vaeumJln4TZ1atmVmV7qVceOGFstxXV+xRo19KQRMAACAASURBVEYNpe9paiWPHFkM HoXK4ue99947efLkokWLur2iv8fmevoyw/ztgOE6IPZro8G3xBXev3BiMXZUFT3fS9u6Znk1Nu38 L8dXBM42f4pWblQ6cB68QS8ndPjo0B/kSzt14JQBNJ1MoEwLINIo4OrkC8mReWMtx8Fd0s+lz5kz R6/X/+EPf7j22muHsk6GQaZ3tPohGo1yHLdx48ZsF6Q7WZL6OhPRm6wfQnzuueeUY24A9Hr9mDFj TCaT3+9PTTAyvwlDp9Z69SFbh9pGckmG6Kmnnrr77rs7Hnd0nGGMMb/dAAAGu8iiNg4Gh19mctBj A8BbfYxF7Ry4GrfIOl86Ha7hAMBUF2SMKYN3GGxeibGI3wHA6ut04WrEwwFmp19islBnQcf5Hjj8 ETnqMwLge1l6t2NujLGHHnpo8+bN6V1l/TBCW2aa4keOBn3+oMyY6Lf2fKF+78SAy9Ae2FZX4Pxv aJf14GGMPffccwAKCgpuuOGG+vr67h3ehrKNHspaVUgBB2Dwi90HI1eGg+tTxGvkLUIvl2znW/b0 urmX/EaAt7hTKzPgMIK393KaUQ4JPiEkMsb8Vg41vuEvT0655ZZbnE5nx+NzsyfZJ9ZgFxnzO5K9 2sAZa8y8cp7GbzcC4Kx+ofOwHQ4jYPC2t5a+O3AGXTXtL3IA7H6RsbC9vanwvJI9PS09InTvQLt7 926e59OypgZi5LbMdMSPLFgBq8SYHA14PIEB7MHIQRNgsHmikijUWdD5m9enkRA8jLG2trZf/OIX ffRvGVL2DHqttusY/UgZQcfpCwYDgUDA46xBanienkWsHJSx4HqUV9nT14Zeah9kr/0ncEe34J6m tgOw+hljkYDXKwzp2zuQ+InajQZnQGSMScE6g9EhMtmnbE85oysQZYxFhToDBwBGmyczQ8ScOXNm /Pjx/e8bJkUjkWRnWlkUk90x+3W8pM8OnLIYCYcj51ZZjka6Tt/j0rs4derU6NGjsz7Ezohumf2P n5DXkRx42pi8r4wUrDOZrHaltztv9oYkKVCnTMObnZGgy1yj9GnuzzDMysBlhuSPa9ELwBE4f/iM kODpjx620T2uB8YCLltyVRssvrDcfa1GAnUGztx+zECsMxvMzgBjst+pHGbgzHZPl3XXOXt4wNax FyM7eHBbXrEZeatbuZSChT1W3uRQZu+z8gCX3GfqZ71U6jyb+IxfkjKAsnXirVH6hjG/jYfFG/FY AEtAlMJeK2AMyKKdg7EuxOSgOc3Xw6W89957M2bMyMCCMulb3/rW22+/nd0yjPSW2Z/4EQMOACa7 JxT01fBQrtYUBTsAGO2BoN/KAzA3t4ZcNhNgdPmCrX6r0iO+n8Mwdy6Rw9jRgPuQQ8HDetxG97Qe 5KATgNnpDQX9NiNgcMTEbmtVEoypA9lRLwfYBTFYZwJgc/n8Hju6jQHaZb/H6g0zWZIkKex3coDF c9RtBniHyBhjooMHajyMsajPBhj8Yb+x993QPMme82/cM3xJyiBKqBQz4ABqoixqBewByVvDwWh1 uVwul50D5xWlOiMAo63OLQS73f8xPV555ZXvfve7GVlU5qxatcrhcGS3DDnQMs8bPz4rB4Mz+UWM ejnAERBFwQaYkgeAIh4OsPlFOWAD7FKqR3z/h2FOkj0WDjB4z/e1z63gYT1uo3taD3I04HL5RMZk KeqxJm+s0HWtMuaxAAaHxFjIZQIsYRa1ceBtySPdfruhyx0ZOmdPl/M9ylgJot8GcN5o8vN1BiUl Gq0+kbHUCNn9q5fq9GuzntlLUgZfThYyg3N6nBzMISbVGcGbbU6HwhWSGJMiPrfDbOTQMXZGem3d uvWHP/xhBhaUSZs3b+7jisPMGOnjuQEoLi7ev3+/2+1++OGHe3o99u4egV88M9lbvGj8VCByOgEA 3OxJyrP68VMBICHJOKenfbLrbT+GYU4uyl+9RXAEXri+rK++6aq5Pqn7etBqdZ82WMZpNLqikvkb G1BaoAW6rlXgW3fa4Xr+/XjsD89t5+13Tox/ckhAw/pKjUaj0Wgq17pQWtDbQmOAxSVEwqFQKBQK ReRXNpQXQj97iRmC+08tLQd/K6DmpnLU/2ulC6ZvjA43vuU/iZOH9h882pqPY7sNqDt1+yUpWPzw jqM455IUjUY3rmTGJgFTL+r1kpQnnzsUjx1+ogGPfq9yEGOKz5s3b9euXXfeeeebb77Z+1RTVtmm rpy/stR2xxQUfu06vgHTV9x1112G8udX14k4Wl204Is5dz3xwmGPGW9/ED1vlYfugw8+uPLKKzOw oEyaPn36hx9+mN0y5ED24Dzxo/uHaWiI/D35SD79MTBhtBYAhI5rsESgx4uZBjYMc9HFK82266/o a7RM1QRP0rnrofk3D619cpo3FJEZC7vNONnz9QuFMxdZ0PDCdsf/c8F88wxoR48GTHUBWZZESYoE fO7Hvt3bShSBS6ZeVjZxypQpU6ZMSYV8+R1WfovD4bA/aXAsL4P8JXhwvvncjMobVgsQ1i6e6/q4 l3GE1WtQ1/Ho77G5uO2r56/eianouCgkKin7NGIfl6S4dv6X47nkJSmDGlO8P/HDGYwAvr9kFoCK //O0Zd9ijUajKblhVt3/nVk4ZZWdm1+imaXRzH/S+MD8TFyPHAwGhz97Eq2NbzX2/8dSrGmbZta2 Yfx+V1RUBIPB4ZvfYORG9qCv+CmctcSMTQ+82twKxF7dYhJg5iv0QAGwcUt9MxDbs62mAcaFV+kh AzgeibV/5vqBDcOciJ3+6qzL+hhrWm3B043cBqD00klliWMHH1v8JEoRB7quVQCYcrvd8OT69Q0G Oz9RC+2UJSZs3/zqUalQL4eemDF38c5QX3uOcg+NsvK2+7Fz40YXt25JBaBfUbuPHT7MWPvRJImt 6+VGGGo16AtItVOWOuyp6wUSAKZO/+qEYu2RfdtXNwBxGUjgJE5+Hum8sSusWFjDudau3256dEnx EMYUP2/8SOJJwLq4vFBZ6k8Oy9FIRJTkJ26vADB7zQtSNOIORyT2wpyMfOCnTp1KXRs3fD6uvKHy 4wHtqAvnn6T/xowZE4tl+7dadg/5DVQv536iTnNqiGW+ToiyVF+DdjZPmDEmBeuUR38VbOBsYv+H YVYedB5YqZucO8fTWQ/fhJ7Wg9QxzjSUG7ByNn/3tcoYk0MuDrC0d05jomBJfURcTeDc0zOdr+8x 9HocP2LlAaOz62tdLrY4b71UYcDXzWT8kpTBlV+wGwHYfJm7JaggCAB+8pOf/O1vf+txgunTpzc3 Nw9pGXLEZW3vTOvwSnKwJtlV1CyITAx5lDGqwRls7qDyjpDHnuw+arIFoh1nUpkcspt4Q417iP2j T5w4UVZWNrR5DFXutczeuh6IkXAoFE51aBf9NnB2kcmRc4ddliVJ6nrr8sEMw9xFTgcPG9A2WhYj 4YgoKX+KymULPa3VHt4ZjQxqMPAhUGX2DPsFm2m6JKVvPdei14tS0uWZZ54pKioqLCwsLCysrKx8 9tlnP//8884TTJw48ZNPPhnKIiIeC2BwC0HBYwNg8f5VcNs4cDaXLyqLNgBGuxAMehxm5cJBUUh2 3A0ILiOAGq+yNZOUn18wD72PxRdffFFUVDTUuQxNTrbMfnW8Huw19oOQ68HDVLqNZmqslzpGClCM hLo899xzY8eOTe3AjR07tqCgYMmSJbt27YrH44yxcePG/f3vfx/KIgIOI2B0C2GZyWHBJ4SiTE51 zpQEt8sfkZgshQWHkj1+K9d+RQGLeG2mGneLYAcMZiMAS2CYLgnVaDRnzpwZnnkNykgcS/S8lHM/ N954I4DHH3+8x2mKJi+ocyMD9wFV/TkeMnJkfZDQ4aWc+7n55pu3bNkiiuKZbhKJRPcnh/d5SZJG jeo47X3q1CkAr7/++u7du71e7/XXXz/0albctqHmFW4xtxMAb7L97D8qkZChdLMtxOnoYdMEQ2rs aR1ih/YI/PcqlRPPZdevq70esaZawPXkTgAnlXepQE5mD/oRP9qy2bd3H3Z2uFHwkExaunSpaoJH MW/evNdee23x4sULFiyYOnXqBe20Wm1BQYFWq72gJ8P4/Msvv/zDH/4wVZ4xY8acOXNmyZIlDz74 4Lx58wCMHTv21KlTF1100aDrGIvqVjwjWV6IBd79/VM3LF9dft3hdQCg0yFx9I25KzfZPIHV36rQ o7Gq6F9lpePu0Rblva2N9c8c+srd32oDzELk7ucmcNymW+QnFg1xw3369OnCwsLOoZsFWdznGrqT J09yHPfwww9nZekqONSWkuvfhN6orF4HDhy4+OKL9+zZk+2CMMaUs3xDPQCU9cNu//3f/z169Git Vjt69Ohp06Y99dRTXY6wXXnllYHAAMYO7s5XA3C2sMwYizqN4Kx+Jvp5wClElEt0XUGRyRGXhQN4 T1gOu80A5wpEZTFgAWDxioINnE1iLOK1otu41INw/PjxCRMmDHEmQ5TzLTNb8aOm4GGq20anqK9e Q4mfQY4XLgYdNSae5w1mmz85oofsd6Z6x5m9oUEmUNaDhzF2+PBhAPfcc8+f/vSnHieorKw8dOjQ UBYhhz2GjjVt9ISkZD9DcD4xbGt/jTdZjBwAW5RF6yx8avX6o7LY0YNUdJoA1Jx3TK++BYPByy+/ fGjzGCo1tMzMx4/KgoepcRutUGW9Bh0/gxovPFwDgLe4vR6rAYA51H4Bg8MflsSQw5QcP2mgRkLw KLrfUqSzb3/72/v37x/yQqRwKBQ6ZyBqub0jodL/U+k5KontvQvFaCQSTdegQYcPH541a1aaZt5P KmmZmYwf9QUPU+k2mqm3XoOLn0GMF/6htwYwJZ+Sg/Yae1BiAacplTehOqMyLO+AjJzgOa977rmn trY226UYZi+99NJtt92W3TLkzLgGfSspKWloaHj99dctFktaF0SdC8hIMHfu3F27dhmNxr179w5u DuOA+N+jSMTj8fixxv95ogFLvvn16Rc3bNzaEAOA2Bv/sbHhq5fG/uQHTry0tXqWRrPsB7u/9cCa 8kJUrKhlr9xVCCSO7Vu9fCdX87W+hpnqJrd661155ZUffPBBtksxzD788MPp06dnuRDZjb7hle69 H1Xu8ShU9k1IUWu9FAPd+xnEeOHKQAMwWl3uOjMHwNRxfYkUMAEwOQe005NDezwKuodCmqitZaYv flQcPEy922i11ivlwIEDpaWle/fu7c/EXc73nDNeeHKSoBmweCIRtxmoiTAm2A3KDbEYYyzq4dAx xFTIZQbMwYGUNueCh9G949ImV6/v6Y1y8I3neQBbtmwZrtmq/lCbcneDbJdi+KmyUp0pB9+WLl3q dDoXLlzY/ze2jxfe5WhZ+R1Wfq7DMT72pMERKAP+1iaCm5CcSF82FbhIl9xo6IorzNYpk/q9xNw6 1JZSUVHx6aefnjhx4itf+Uoml9u4dVZl23b26Jxhn/MXX3zx7rvvVlZWDvucBya70Zcmw7v3o+49 HqIC77zzzsUXX3zevZ+ufQ16ukxETo4Mm7xLqXIBitUdkJnktRuRunM8YxHB7XD1dtO+HkqYc3s8 KbfccovT6czwQiMBr1dIyzZn9+7dPM+nY84DopK+Bl0MY9cD1e/xEBWYN2/eq6++unLlyjfeeKOP yXS6AmCc8vc4oEDXw2EPbfm3rTxg3HhNGQAUVhj9DvPGxTN0mqIb1u60eWwz2wd0Od6wdbXhbakf xcvRPZ6U+fPnezyeAbwh0fLq1jXKsYTqHW8pN59sbd6zpkqj0Wiq1mxrak0AaK5/ZM3WHVtXaW7+ vz9dNqv6YKvy5lh99bLqF5vFDw/s/+AkgETLwUeWzdJoNJpZq+objwFA/OiO6mXKMy8ePDbQ6uzb t6+qqmqg7xp+2Q6/NBr63g/t8ZAc0s+9n0GQxWgkcs548P2X03s8ij//+c9Tp07t//TdBq6OsoiH A/iaOiHgtfAAZ20/lwYYa1zv/N4ImOqCjCV7edgF0W/jYPUxFrIAMFj9QcFhAmAOylE7D3BmjyC4 rEYAdaGBjfz9j//4j1k/2cPU19egi6HEDwUPyTnpi5/BUUHwKL7xjW+43e5+Ttx94OrOXTakUB0A V0gW7Dx4u3L5qMeSvEQ35DIBljBjfhvPWf3KZbzK8U8mCRZjzaF3HQDqgsoPgXANYLAL/a+Iz+cr Ly/v//Tpo/LsYYONHwoekqNGTvyoJngYY7W1tbfeemt/pxaFmo6Rcmz+iJzsqt6JzS/6O92XT1JO xUmi0wDeLrCO7LEpUZQiCY4uszLY/P2vyN133221Wvs/ffqoP3vYwOOHgofktJEQP2oKHsaYKIrF xcUnTpzo18ShQDAiyWJE8NaZAM7q99t4cLaILIuiJEVDHrc3IrPO2aMcWzPbbDzgCssslT1+G2AQ krfzC9pr7IffsQGcJyzJoihJouB1+0P9HXonFouVlJQcP358wPVPg7zIHjaQ+KHgISqQ3fhRWfAo NmzYcNddd/Vnyu4DV0e8NQDnFCKMSV4bDxgCXbOH+ZXTP4bkUbjkq1EvB5idfomJXhsPmIKtfgNg sHklxiJ+BwBrv28xXl1dfe+99w604mmSL9nD+hc/FDxENbIVP6oMHsaYKIqXXHJJf8a07mHgaia5 rR3POfwRxphwbvbIIRcHWNrH00u9GnJbO47UeUKMsYjP3nHAzerpZ0+D5ubmkpKSlpaWAdc8PfIo exhjJ0+enDlzpsVi6fFVCh6iMpmPH7UGj+KXv/zlvHnzEolEP6btPnA1k6KRcCQiDqxXmvJOMRKJ SvI5z4TDkWi/53X27NmFCxf+53/+58CXnS75lT2s9/ih4CGqlMn4UXfwKP7lX/5l6dKl/YufkeLs 2bM8z996661nzpzJdlk65F32sJ7ih4KHqFhm4icfgocxJsvyggUL/umf/ikaHerNQzNDFMVbbrll 7NixX375ZbbLcg51jmvQt5KSkv3797/22muPPPIIaOQConb9HPVgKHJ95IL+02q1e/fuHTt2bElJ icPhUG57OjL9+c9/fv7556+++urS0tKTJ0/qdLpsl+gcGsZYtsuQHdFo9MYbb/za17727rvvUvAQ 1Ttw4MAghhzt55zzJHg68/l8Npvt8OHDwWBQluVsF6crnU43derUysrKe++9VxlbeaTJ3+wBEA6H q6qqGhsbx4wZk+2yEJJ26Yif/AweMnTqOObWWrtq2YvNMQDxI/XLVu2IIXFwR7Uy1t6rza0AWpvq leH4Vm3bF29/26RJkz788EMKHpInlINvK1asePPNN4dlhhQ8ZNDUkT3FV013WV99H8D7u592TS6P 79s0d3VRQJTCT800zFjXnIj9j3G5/tEQk4MXr5+/vSmW7QITkh3z5s3btWvXnXfeOfT4oeAhQ6GO 7ME1yx3Cxjda0fq79Q32f7mm+Q+7YRz/YcMbf2y9iIPQIulKOexc/uNtr3x0dzBy/8wB3V2eEFUZ lvih4CFDpJLsKazgzah373M7YV5UgRMfCvzFhaei0Wi0oNqx+VJd4e3PRHzu+R+7NnJXTHiW9ntI fhti/FDwkGGQ7U7ew8ZvMwDgbT7GWMDOw+xmjLGol4dRkEJmcJ4oY4x5zDDWhVLvUtMaIGRABndF Tp5cx0PSTT1bXjlUB8Cp3NZCCli4ZLia6wKMMb/dCIADAGPnkfcoe0g+G2iQUPCQ4aKePtaxptpx 3OdRtqE4+USitaVVqy/WFyZvDBxvbYlKKJlYVtjpXRqNetYAIYPQ/wNodKiNDCOVbHmbaldxa3fa fNF1c4rPP3UnlD2E9CdUKHjI8FLLljcRi0lFer12oO+j7CEE54sWCh4y7PJ9y0vZQ4iit4Ch4CHp oJI+1oSQIeqx4zUFD0kTyh5CSFKX+KHgIemT70ec6JgbIV0okVNbW7tmzRoKHpIm+b7lpewhpDuf z3fTTTe9/PLLCxYsyHZZiDrl+5aXsoeQHlHTIGlF53sIySfxpkeWrXlkzTKNRrNs6544AMT2bF2l 0Wg0muQNRwjJAMoeQvKK7HNtl27aHAl5xI0b32nB0fr7F2+cHhSloHu6Yca65kS2C0jyQ77vVtOB BZJfYgeXXfd7x+ENxYjXziqKbP/rBNOlnzvEDbP1QGzbrHEFL0lrKgpBTYOkGe33EJJnSpURDeU2 oEAHlKJQp7yQiIMrLRrw4CCEDAJlDyF55mS804Ox31rGr//1IQDxI+6NQunlX6HsIZlA3zNC8kxy vwcFAKCdufpnpnGVmi0AYKkLzC7s/Y2EDJ98P6RLB7UJAeItLTFtYXFxp9F4qWmQtMr3rxc1MEJ6 RE2DpBWd7yGEEJJplD2EEEIyjbKHEEJIplH2EEIIyTTKHkIIIZlG2UMIISTTKHsIIYRkGmUPIYSQ TKPsIYQQkmmUPYQQQjKNsocQQkimUfYQQgjJNMoeQgghmUbZQwghJNMoewghhGQaZQ8hhJBMo+wh hBCSaZQ9hBBCMo2yhxBCSKZR9hBCCMk0yh5CCCGZRtlDCCEk0yh7CCGEZBplDyGEkEyj7CGEEJJp lD2EEEIyjbKHEEJIpmmzXYDs+NOf/vS///u/yt+1tbUAZs+efc0112S1UIRk3+HDh30+n/K30jS+ /vWvf/Ob38xqoYgKaRhj2S5DFmg0mgsvvFCr1X755ZcXXnghY0ySpLNnz2o0mmwXjZBs0mg0Op1O p9N1bhpnzpwZNYqOkZDhlKffp02bNmk0mtOnTycSidOnT585c+ahhx6i4CFk8+bNF1xwQappJBKJ 9evXU/CQYZen+z1//etfp0+f3tbWpjwsKip69913p0+fnt1SEZJ14XC4vLw81TRGjx596NChq666 KrulIuqTpz9nLr300pkzZ6YeXn755RQ8hACYNGnS7NmzUw8nT55MwUPSIU+zB8C6devGjh0LYOzY sQ8++GC2i0PISPHggw/q9XoAY8aMeeCBB7JdHKJOeXrMDcDp06dLS0vj8XhBQcGJEycuuuiibJeI kBEhHo+XlJRIklRQUPDpp58WFxdnu0REhfJ3v2f06NEGg2HUqFELFy6k4CEkpbCw8Lbbbhs1alRV VRUFD0mT/M0eAPfff//Zs2d/8IMfZLsghIws9913HzUNklb5e8wNQCKR+OCDD6688kqtNk+vsSWk R2fOnGlubp4+fbpOp8t2WYg65XX2EEIIyYqR+Ht/1KhRqkxEjUZz9uzZbJeC5DBqGkQ1RmL2MMbU 2sCyXQSS26hpENXI674GhBBCsoKyhxBCSKapKnuaapdpqmpjPb4Wb6zSaLY1tiLR2vhWY2ui0zM9 SbQeOdh4JJHO0hKSMdQ0yEgzEs/3DIGIk728Ujj1Z27P6Kl6QKi8odIvseKOZ3ryyW/mVkJiG1S2 gki+oqZBRhZV7fekNNc/smrztq1rqjQazaxV247EgYT49t5dociHmxdWAqicU93UKr69d1comgDQ /Oq2Ko1Go9HMWvbIwWOJeHP9Qm4jsPE71S/GgNbmPWuqNBqNpmrNtqZW+sFHchg1DTJSsJFn0KUS 7Dw4u8iYYDcAMFhdPo+DB3ibn4l+HrD6/yq4bRw4m8sXbVWeicpBJwCz0xsK+m1GwOCIiSGXzQQY Xb6gHPFwAF9TJwS8Fh7grJGM14sQBTUNohoq3W9uE2Gsq9+wVAv8zPrE6jigA4BCjJ25gC/FK9ct nFOMRgCFAEpmu1w+fumconjr12bycIqyfsp3Fl4NFCycUx6ofUhATfjR2ycC0xx1Wy5bfuDoD5dO Uel6I6pHTYOMDOo85iYD3DWXK41AV1h6zmsJGYAsdzyh1eo+bbCM02h0RSXzNzagtEALSDKANhkA 9MCmSRqNRqMpumw5gNBJKUPVIGS4UdMgI4Q6swcA4sn/5Z5e7DxIVfNvHlr75DRvKCIzFnabcbKt 85RyWxicLSLLoihJ0ZDH7b2T6+UcLCE5gZoGGQHUmz29kQE0NH/U0vFEG4DSSyeVJY4dfGzxkyhF PDnZ8UgsMfnrPIRn3wy06vU49MLq+Yt/3lt3IUJyGzUNkkEqOzg7DqVA8gh2UvvfuklAgU6Loovm cljJLSiP7FSembbgbh6Gy3RbAJgtJmxZv2DbdQeXTATWXzHukij7kdvqX8xNWAkAcPgjFSpbZyQv UNMgI8tIHMdao0l3qRLxOAoLOzWURKwlEi8sKdMXIhGLJYr0hVok4vGEVluo1QKIt7ZEE9AXl+mH 0LrSXy+ictQ0iGqMxI9crV9EtdaLZIxav0JqrRfpQ/6d7yGEEJJtlD2EEEIyjbKHEEJIpuVk9sSb d2g0yxpjQLxxleYc1TsOnmdUqZa3VlU90hTveyJCctIgm0bsyI7Na6qqqpZVb2tsoWHZSCbkZKdI WW4DROXvGGB2+h6Yc5Es41hj3fyVc4suCf9k0cRe3tqydcENOwXDA7IyZgghqjKopnFs87grNvEW 92PfE34+v3LCxyH2xJQMl5vkn5zc7+lMBKbOnFVeXlFRUVG1wuLgsfvdQ9tWVW3dc1SZ4Ni+rVVr dii3Ijm49XsbBQ7nXuWgOPrWjuR4vau2NrUm4s31y2ZVH0zewSRWX72s+sVmINH44uZZGo1GM6u6 dl8MQOLI1lWrttZuW9b7/U4IyYp+No2P3np2E0yhfT9ZdH3VhvqgvaYice5RAWoaJC2yNYhpH85b KlGwA7xfZEzyGwCrN8xkSZKksN/JARbPUbcZ4B0iY4yJDh6o8TDGoj4bYPCH/UbwPvHcGQYcAEx2 Tyjoq+EB1IQlwQiY6oKMMRb1coBdEIN1JgA2l8/vsQMw2AUm+g0AALPVIUTkIdaLkL6lo2n4bQbA YLWaOcBgsgnRc2dITYOkx0j8yAfUwIxdstRgDUpM9NsAzhtNtg1nUFJagtUnMibw4P3SOTP0WTkY nMn2EfVygCMgeiyAwSExFnKZAEuYRW0ceJtfmcpvRnV8tAAAB9hJREFUN4CzRSW/ATC7QsNSL0L6 lo6mIdiNAGC0utx1Zg6AKdCpdVDTIGmSk+d7OosBFpdQ/Y1xp2UAoydNKdMCmL3EjPXuP7VUfPlb ATU3laN+TaULpnWjw41v+U/i5KH9B0vnVE4pVqofe3ePwH9vZnJdFI2fCkROJ+640w7u+ffjtzU/ t523CxPjnxwS0LC+UrO+fdn8YihHNqaWZL7ihPStf02j8PjvYkBN+IUNE4Glczz7Sua/+v7jFbOL lXlQ0yBpkvPZIwKXTL2sbGKXAXTL77Dycx2O8bEnDY5AGeQvwYPzzedmKC+vXTzX5o+uK1YamO4f pqEh8vfkW+XTHwPLRmsLKxZZsPaF7Y7DLpifngHt0dGAqS7wy2WXSQnEQ4f9LRfpcRoAZOoaREac /jUN/K1NBDchOZG+bCpwkS61WaCmQdIm2ztePThvqTofWOABmz/afRo5WAcA4DxdbqYo+bsfcwu5 zADnCkQZE10WDjArRwr8dgMAGOwiY4zJLhPAWYMiY2LAAsDk7qMAg6gXIX1LR9OQAg4AVndAZpLX bgQMQqfWQU2DpMlI/MjP+0WUAg7AkDqhahfEnqaKWHnA6Oz6muTnu/U1YCzqNHPtcczXtZ9vlUMu DrC4249Zi4IlNRVXE5AYkwQjYOu5AAOuFyF9S0/TkP0Oc+rHqM3T5QwNNQ2SFiNxCL9sDSwYazkW PY2SSRP7HJE30doSSWj1xcUDHreXBkwkQ5S+r1Ai1toaT2j1ZcU9XfdGTYMMu5H4kav1i6jWepGM UetXSK31In3I+WtLCSGE5BzKHkIIIZmW832s+y95RFurL+7xkDYhhJBMUdF+T9eBe5fV7juSem3f tjW6cSUTJkwoKSnSLNvcfbDepm1Vs7Y2It5YpQw/lWhtfKuxlS5OIOoXP1i/bdWyqqpla15862hf 06UGySZkyFSUPUAMMDm9wWAgEBDqrPq186+orj8C4NiemvnrfU5fUJSkSNBrdm2q/N7OLndRkJX/ Cqf+zO1ZOFUPfFx5Q+XHlD1E7Rpr75i7/Nlr7v6xuQorb7hsR3Ov9xfRAoAoZ65oRM1UlT0icPXM fywvr6iomHn7hhd8Vv7J5VuPJHD8Qx+4e26eU64vLCwrv35LwGmc1hbtMVcS4tt7d4UiH25eWAmg ck51UwyIH91RvUwZyPfFg8cyXClC0ijeVLPWZRMOrltatXRdrc9hu0Qnx4/Ur6qurd9RrezlHN1X W6XRaGat+tETTwDjuo8BT8ggqCp7gHPG8Ji1+HvAR59JuORrPIT146rWbHvx1cbmo/IVK16oXTOx x1Nd0slXnnxS+EK/bIONA2fbfMdXi1prv3PZ6n1TPYLgWomVcyfVH6W9IaISiRMfuIDP39m2apZm VtWqIzNuX1Sul0+f3Pnk2uWrP7Y51+mFbZfNXzvJ6vI9NX/fdiHb5SXqobrs6UQ5OKADJlY9GvQ4 zeM+Wr/SUDnjsnE6zSP1TUDiWHNTU1NTU1NzS+owgw4ACjF25gK+FKXXLZxTFHStbUDdb7dUzZy5 dIO1Bti5J5ClChEyzCTxJIBNa/fM3+yunhtbOXfS1oMtAADOE31l3YqqmP8VGJyODUvnXH/X235b 6sZ0hAyRqvu5yW0AZCDW0jLhhhVPVK14IhE/dvTwrqcsa5evN4i/+f0MbiMAwOqPLujy3oQMQJaT Cbb8iqLUK4Y2OuJNVMUZeH1FRSGWXtu2e9zTv//LfYsBlI7XAoj/5VADV/Wz5GZCV5DNUhJ1Ud1+ T8cQvPG9tesB/nJ9668mTBj3i0YA0BZOLJ+zZtOPgYYTUf06MemHyRHju81MB1kWAc4TlmRRlCRR 8Lo3GaZlqC6EpJlOVwCgpFS56kBXUIouN/X9EhA+/6J94gyXjqiZqrJnHPCe/1Bzc1NT41s7HvnO 8u2weu8pQ/G3rTw2rq5960g8kYi1Hq3/6X8Ahqlf0Rbqk3rY+5MBNDR/1KKfdp0Bwrb6Qwm9Pvb+ b7gbFv/uOJ3vISpRWMFbgI1P1B+Lx1uaXnuiAbfPm6y8JANA4bXLTdj0QH1zK+JH/+s/1wLjsllc oibZGsS0D4MsVZcbNXIGuzvQ/lrYaeY7vcY7fOEu7xZsPGf1K4Pv2gWRyUELB4DziSzis6feabB6 znP732GvFyHt0vEVEgOuVNsw1LiiyRsxpO6kEHGakiNUc0YDYOxy/5FhQU0jD43EIfzSNLBgvLXl hHhaN3rchLLi/p3mSsTjKCzUAkA8diwaLxrMEL0daMBEMkTp+gol4i2RKIpKeh7FGmhtOZbQ6suK 9T2+OnTUNPLQSPzI1fpFVGu9SMao9Suk1nqRPqjqfA8hhJCcQNlDCCEk00bi9T3KUKDZLsXwU2Wl SCZR0yCqQYdZCSGEZBodcyOEEJJplD2EEEIyjbKHEEJIplH2EEIIyTTKHkIIIZlG2UMIISTTKHsI IYRkGmUPIYSQTKPsIYQQkmmUPYQQQjKNsocQQkimUfYQQgjJNMoeQgghmUbZQwghJNMoewghhGQa ZQ8hhJBMo+whhBCSaZQ9hBBCMo2yhxBCSKZR9hBCCMk0yh5CCCGZRtlDCCEk0yh7CCGEZBplDyGE kEyj7CGEEJJplD2EEEIyjbKHEEJIplH2EEIIyTTKHkIIIZlG2UMIISTTKHsIIYRk2v8H5K9XZnIN pHgAAAAASUVORK5CYII= --Apple-Mail=_998752BD-94FC-41BE-93BB-3ED3E3C23C82-- --Apple-Mail=_4272089B-80E3-437E-BC08-2EAF8D524AC7-- From hansliu@gmail.com Tue May 8 02:40:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B597321F847E for ; Tue, 8 May 2012 02:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGBkD0O-9qj3 for ; Tue, 8 May 2012 02:40:46 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D304921F855B for ; Tue, 8 May 2012 02:40:44 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4644859lbb.31 for ; Tue, 08 May 2012 02:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j+JsJM9hBAhO12IAnQpH+9fTe7ZM0GpgdC6MX4kBrO4=; b=dOIvBBhTffszurvaCkSoEp040KEwKtmKE1qDIyJ0MYSoC3c3a3/UqXE5xggJ8eiody azXzKf+MfldmSZWI9GB8Pbp3nlHYGJfAOZl1LkgowjIkQdvwtjdDzDhe2eNHfmEHWied kzfUh4VWo4rQVLTwLYIejAE78QEqqG/GSyr0/YUTt/3s4cqx3rSU/Oyf3pm3INnuSF69 1CtLFpeqI0AzJQ7mkyRTalz6D4a7BgwWFfMjyetynn+GqbXEuczJJ+ehpvdxzVXTYMYu 5UWIzCXeqIEsGp50zw5yyIhZC8+zV8qjCKaPPiBjsdr9m06MwQc1FDyn8rlWy6OBHXEG khFQ== MIME-Version: 1.0 Received: by 10.152.148.34 with SMTP id tp2mr4140141lab.47.1336470043735; Tue, 08 May 2012 02:40:43 -0700 (PDT) Received: by 10.112.43.8 with HTTP; Tue, 8 May 2012 02:40:42 -0700 (PDT) In-Reply-To: References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> Date: Tue, 8 May 2012 17:40:42 +0800 Message-ID: From: Hans Liu To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/related; boundary=e89a8f22c70535b6dd04bf832e07 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 09:40:46 -0000 --e89a8f22c70535b6dd04bf832e07 Content-Type: multipart/alternative; boundary=e89a8f22c70535b6db04bf832e06 --e89a8f22c70535b6db04bf832e06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about run IPv4 and IPv6 provisioning in parallel. Cache 6rd option and DS-Lite option if there is one. Try bring up the native connections, either IPv4 or IPv6 or Dual stack, first. then take bring up the virtual interfaces via the cached 6rd or DS-Lite option. And again run IPv6/IPv4 provisioning when lease time out of a IPv4/IPv6. For example, a device gets native IPv4, and 6rd and no native IPv6. Later on, ISP may start their deployment of native IPv6. When IPv4 lease time out, the device re-process IPv6 and IPv4 provisioning, and it may now get both 6rd option and native IPv6. Best regards, Hans On Tue, May 8, 2012 at 4:53 PM, Ole Tr=C3=B8an wrote= : > Forced single homing can be done. but at the expense of creating > dependencies between IPv4 and IPv6 provisioning. > see the attached flow charts. first one for multi-homing, second for > forced single homing. > > how a forced single homed CPE is to deal with changes (link failure for > one protocol, lease times out for IPv4 address or IPv6 prefix...) is left > as an exercise for the reader. ;-) > > cheers, > Ole > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Instead of following the fashion, we lead it through. --e89a8f22c70535b6db04bf832e06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about run IPv4 and IPv6 provisioning in parallel. Cache 6rd option and = DS-Lite option if there is one. Try bring up the native connections, either= IPv4 or IPv6 or Dual stack, first. then take bring up the virtual interfac= es via the cached 6rd or DS-Lite option. =C2=A0And again run IPv6/IPv4 prov= isioning when lease time out of a IPv4/IPv6.=C2=A0

For example, a device gets native IPv4, and 6rd and no nativ= e IPv6. =C2=A0Later on, ISP may start their deployment of native IPv6. When= IPv4 lease time out, the device re-process IPv6 and IPv4 provisioning, and= it may now get both 6rd option and native IPv6. =C2=A0

=C2=A0

Best regards,
Hans

On Tue, May 8, 2012 at 4:53 PM, Ole= Tr=C3=B8an <otroan@employees.org> wrote:
Forced s= ingle homing can be done. but at the expense of creating dependencies betwe= en IPv4 and IPv6 provisioning.
see the attached flow charts. first one for multi-homing, second for forced= single homing.

how a forced single homed CPE is t= o deal with changes (link failure for one protocol, lease times out for IPv= 4 address or IPv6 prefix...) is left as an exercise for the reader. ;-)

cheers,
Ole


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




--
Instead = of following the fashion, we lead it through.
--e89a8f22c70535b6db04bf832e06-- --e89a8f22c70535b6dd04bf832e07 Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; name="Screen Shot 2012-05-08 at 10.49.50 .png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: be2604c289354f54_0.0.1.2 iVBORw0KGgoAAAANSUhEUgAAAikAAAH4CAIAAAAAe+peAAAX/GlDQ1BJQ0MgUHJvZmlsZQAAWIWV eQdUFM/Sb8/MBpaw5JxzkpxzziA5KzlnlhxUQECCgoAiAoqCiogKokRJoqAIfwQUVEQliARRMSAo IG/AcO+733fPO6/P6Z7f1lRXV1d1qNoBgO2WZ0RECEwDQGhYNMnGSJfHydmFBz8JEMAICEAASHt6 R0XoWFmZg/9avo0DaOf5WGJH1n/n+18LrY9vlDcAkBWKvXyivENRfAsApMU7ghQNAHZHnkBcdMQO Po5iBhKqIIov7GD/X7hlB3v9woO7PHY2eiieAoCM0tOT5A8A1TJK54n19kflECkBwNGF+QSGoaw8 KNb0DvD0AYDNA+XZExoavoOPoljE69/k+P9fMr3+yvT09P+Lf81lt5DpB0ZFhHgm/H+a4/9dQkNi /ozBhVbKqGBbM/TJhNot3tvTwBbFLCjOC/A1Mf9NvxQRrWvzm94eGG1it2MjFD8JiDG2/40XYoLt dVDMgeLN4HCzHX7UTjBLmNdeSxTToVjAO0rP5ZdMWDExwM7xN4+5j6++AYrRVQQ7kcJt/vAHRMXa /qEnJgbo7f3DH+RpuuNvIopzPEm7c0F1gEt8Q4x2xuVD8dWIaCu732MNhYXs/T0X+I0fydDmN/7h G7U7392xogPsjH/JR2ii0QXwSybC4RdoaPJLB0Q6gGT8h64dEbK7ptG+iB0pxmbHDgIo9vMNs/8t E8nx8dQ3+2UTpBwYAk9AAr7AC4SBLcADzIEe0P/d8qD0MLT1BuEgBK0kHuo/b7BvsSPYGewYdgr7 /C+33h8+EAh80Ocfuve/0W1BIniPSvUFUX9Gw7BhNDFqGHO01UarLEYZo/Ln3dBy8/JfrX7p6o/2 lfhN0f2tfey/a+8emEb6jz5ef3v8T50MwZtdqb85pGulF6U3//T/14xxBjh9nDHOECeKZCE3kfvI HaQfaUeaAQ/ShbQgg0jHDv6PUTx/W4W0O18zdERfELP7K+x/1SjmL8dvKlGMqABsdvmD0XeBf0dw 2NU68H9IiUGrFyopCH1n9neOfywthFpXAaOL0UDtjNoYw4RhAxIYedTiOhgt1AcKKFXvP3v9biWA 364tY3fnEgzeojg02jc+emeh64VHJJAC/QOieXTQ09J3D49JmLfkHh5ZaRlZsHP2/traX2x2z1SI 6dG/aOEyAKjsnJWH/0Xz+ABAcxB63ND9iybUDAC1LAD9p7xjSLG/aJidBgvIATW6+lnRk4MfiKB6 ygJFoAa0gQEwBZbADjgDN9S6ASAU1TgOJINUkAlywXFwEpSCClAFLoNroAE0g3ZwB/SBATAMxsAL MAXmwDuwAr6BDQiC8BAVRA+xQtyQICQOyULKkCZkAJlDNpAz5AH5Q2FQDJQMHYZyoUKoFDoP1UA3 oFboDtQPjUDPoWloEfoM/YARmBJmgDlhIVgKVoZ1YDPYDt4P+8ORcCKcDufBJXAlfBVugu/AA/AY PAW/g1cRgFAgTAgvIoEoI3qIJeKC+CEk5CCSgxQjlch1pA1di4+RKWQZ+Y7BYegxPBgJ1JPGGHuM NyYScxBzFFOKuYxpwtzDPMZMY1YwP7FUWA6sOFYVa4J1wvpj47CZ2GLsJWwjthfdz3PYbzgcjgkn jFNCV7szLgiXhDuKO4Orw3XjRnCzuFU8Hs+KF8dr4C3xnvhofCb+NP4qvgs/ip/Dr5NRkHGTyZIZ krmQhZGlkRWTXSHrJBslmyfbINAQBAmqBEuCDyGBkE+4QGgjPCLMETbIacmFyTXI7ciDyFPJS8iv k/eST5J/oaCg4KNQobCmCKRIoSihqKd4QDFN8Z2SjlKMUo9yH2UMZR5lNWU35XPKL1RUVEJU2lQu VNFUeVQ1VHepXlGtE+mJkkQTog/xELGM2EQcJX6gJlALUutQu1EnUhdT36R+RL1MQ6ARotGj8aQ5 SFNG00rzlGaVlp5WhtaSNpT2KO0V2n7aBTo8nRCdAZ0PXTpdFd1dull6hJ6fXo/em/4w/QX6Xvo5 BhyDMIMJQxBDLsM1hiGGFUY6RnlGB8Z4xjLGDsYpJoRJiMmEKYQpn6mBaZzpBzMnsw6zL3M283Xm UeY1FnYWbRZflhyWOpYxlh+sPKwGrMGsBazNrC/ZMGxibNZscWxn2XrZltkZ2NXYvdlz2BvYJzhg DjEOG44kjiqOQY5VTi5OI84IztOcdzmXuZi4tLmCuE5wdXItctNza3IHcp/g7uJe4mHk0eEJ4Snh ucezwsvBa8wbw3ued4h3g0+Yz54vja+O7yU/Ob8yvx//Cf4e/hUBbgELgWSBWoEJQYKgsmCA4CnB +4JrQsJCjkJHhJqFFoRZhE2EE4VrhSdFqES0RCJFKkWeiOJElUWDRc+IDovBYgpiAWJlYo/EYXFF 8UDxM+Ije7B7VPaE7anc81SCUkJHIlaiVmJakknSXDJNslnyg5SAlItUgdR9qZ/SCtIh0hekX8jQ yZjKpMm0yXyWFZP1li2TfSJHJWcod0iuRe6TvLi8r/xZ+WcK9AoWCkcUehS2FJUUSYrXFReVBJQ8 lMqVniozKFspH1V+oIJV0VU5pNKu8l1VUTVatUH1o5qEWrDaFbUFdWF1X/UL6rMafBqeGuc1pjR5 ND00z2lOafFqeWpVas1o82v7aF/SntcR1QnSuarzQVdal6TbqLump6p3QK9bH9E30s/RHzKgM7A3 KDV4Zchn6G9Ya7hipGCUZNRtjDU2My4wfmrCaeJtUmOyYqpkesD0nhmlma1ZqdmMuZg5ybzNArYw tSiymNwruDdsb7MlsDSxLLJ8aSVsFWl12xpnbWVdZv3WRsYm2ea+Lb2tu+0V2292unb5di/sRexj 7HscqB32OdQ4rDnqOxY6TjlJOR1wGnBmcw50bnHBuzi4XHJZdTVwPek6t09hX+a+8f3C++P397ux uYW4dbhTu3u63/TAejh6XPHY9LT0rPRc9TLxKvda8dbzPuX9zkfb54TPoq+Gb6HvvJ+GX6Hfgr+G f5H/YoBWQHHAcqBeYGngpyDjoIqgtWDL4Org7RDHkLpQslCP0NYwurDgsHvhXOHx4SMR4hGZEVOR qpEnI1dIZqRLUVDU/qiWaAY0yB2MEYnJiJmO1Ywti12Pc4i7GU8bHxY/mCCWkJ0wn2iYeDEJk+Sd 1JPMm5yaPH1A58D5g9BBr4M9h/gPpR+aSzFKuZxKnhqc+k+adFph2tfDjofb0jnTU9JnM4wyajOJ maTMp0fUjlRkYbICs4ay5bJPZ//M8cl5mCudW5y7edT76MNjMsdKjm3n+eUN5Svmnz2OOx52fLxA q+ByIW1hYuFskUVR0wmeEzknvp50P9lfLF9ccYr8VMypqRLzkpbTAqePn94sDSgdK9MtqyvnKM8u Xzvjc2b0rPbZ6xWcFbkVP84Fnnt23uh8U6VQZXEVriq26u0Fhwv3LypfrLnEdin30lZ1WPXUZZvL 92qUamqucFzJr4VrY2oXr+67OnxN/1rLdYnr5+uY6nLrQX1M/dINjxvjDWYNPTeVb16/JXirvJG+ MacJakpoWmkOaJ5qcW4ZaTVt7WlTa2u8LXm7up23vayDsSO/k7wzvXO7K7FrtTuie/mO/53ZHvee F3ed7j65Z31vqNes90GfYd/d+zr3ux5oPGjvV+1vfaj8sHlAcaBpUGGw8R+FfxqHFIeaHik9ahlW GW4bUR/pHNUavfNY/3HfE5MnA2N7x0bG7cefPd33dOqZz7OF5yHPP03ETmy8SJnETua8pHlZ/Irj VeVr0dd1U4pTHdP604MztjMvZr1n372JerM5l/6W6m3xPPd8zYLsQvui4eLwkuvS3LuIdxvLme9p 35d/EPlw66P2x8EVp5W5T6RP25+PfmH9Uv1V/mvPqtXqq2+h3zbWctZZ1y9/V/5+/4fjj/mNuE38 ZsmW6FbbT7Ofk9uh29sRniTP3VAAQSvs5wfA52o0b3EGgH4YAHLir9zod0HQ4ANGn3g0UjBFI4BZ SAy9t7thVjgankBMkLsYI8wTbCiOFteDTybTJOAJL8lbKcop86mqiZM0NLRmdNn0/Yy0TPuYr7Ji 2DzZOzh5uI5yr/P68E0I7BXsF5YSyRN9J26yp0Lim5Se9DGZYTkqeV2FKMVypW7lKZUtNWZ1cQ0V TQMtG21vnSjddL1T+rUGXYaPjRaNt00ZzfaY61m47g20jLXKsC60qbCttWtGd/2A46jTc+fXLrOu C/ve719wm3Qf8ujyrPM6633MJ9HXz8/aXy1AIJAY+C3odXBfSE3osbCIcNsIpUi2yE3Sq6ju6KqY jFi/OJN48QTyhKXEwaT65JID6QfjDkWmkFIT03IOn0/vyHh9hJClnh2RU5U7fow8Tz0/9PjZgqHC rRN7TroW55xqKpkqpShTKHc/k322oeLFeUylRJXDhUMXL18aqV6v4bliXpt8teHapzrV+vwbH2+6 3nrUZNn8pFW9Lfp2TftkJ0WXXLfDnciejLsF94p7i/sK7mc9ONx/5OGxgWODGf9EDzk+kny0Mdw9 kjSqOPrt8dMnrWOl4weeuj/TfS44QZh4/2JksvFl6asDrz2m9KdFZ2hmvs++fTM+1//2zvzthdbF 1qWL7/KWY9+7fTD4KL5Cs7L6aeJz55fzXzNWA76ZrUmt06+vfZ/80b1RuZm+5ftTf5tvexv1Pw6w odFhPOhFIzpz6Dj0GpZDY68viDsyjkZNL7EROCKuGe9LxkY2QSgn96fQpdSgsiMGUKfQnKO9Q7fI wMioz5TAXMfykU2SncTRzkXB7cBzhXebX0cgVbBLaFNESTRI7Iz4wJ7PkoxSctLGMq6y/nKR8gkK BxQTlYKUXVXMVTXUpNX5NBg1yTR/aL3XntYZ032o16l/06DasMQoyzjOJMDU2czYXNlCeC+jJcby q9WM9YhNt2293Vn7LIcoRzcnE2c5F05XnOsH9KTvcKtyz/EI97Tzkvem9J7xafXN9/PzVw+gDXgb eDuoINg3RDWUOnQ2rDk8K8I5UhxdF0NR56JJMXqxjLHzca3xRxPcEqWT4KSnyXUHcg+GHrJP0U9V TVM5rJFunOGUGXbkSNbF7Ls507k/j3HkqeQ7HI8qOF54taj/xNti+BRHieJp69LQstzyq2eGz347 x3feqvJwVeuFT5ckqyMv36pZq1W5mnytsw7U69w43NB7C9to1JTVfL8V32ZwO629o+Nrl1C37Z2k nrN3b98b613sW3uA6ad/yDsgNajxj/mQy6OA4biRzNGTjyuf1I21j/c/HX829/zrC2SS4aXgK+XX 5lP+01Uzi2+E51zeZs5fWbi/OL20vkx8L/hB66PrSsqn4S9yX4tWv6zZrN/6wbKRsbn+M27X/xhA C8TAXpACutG4XhWKhpphGLaAz8EbiBvyEKOOacIqY3twVrhZfBIZO9l9wjFybwp1SnbKn1QzxAHq RpqLtCV0efRZDBmMmUy5zEUsFay1bC3sHRwdnJ1cXdydPLd5G/lq+c8I5ArGCO0T1hbhEwWiL8Sa xXP3OEjwSCxJNkqlSJvJMMlMy9bKxchrKRAUHiueUQpQlldeV+lUzVAzU6dTn9Co1AzSktXa1O7T KdDdryemt6Z/1yDf0NVI2OizcadJjqmDGa/ZO/Mmi5S95pZMltNWtdZRNmq2sO1Du0J7Fwceh3nH 604xzmousEu/a/4+2/1M+5+7lbnv9+D0eOl5xmu/N4f3hE+Jr4Mfvd8j/9wAg0CArpfYYJng5ZDq UK8wjrCn4UUReyPJIu+QEqPkopajL8a4xTLHPoo7Eq8Vv55QnxiYxJP0PPnEAbuDrAfnDrWknEhN SPM7vC/dOcM10/dITFZGdnHOpdymo33HxvLm8r8WIIX0RXwnpE+qFuudMi2xPu1c6lUWXn7oTNHZ qxUD5z5WClYlXBi+JFx98PL4FYna9KsvrsvUZdW/alC8mXvrdZNc85GWyTa52zntM53qXSXd33rs 7jb2CvddeCDR3zsQ/I/A0PLw/dEbT2rG65/dmXj5EryWnq5+kzmfs9T8gfpT1irLeuOm447/f/1H tlNwigBcnAXA4TwA1q4AVIsDIFgGAJEBACsqAOxUAKybD6DnpwFkdP3v/UEFhIEhmg0fQTPHfvAO IkIykD2UCJ2B2qEX0Caa32nBXnAmfAV+BH9F2BEdJAA5jrQiMxgKNMP2QDOyFswbLB1WCxuGPY8d w5HjdHDxuAbcMl4E74+vxi+SSZLFkHURKAguhKvkELkTeQMFkSKMYpRSmfIcFRkVieoV0ZTYSi1C XUpDRZNKs0YbjuYr3nSv6b3o5xlCGb4xpjIRmc4wSzHfZXFlWWUtYJNhe8wex8HJMcx5hEuXG3Df 4cngteBj5Vvgvy1QIBgkZCgsKEIpsio6IzYqfm9Pm8RNyXqpOukGmRbZbrkB+VcKn5Qwyowq/KoS ajLq0hpimjxadNqw9kedF7pdepX6WQbhhk5GusZSJlym1GaI2br5isXS3jnLGatp6zc272y/2G05 EByZnYSdVVwsXL33Je0/6VaP3mPvvYjecj7Ovof8qvx7A2YDt4LpQnhDxcIkwyUiRCP5SExRhKgf 0YuxbHEW8ekJXYk/kw0OFB18l2KRevuwfHprpsmR2ewjubxHr+dp508VFBQ5ndQ4ZXI6rqz3LPs5 YiVc9f3i5+oPNcu1y9c+1q3e2LpF1sTeItWm3+7cGdgd23PwXkrfgQexD0MGPYZyh1tGl8Z4n+5/ XvHi7SuZqdSZsTnx+azF+WWjD1c+0XxJWn2/7vdjfiti9/ygBpLAGsSAUtAF3kAUkCzkCqWjGf8A 9BHN7lVhDzgLroefIwiaszsjGcgN5DWGCj1VgjFlmH/Q/FsG64MtR/1OjTPHZeMe4MnxFvhC/ASZ IBmJrIfARAgh9JHzk6eRz1GYUrRRilNWUDFSHSXiiGnUgDqVBqHJoiXSnqLjo6uj16YfYwhlxDFW MukwzTBnskiwjLOmskmzTbEXcRhzYjh7uA5zG/JQ8ozzVvJF8RsKcAmsC44LNQufEzklWiCWJ563 p1CiVPKSVKP0A5lXsmvyjAqqit5KecodKh/VBNXdNco0X2hz6fjo1ultGBgY5hoNmGBNlcy8zDMt Lu29YzlhtWKDsWWyE7PXdnB2jHLKd77uMuT6aT+Tm4a7n0eBZ6fXBx9+Xye/fP++gK0g+eDAkLOh I+FwhGykBykv6nb0Qix1nFK8R0JuYkvS/AHmgyaHDqQ0pC4d5k/fn1Ga+SyLOds552zum2MSefH5 fQUsheFFgyeli8tKiKezyyjLT54Vrrh/PrCK8kLDJZfLmJr6WvdrNNfv1sc3SN1caKxuDmyVaPvc 3taZ1m3ew3x3trf+fnK/6QDr4PCQ/aPZkcTHXE+GxnOf2U4ITUIvZ173TdfO5s+R5m0X2ZcqloXf 3/iouTL02f3Lx9WUNer10z+4Niq22H7m7/qfGeiACFABHoFt1Pd+0GmoF/oC88E2cDrcDC8jvIgT ut/7MQhGE5OIacasYhWwsdgOHBZniSvDLeHV8MfxC2T6ZBcIZIQIwiS5OXk3hRLqaV3KQSpnqiXi QWpG6noaS5pPtMV0mnSL9GcYbBmpGB8yZTObs9CxTLBeZCOx63DQc7zj7OO6wJ3JE8xrx6fDLysg LMgtxC7MJsIjKi6mIm62x1MiWbJUqkP6jSxRTl2epHBd8aOygkqq6qi6iEa65lttc51mPXH9C4a8 RlUmoqaN5voWzywjrClt6u1c0f3a4RzrKr9v3a3b45iXm4+iH6X/88DSYJOQxbCE8M3IaNJctFXM zTjaeFLCkyTV5PMHKQ7Fp8ynOR0ezNDNbMuSz27K1Tjan+ec/67gYBHticpiqVOtpzVLu8rVzzRV YM+Znz9Z+fqC2MW4S72XGWv8rrRdJV7zud5ez3gjomHglgia+bxvsW5tvs3Vntnxocux+06P+N2T 97b7gu4/6dd+WDvI9E/U0MNh9pGA0auPl8b4xx2fpj27/PzhxNyLzZc0r7hfi08pTKvOaM5qv9Ge 03yrOq+0ILMotsT3jvhucbn1fdwHhQ/LHy+uOH8i/9T+2e8LzZeWr/tWwWrlN91vM2uH1jnWW7/b f1/5cXRDeKNn021zfavop9TP/m2fHf9H+cnJ7l4fEKUuANhX29tfhNCkohCArYLt7Y3K7e2tKjTZ mASgO+TXd5fdu4YGgPKq//b94/8AmJfCLqRoihwAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURB VHic7N17fBNV+j/wJ7Sl6SWFXilULMjFcukUqQgLiE7r8gJ1SUEQ1LArIgHxQtAVjK64lv3KhnVX ws9LQDTs2uKlLEtUrK6kxQJrQFIhdUktQQJrQFJJYVKY1El7fn9MW9pSek0yk/R5/wXpXJ5JO/nk nDlzRkIIAYQQQiiA+gldAEIIoT4HswchhFCgYfYghBAKNMwehBBCgYbZgxBCKNAwexBCCAUaZg9C CKFAw+xBCCEUaJg9CCGEAg2zByGEUKBh9iCEEAo0zB6EEEKBhtmDEEIo0DB7EEIIBRpmD0IIoUDD 7EEIIRRomD0IIYQCDbMHIYRQoGH2IIQQCjTMHoQQQoGG2YMQQijQgix7rFbrRx99lJGRIRGf/v37 Z2dnP/fcc3a7Xej3CSGERC1osud///vf3XffPWvWrPfff3/37t1EfH755ZdNmzZFRERMmjSpqKhI 6DcMIYTES0IIEbqGzplMpjvuuOPFF1/8wx/+IHQtnSsvL8/Ozl63bt3LL78sdC0IISRG4UIX0DmT yfSrX/1q//7906dPF7qWLpk4ceLPP/88ZcqUG2+8cenSpUKXgxBCoiP27Dl58uTcuXNLS0uDJXh4 iYmJpaWlt9122+jRo2+//Xahy0EIIXERe5/b/fffP378+HXr1gldSE+89957b7zxxtdffy2RSISu BSGERETUYw2++uqrQ4cOrVmzRuhCekihUDQ0NOzYsUPoQhBCSFzE2+4hhGRnZ+fn5997771C19Jz ZrN57ty5P/zwQ3i42Ls3EUIoYMTb7ikvL6+pqbnnnnuELqRXsrOzU1NTv/zyS6ELQQghERFv9mzd unXZsmUhcKVk2bJlb7/9ttBVIISQiIi0z+3KlStpaWnff/99SkqK0LX0Fn8sVVVVycnJQteCEEKi INJ2z759+2655ZYQCB4AiI6Ozs3N/eKLL4QuBCGExEKk2WM0GnNzc4Wuwmdyc3ONRqPQVSCEkFiI NHtKSkpycnKErsJncnJySkpKhK4CIYTEQozZc+HChdOnT0+ePFnoQnzm5ptvBoCTJ08KXQhCCImC GLPHarVmZGT06yfG2nps/Pjxx48fF7oKhBASBTF+vldVVY0ePVroKnxs9OjRVVVVQleBEEKiIMbs +f777/lOqlCC2YMQQs3EmD02m80n2VOxfXmrB4vmra+o8XZjfW9N+f7ybq3RgYyMjBMnTvhmWwgh FOTEmD3nzp1LTU31wYbqzgOozXa7zWazmotVp9ZR9xW4u7H+qewZ2ad8lD2pqannzp3zzbYQQijI iTF7amtrY2NjfbElBujRVHr6iBEjMibOWr6ShlLGCwBQ8/nmxibR6s0lfBp5q8vX52Xx7aPth86C 9+T6mdkAkD15dUV38up6ZDKZ2+2LDSGEUPAT4+TKbrdbJpP5YktxUPr17pIRCcDVnjn44opShV4b D3Bo832zV10oNNkm/rJ/zIzcY2AueSpxXUr2BrnGbNvl3PPH2VPS+lvP5q3R7ix9Z+n6RTdE+aCU 2NjY2tpaH2wIIYSCnxizx3ftHhnA1gWrTRSAxWIBgOH/O+X2wIZVpfllzgcnJwOMsBUaR2oOnKMj NwBlem/NRBnAU5u17xRoPj537Gk6EXZPnzk53hdvEmYPQgg1E2n2+Kjd4wBKxxxbzm/r7KEtaVPk pfcdBoDmA0+bOB0s5dX14wAeGt24z6ghFIAUwMsBAMcBSH1QSnh4eHh4uMfjkUp9sTmEEApmYrze Exsb68NLIxFN/xiSNYEGsLsuMwADBjZmj+O7A0CNS24AgIrzTcMKLjharB4BPuH1er1eLwYPQgiB OLPHd5fl48BS+U1FZUVFRUV5yfq7p5SCnL41ayENq17Un/aAt6b89QUF1PxbBg8dT0HBlo/KvQBn 929dUQor6VHAAUBp5YlqX1Tiw45EhBAKemLsc/PZpZFIGcCmGdSmxv/SKqM9P1MqG1NQdiBtxrCo VQAAco3t2dtBCrsM+SPl2ZseAgBQ6kxLM2XgHTCFgoeou0Ywxyb3ugvQdwMoEEIo6Inx2XFTp059 9dVXp06d6s+deKrPujiIShlydSSB113jdLMRUQnJ8c09Y16PB6RSHyS01WqdN2+e1Wrt/aYQQijY ibHdM3jw4J9++snPO5EmDxnS5qVwWfwQWXyb13x1geann34aPHiwb7aFEEJBTozXe0aOHPn9998L XYWPVVZWjho1SugqEEJIFMSYPTfffHPoZU9ITs6NEEI9I8bsCckpnzF7EEKomRizZ+zYsZWVlQ0N DUIX4kvffffd2LFjha4CIYREQYzZk5CQcOONNx4+fFjoQnyG70IcMWKE0IUghJAoiDF7ACAnJ6ek pEToKnzGaDTm5uYKXQVCCImFSLMnNzfXaDQKXYXPlJSU5OTkCF0FQgiJhRjvLQWAy5cvDx06tKqq KikpSehaeuvKlStpaWlVVVXJyclC14IQQqIg0nZPTEzMvHnz3nnnHaEL8YHCwkKapjF4EEKomUiz BwAeffTRbdu2CV2FD7z99tvLli0TugqEEBIR8WbPbbfdFhkZuXfvXqEL6RWz2Xz+/Pm77rpL6EIQ QkhExJs9/fr127hx4xNPPOH1ejtfWpQIIY899tgrr7wS4aunACGEUEgQb/YAwN13352env7WW28J XUgPFRQU9OvX78EHHxS6EIQQEheRjnNr9u23386ePXv//v1BNxHnjz/+eNttt3344Ye333670LUg hJC4iLrdAwC33HLL66+/npub++OPPwpdSzdcuHBh6NCh69evx+BBCKFriT17AGD+/PkqlWro0KH7 9u0TupYuOXbs2NixY1944YWlS5cKXQtCCImR2Pvcmn355ZcKhWLJkiUzZ86kaVoikQhdUTv279// xRdfbNmy5W9/+9vixYuFLgchhEQqaLIHAM6dO6fVavft21deXs5xnNDltBUREZGZmTlz5szly5cP GzZM6HIQQki8gil7/CEqKqqmpkbqqydjI4QQ6oIguN6DEEIoxGD2IIQQCjTMHoQQQoGG2YMQQijQ MHsQQggFGmYPQgihQMPsQQi1Ul9fP2/ePIlEkpOTU1dXJ3Q5KDRh9iCErqqvr1+0aFFdXR3LssnJ yXl5eRg/yB8wexBCjfjguXLlyq5du6RS6Y4dO+Li4jB+kD9g9iCEAFoHT2RkJACEhYVh/CA/wexB CLUTPDyMH+QnmD0I9XXXCx4exg/yB8wehPq0joOHh/GDfA6zB6G+qyvBw+PjRyaTzZ07F+MH9R5m D0J9VNeDhxcWFvb+++/HxsZi/KDew+xBqC/qbvDwMH6Qr2D2INTn9Cx4eBg/yCcwexDqW3oTPDyM H9R7mD0I9SG9Dx4exg/qJcwehPoKXwUPr4/Hz9mzZ//0pz8tWLBAJpNJxKd///5jx45dunTpkSNH hH6r2ofZg1Cf4Nvg4fXZ+Hn77bezsrIuXrw4d+7cn376iYjPL7/8UlhYmJ2dPW3atBUrVhBChH7P 2pKIsKZAioqKqqmpkUqlQheCkB/5I3habvyBBx6ora3917/+5fONi9Cjjz76xRdfFBcXjx8/Xuha Oud0OufMmZOcnLx79+6wsDChy7kK2z0IhTi/Bg/0sdbPK6+8UlBQcPz48aAIHgBISUk5cOBAXV3d U089JXQtrWD2IBTK/B08vD4SP7t37962bZvT6ZTJZELX0g3h4eGffvrp4cOHt2zZInQtV2GfG/a5 oZAVmOBpubsQ7nzzer3jx49/9dVX7733XqFr6YlDhw7NmzevqqoqJiZG6FoAsN2DUKgKcPBAqLd+ Xn/99WHDhgVp8ADA5MmTc3JyNmzYIHQhjfpouyczM/PUqVNhYWEMw8TFxQFAQkLCd999J5JvBAj1 UuCDp+WuQ6/14/F40tPTDx48OHLkSKFr6Tmn0zlmzJiTJ08OHDhQ6Fr6arvnhhtuuHLlCsMwAMAw DMMwsbGxGDwoNAgYPBCirZ9PPvlk3LhxQR08AJCSkkLT9Icffih0IQB9Nnueeuqp2NjY5v/KZLLn nntOwHoQ8hVhg4cXevHz9ttvL1u2TOgqfGDZsmVvv/220FUA9Nk+t/r6+sTExEuXLvH/jYqKunDh QlRUlLBVIdRLYggecRbTG2fOnJk0aZLD4QgPD/f5xj1uj1Tmo7FOXo8bpLLOahw5cuSuXbsoivLN Tnuqj7Z7wsLClixZEhERAQD9+vWbN28eBg8KdmL7rA8LC/vggw+io6PnzZsX1K2fkpISmqavFzwV 25dLJJLNh6qbXnBvz5PkbanoypZrDm2MittaA1CxJU+Ss8UN4K7Y0mpunKzFOyuqO97IyY/X563e 6QbwOj6Ni1h9urOd/vrXvzYajV0pz6/6aPYAgFKp5P+YoqOjV65cKXQ5CPWK2IKHFxrxYzQac3Nz r/vjuisAsGrKKye9TS8wcKqO68KGT+dPWas1L4kHAGDgwtUf6E1Wm9VqtZp0OZYF1NMVnutuwnt6 50j5OsOxC16A8PT5xapNczaXd7zX3NxczB4hjRkzJj09HQBkMtnUqVOFLgehnhNn8PBCIH46yZ5G m5b97VDzfxIBAMBbXb4+L0sikUgkedsPnW2zwsmdf9hEaRdPvPY2VXl2VsaIjIyMjMnLn18PUFBe 8n5e1upDNfxP3TtX563eUQkAAKfXDVsAABAHfKPsLlWRZVV++fWzCgBomi4rK6uvr+/siPyr72YP ADzxxBPR0dErVqwQuhCEek7MwcML6vix2WxRUVE33XTT9RdxgLzQatKWrp2ys7ntAwBwel1K9jp4 yGyzFWtlS6ak7ah0t/ip51BBAbV0enw7GzxV7fJ4PR6Pp2b/rj0AdObU8TLLpneNJwEAao6u32TI yEwDgJLnh21QFZkKFXCqcc3w9KlqMOw9XtPBESUmJo4ePbq8vJPmkb/16exZvHjxlStXlEql0IUg 1EPiDx5eF+LHvXP14tXPL5dIJJK8jSc9AOD+fONiiUQikSz+uLKjD1O/OnHiROdDq0+5h01eWaiA BfPedEME/2twV3y+ASjTe2smjhgx66nNWgo0H59osQ7nPgVUUnR7m7PkpkVFREVFRSXMWLFVqdtA DcxcooatBfs9AKf3F1hA/ZtM2dmS9bkbFLbX5if94gaAiMZ1ZaNp+PzAqfY2e9XIkSNPnDjR8TL+ 1qezJy4ujhCSmpoqdCEI9USwBA+v0/i5UFKwif21w2XTnFr7zn+qT+9cOXvtaBvD2opHy8c8Vem9 do1AqKqqGj16dKeLcRD+4N+MlGXVho+P9U/jr93UATw0urFHLWoIBdB6OFsdwKTMtHa3VmSxO+x2 u93mcLJblk8OB5j6gA4M/zjucR98dyute2CIp3Jt7jpQy7mT5Xu/NoClcl95pdvbuNlOjR49uqqq qgsL+pHvhwz2Xr9+/UJy5LdEImloaBC6ChQifBI8nppqF8sBRCQMSe7iOF+vx+OFcKm0Jx8dfPws WrRo3rx515TtrUukjfnzh8hgzkp6zMHv0ncWaMzMCJkUZqm0VNxXtrczMgSYd7GqqiojI6NLiybn fKhXjJFPAQD5dAAOACrOeyE+HADgggNgUqvFIwHKv3dC5rXXe+ibRqUPaX2s0sxZaljx3lb9MQOo 3hwDYI2mgNqzYEzjFDmbZmf/bGbea+fiUXtGjx792WefdWlRvxFju0fABy75m9BvLQoRPgge79nt q3OiElLS0tLS0lKiJHk7K/h+Lff2nBZDhN0Vz2dJJJLl5TUA3tNbFmdFREVFRUXkPL/jbI8aIh22 fuL4jqMrdUBFRkAiSBs7krweoBKjhPmiXFVVNXbs2C4unPGwJp+/baYOZEPHU1Cw5aNyL8DZ/VtX lMJKelSLZSNkw8F09lK72+HaGSWXPl8n37RqValcRw8JB2nmlmPk2DFCCGEtWgAtQ/jg8daVwqzp wzuuc8yYMYK3e8SYPQihDviixVO9ZWbakk1QWGZ1MYzLYdEpTy2gErZXuAGgDpqGCLsrVsdRGywK k3PLxHjv5+uGrSi4x+JiXTZj3IaH/rK30ztJ2te1oQfRU/PoVe9/AwCek8VrLYk3DfJL9ly6dOmR Rx7p4ML7pUuXOnliQmRc47A2AIAhz35YCACyyAhIztllyN/0UHaERJI2Y5VSZ1raqokjnXy/wlJS 2TQkreVG4qIj4FrUrEcoAPWKWW2q4QCg+T7R6m9XAdwwoJO7FePi4prvrBeM0C2Bdoizqt4L1eNC PpSVlUVR1IcffujxeNpdwOv1zp8//+67777eAl3hLNMAQKGNbfmalgZQFLKE0dFA66yEtSgBAFQW hl+ALVRAvtHJ/1tPA2hMPS6AtHMgLi0tL2MIIcSipWmtmTDm5lFA6iJrb/bVgR07dsTExMTExNx0 002bNm26cOFCmwUyMjKOHz/e4+1zjMvhcDhdbDs/Y8w0QJGd6/HGr2XR0qAwdLrFc+fODRo0yIf7 7QExfhqG6md0qB4X8qGkpCQAiIuLi46OXrJkyeHDh1v+1CfBQwgxa2mgtK7WL1p0cqC0LsLoaACF WkkDgMLMtLO6tUgNAHqLq52fdUcXDod1Op0uxpefzm0UFBQ0N2uio6MjIyPvvvvu4uLi+vp6foEb brjhzJkzftq7rVAO8qL2cqlHGBMFYHB0/na53e6YmBhf7bZnxDjWAKE+SyKRAAA/w/o//vGPjz76 KCEhYeXKlUuXLk1OTl60aBEA9H5UW3RcGkBkOye/5SfGC5FxAAUbtgIAFLz3xQsT57e60l5zaPOY BRvUBtvDme3dmtIdzUMPpk2bduzYsX5NJBJJvxY6/m8vlz979mzzCKArV64AQHFxcVlZWW1t7Xff fTdu3Lja2tqW8w771ogH9abUU1zbEXA95PVEv2ay5wzp/FM9JibmypUrhBD+700QmD0I9YqvhmX2 69evoaGh5SN06+vrL1++fPny5T/96U9qtZoQ0q9fPz6WeukK4wDLJQ9AyysHXB0DVGpCONQBAK1x lDxd+Xx27oKFtN08J735g8L9kXIV5BtfmTOi92U0GzRoUE1NTURERENDQ0NDAyGkoYWO/9vL5ffu 3dvmqntMTAzHcb/+9a/5h9x4vV5/jl+Pn5zT2whvFp6cmZPcpSUlEkn//v29Xi8/p6UwhGpwdUCc VfVeqB5XH+fbX2ty8tUPj7CwsJiYmKFDh/75z3+urq4mhHi93vvvv3/WrFm97HPjr/foLC071Oxq ACq/jDRe77EQQghrVQIApXFcXYwtzlcb7L7pJfJVF2JvvPvuu/yDu6RSqVQqnThx4rvvvsswV9+Z 1NTUs2fPClWen7AsGxkZKWwNOM4NIRHh+39kMllMTMzvfve70tLSM2fOrF27lr8OFBYWtmPHjri4 uLy8vN5MTpN8+xINBSuo6dv3V7o9npqz5Rtzhm0A+vUVt/MLXODHuUkz/mzWgWXtys1XZypLyRoN F9ztbrZbRHJj7MCBAy9fvjxkyBC1Wv3999+bzeYlS5a0HNgWGxtbW1sb+MLKN2ZJ1h/qfLkecbvd nQzeCwBho69d4qyq90L1uPo43/5aJ0yYMHXq1I8++qiDpoBvWj+sTats8QQXSmlsbM0wOhrkfLuH EEJImUYOAEW2pp9SQGnNPd8vIUQcLZ5mR48e7eCnt9xyi9nc2+PtAae1rMzi9NPGf/jhh2HDhvlp 410kxk/DLp7MrMvpcDicrvYG4nRldYb14+iZ9mD2hCRBfq2+6nxjnA673W53OAN5LogqeDp1++23 79+/v3vrcE6DpnF8uEpfxoe2y1qspAEAaKXW4uIIIdYitVKj1yjg3uc3yimVqXHYIFOkkqsKrTaD Jr/ISgjhnCa1nAIAoBRFZgchhLB2vUrOv1JoclyniI58991348eP78GKPhScfW7e0823ZKckxEny NlbUdOse65rty7Oi4qLerDi5PUuyvlywaQoR6hlfdb7Jkoekp6enD0kO2KAjkXS1dd2wYcNsNlu3 Vqkue02+9nyxxWYxajctmZG/vwaqS+4cM/sEXWSxlk05sYq682/VANyF41vXLlkL+cvunXztNNWX 7IXrfrgEcHpdypQN8JDZZtFPKViQ/ZeT3potdw9bUjLcaLEYHoKHpqTtPN3tGSZOnDgxfHgncx/4 nbDR167OqnJqaQBQGMx2hmWdtjI1BUBpu9E65Sw0QL7RQQhnLTNaXQH6zifOdxv1koC/Vl+1fgIm uFo8vPXr1/ODDLvOqlcAKIotDo5wDovJYndZdHKAfL6FwtqLAMBg5yw6Gmgd329jVAPI9SwhdoMS QO0gxKylKY2ZsegAoOmOXotakf/NUT1c7QJ15EOrDtIu0mg0zzzzTHfX8q3ga/fUlL+/qhSKbPo5 E9NlUmnyiNvzPzbQcOonNwDUfL55Of+o2dWbS9wA4D25cXHe85s3Ls6SSCSS1dsPecG989lVpQDr Vq/9/HTN2a/3Vrm8AHC6ZEueRCLJytu4ef3y5ZtPe6Fyx+rVOxpntarcsXr1jkrwnty4ePHGLZvz JJLN5TXgOb19dR7/XNsd1zwYCiF/41s/Mpls7ty54n8uTtC1eHg9mPI54741+fKC2VRahCRC8foh LloGIANYlyaRSCSSqGELAMB+geXqgJo1ib/i33aa6qsbqwNQZ/CDH6WZr7z34vh+AAALRkZJJBKJ JG0dAHTpGamtdHFybv8SNvra1XFV7d6SzTNpaQCq0GSzlukBgJ+WQw4AALrismKdEgD0VtZm1AJQ WkOZk3XpKNCYXIxFDwAKXbHZqAcAALmJIWYt1TxrSOO/m7am0ugtTqeOBqBURovFoFFAF+bGEOe7 jXpJ8F+r1+tdsGDB7NmzxdyYCMYWD+/bb7+dMGFCt1Zh7Fabk+UYp6WsSAlAacz8p5aT4xiGZV12 Y3GZk2ts2TStZFcDqLRaumligsZ2j1kLILfwHy2sTZevO/YfLQBldLAcw7AsYykrNtu7fc37jjvu KC0t7e5aviXGT8OOT2aLjgbQtJM9rEUOkF/W2PdmK1QApWVYsxxAXewghBDOKgfQml2Es9BAm1lC CKOlQGN2mTUUKIv436/LpAGgzUyrvwwL/2/WLAdQGeyEENba7Zav4B9SyB/E8GsVefwEb/AQQurq 6mJjYy9evNj1VUz5AJTWwRFCXIUKoDRmZ1k+AFVocRLClmlpALm1bfYQs04OACBv7IVr/KmrjAJQ FZpZwpRpaQClrcYsB5Bry1hCnGY9AGhM3ZvcqAdH5A/B1+cGkXEA0Orimvf0js1bKqr5CWEbL5qm TZwOlv86vcAApKbJAADC02ZT4AEALwetZimv/abQQo27iV8zPHrAtfus/qmU/wcDMHx4AgA/eWxv W74I+URYWNj7778fGxsrws63IO1qa9a/f/+pU6fu27ev66tkLzXKLavSIiQSScJDBYrXFo5Nvv3Z Ys3wh6gUiSRqxqpSvfntjHBoM6NAm2mqG38af/vHxZpND2VHSeJmrCrVGp8fMXDi2yadYdWMKIkk JXuJXGN8enL3Zkb4+uuvx44dO2BAOx90gRR8c+qMmpIHsGRXxWPLmyYkP7t3y0Or9pjm6hmAAQMb j8jx3QGgJqXw/+Mao+o6J6U0PQcsl5qSg2uxVOPzQ9wn9kDi0qYXOS8AcBwDQBkdh2bIOG8EnPjm IHdjy4dzIBRQfPw88MADc+fO/de//iWST/lgDx5ebm6u0WiUy+VdXD58SM5uwp49fZ6LiB7U9FC+ WWt2s8uqXV6QxSfLwgEAMp8qOdZyrfQ5x1pMztT80/RZawj7WLXbK4uP55/Ylzx5OWEfPOvyRMni 42Xd/gw3Go25ubndXcvngq/dI824R0vDCkq+49BJt8d9cv+WtNkbQLk+e+jwhTSselF/2gPemvLX FxRQ82/p2p274WOmKWGdcmdFtaf60O+zVwHE8UFkeWf3Sbf3dMlbKywQ13od2ajpcrBs3vmNVyZz H/8nNWP23p8EeqgvQgAgvtZPaAQPANx5553davcAAIB0SHp6euunwUrjk4ckJ3c/LACksuTk+FaP ipXKhgxJ7kHwAMC+ffvuvPPOHqzoY8J2+bWr86oYq0Zx9ZZseX4Rf5GHc5Qprr6qsbGEsBbF1Xmr GB0FGrOLsGYaaBPT+IrWzBDCFGsaV6UpAFDbOMLYDHTjtmgFBXKtmd+atmkWLKdJ12Jvxk5Haovz 3Ua9JLZfq0iu/QT1NZ5rjRw58uuvvxa6Ch+orKwcNGgQxwX4xvp2SIj4HuQskXSpKndNtZvlIqIS kuNbfrfwVJ91cRCVMiS+618Jqis+//JUyrw5E6UA1fufT5mRypCnZADgdVfXXG3qtsPj7nrL93rH Zbfb33nnnT/96U8mk2ny5MldrhqJQhf/XAOpvr7+gQceqK2tFarzLWRaPM3+8pe/WK3Wd999V+hC euuZZ56JjIx85ZVXhC5EZF/ZeIGvymXWAIBcrSvUqQBAWdjte7W6os1x1dbWbt++feLEiVKpNDIy Mjw8fNOmTf7YL/IrcZ5EArZ+QqzFw3M6nQMGDLh06ZLQhfSKx+NJSkr64YcfhC6EkKAc5+YH8RPX OCzG2QOd31RGFZbZtzyY6b991dfXf/XVV4sWLUpKSnriiSfKy8s9Hk9dXV1YWJj/dor6GqGu/YRe i4eXnJw8d+7cP//5z0IX0itarXb69OnCz6YDAACi6y4AUXZi+AR/XD/++OPQoUPDwsLq6+tb/jQy MrKuro5/gJhQFfpP8+9UIpGE2AGK+c81wJ1voRo8vPPnz48bN+7rr78eNSooR7SePXs2MzPzyJEj IskebPcE2uDBg/ft2zd//nypVNrmWbybNm1qfkp8iOEfFskT6p33EwGfOtypQLZ+Qjt4AGDQoEGr V69++umnhS6kh9auXfvII4+IJHgg9LLHW3PyUPlJL4C7fKNEsrEHM1R7Yjc+0AAAIABJREFUKrdL JHnlbgBP+WJJK6u3H7ruMGr3ye3rl+fk5OSt3lxe3dFg67CwsDvuuOODDz74+eef33jjjezsbP56 T/crRaIg8jQNTPyEfPDw1q5dy3HcsmXLhC6k25YtW3bq1Kn169cLXUgLwn0Vvq7eVMVZNAAalhDO ZTUarT0YSMhYdPycOo0z6BSabDar1Wo1FuZD8/Q8bTnyAYBWF5cZNXIAUNnbW+h6x2W321988UUA MJlM3a83yIjzT643guKI/Dr0ICQHF1xPbW3trbfeumTJkitXrghdS5fU1dU9/vjjACC2gRJiPG3a OZk5m0YhV2sb7+pR6U18qFgNWv4WHEquNjk41lrE/5dWFTptBlW+wWktuvahTIRw5sJ8/mFMKp2x zTx8LbOHBtBamh9Nz+lpoDbs1ipoTXFjuDiMGlqpryrLB1Dam0rV5ets7T3PPig+pPwt9N6EYDki P8VPnwoeXl1d3ZgxYwBg9+7dgs+K1oFLly7t2bMnIyNjzpw5brdb6HLaEuNp087J3N501JytEABU hWV2m1mrAJDr3YzdoFUCKAwmW41ZA6B1sRYFgLLIRgjhZ+XTWRhbkRIAtAaT2aiDa+YAbdPu0ZQ5 CMeyLOswF1IAauPpYhUArWcIIYTR0wD5RrNWDiDXaFQUgFyptVxnZr9g+ZDyq9B7E4LoiHweP30w eJp98cUXubm58fHx4hyhGhYWFh8ff+edd+7atUvot6p9Yjxt4NqTub3pqDmX1WAwMYRwrMuoaXyw AmfVAuhYQhiLFkDLtPNQJpeWArrpgfNmnbzNExlaZo+ize9TrrGxhDFrAagyV2OYFdpYi04BAKDQ GIqLVBQAKK3Y7rmO0HsTguuIfJgWfTl4UO8FzViDa6ejDg+POFeqjpNIIqIScteWQmJkOADLQZsJ pds+lMnz4zcWKF2VzQ8fyF5hgMTrXhp1A6gNFv6R9na7k9u9ZoQUZBPvUYGl+Nvq6kO7LJD/6xFS ADdAvuO9NXNmzX9tn5GCrR8fx+dwIzEKCwv74IMPoqOj582b15uhB31kcAHyn6DJHoC201FX/vOZ FZtGldmdHCGOYhVcaP9EkmbOUkPpe1v12wyg+s0YCI+OBlAWWTmOZVjWaTUVv3zH9aYcZQBShw/j H2mfnt78TPsRizT0Br1er9sk1y9IBuDqGKBSGjciSx4OMCAi+CYIR31E7+MHgwf1XlBlT2tcHQAk 3piW7D176OXZmyARPMA/Vucnp7vlKOf0+Tr5plWrSuU6ekg4hKffo4St6z8+zUplnP21MVNmF9g7 CgqunQHT2fethIK1aw3UU/dkAMDYmb8Fy4q3Pq/0gmf/OxsNIJ86qmszaCMkhN7EDwYP8olgyZ6I NIDIpsYE//c+6q5HaNgwLEISlTYlWq2E0lV3bS6PGDAEYMPIuDcvAkDTVNetH8oUPudVixrWjoyT SOLGbKDyrdpZrfYUEQlND0yIa7HTlsJH3KGhARRrJyUDAEgzFGa9au3sMRGSqBkrCrRGbab02pUQ EpGexQ8GD/IVMU4H0o1JSrzuaqdHmpAsk4LX7fZGyaTh4PV4vOHh0vCOe728NdVOb3iPHr103Vpq ajzecFnrabVbEPPkKwETem9CUB9Rt7IEgwf5kBhPm6A+mTsQqsfVLaH3JgT7EXUxUTB4kG8FS58b QsgvutL5hsGDfA6zB6G+ruP4weBB/oDZgxC6bvxg8CA/wexBCAG0Fz8YPMh/MHsQQo1axo/H48Hg Qf6D2YMQuoqPn8jIyKioqJMnT2LwID8R4/DQYB+0ej2helzdEnpvQugdEe/y5cspKSmXL18WuhAU mrDdgxBqR319vTifDoBCA2YPQqgdmD3IrzB7EAplNeVbcpbv9AAAeD5enbelvMZbfWh1jkQikSxe /3ENANSUr8/LkkgkWYs3n/ZcXRGzB/mVGLNHErqEfmtRnxM/fFTp1jePuQE8xzdtOjVqOLshZUqU ysqx9syd8qd2VFZ+9Pt1svUcYddHr5qztaJ5Rcwe5FdifMxMQ0NDwPYllUovXrwoleK80yhExU/V 06WGozVjY/aU0qs/g8rVAA/VVn32b0jJoSwnL0WMGQUF8nXTi+RP2A6MGdG8HmYP8isxtnsQQr4j nblGtWFX8Rc7dypVNLh+sgAt/cXlcrkga/WLM4eOmK+1mooHVhqmUCMXv4PtHhQgYmz3IIR8aMi0 RfLZUxYAbWLSpVGMHEqHzSyZMwT2b8z5a112/3fTTAtdr7w2a8lvhqboT8HyTH4tzB7kV309ewgh eBkGhThZ9iNKMFxZmSUDgMy/GtQj0/i/ebWVzRw0QSefkrCBArCAzuRsXgmzB/lVX88ehPoA1nUC 8jfk8lc1R8x5hWOfrWHDGx+cOHk5Ye8/62JlCUNkLa57YvYgv8LsQSikeSryoigDrXNNjm9+LVwa n9xyeI00fsiQ+DbrYfYgv8LsQSikSce8xzARMll3h3Ji9iC/wuxBKLSFy2SyHqyG2YP8CsdYI4Ta gdmD/AqzByHUDswe5FeYPQihdmD2IL/C7EEItQOzB/kVZg9CqB2YPciv+ug4t2PHjh0+fBgAGhoa 3n333fDw8FtuueXWW28Vui6ExAKzB/lVH82eCRMm9O/fPyIiIiIi4tlnnyWEXLlypb6+vl8/bAgi BIDZg/ysj37U/vGPf5RIJJcvX2ZZ9vLlyxzHqVQqDB6EmmH2IL/qo5+2S5YsaTmFaHh4uFKpFLAe hMQGswf5VR/NnhtvvDEzM7P5v+np6WPGjBGwHoTEBrMH+VUfzR4AeOqpp2JjYwEgJibmySefFLoc hMQFswf5Vd/Nnnnz5tXX1wOA1+t98MEHhS4HIXHB7EF+1XezJzo6eu7cuf369bvrrrsGDhwodDkI iQtmD/Krvps9APDYY481NDQ8/vjjQheCkOhg9iC/6qP39/CmTJny7bffjhs3TuhCEBIdzB7kV306 e8LDwydMmCB0FQiJEWYP8qs+3ed28ODB5ORko9EodCEIiQ5mD/Krvps9Bw4ckMvlW7duXbRo0d69 e4Uup6/AySOCBWYP8qs++kFw4MCBvLy8jz76aO7cubt3737ggQcwfgKjoaFB6BJQl2D2IL/qi9nT HDw5OTkAMG3aNIwfhNrA7EF+JSGECF1DQLUJnmYHDx7My8t7//3377rrLqFq6wskklD7kwuxIzpy 5MikSZPi4uL4FmpUVFR9fX1BQcHs2bOFLg2FlL7V7rle8AC2fhACAIDExMT+/fszDFNbW1tbW1td XV1XV9dy4l2EfCKkvrJ1rIPgaYatH38LsVYChOIRZWZmfvfdd83/TUpKOn/+PA4SQb7VV/6euhI8 0NT6WbRoEQ68Rn3WypUrY2Ji+H9HRkauWLECgwf5XKh9ZWtXF4On2cGDB+Vy+Ycffpibm+vv2vqa 0GslhN4R1dTUpKam/vLLLwAglUqrqqqGDh0qdFEo1IT+15nuBg8ATJs2zWAwLFy4EFs/qA+Kj4+f MWMG/++JEydi8CB/CPHs6UHw8DB+UF/22GOPxcXFyWQylUoldC0oNIVad0FLPQ6eZtj55nOh10MV ekcEAL/88ktsbGxYWNilS5f69+8vdDkoBIVsu6f3wQPY+vGDuLi4ixcv4uwGIte/f/+ZM2fOmzcP gwf5SQh+ZQMfBU8zbP10188//3z06NFjx44dO3bM5XJdvHjxUpPa2tqBAwdevHgxJiZmwIABAwYM GDhw4IABAxISEiiKmjBhwoQJE5KTk4U+gm4IyXYPQv4WgqeNb4OHh/HTMY7j9u7du3//fj5yLl++ PGHChKysrFtvvTU+Pp5PF15cXBz/Ye12u/k04pPJ5XKVl5cfPXr06NGjUVFRWVlZWVlZ06dPnzlz psi/eodk9lRUVPz+979/+eWXp0yZInQtKDSF2mnjj+DhYfxcq66u7t///ndRUdEnn3ySlZWVk5PD R056enpvNnvmzBm+zVRaWnrkyJHf/OY38+fPnzVrllQq9VXlPhR62WO1WnNycp5//vn169fv2bNn 0qRJQleEQhEJIfv3709MTDQajX7a/oEDBxITE/fu3eun7QcRg8Hw4IMPDhgw4I477nj99dfPnj3r px2dP3/+zTffzMnJiYuLW7hw4c6dOxsaGvy0r54JsZPo+PHjqamphYWFhJBPP/00OTn58OHDQheF QlDonDb+Dh4exs+ePXsmTpx42223vfXWW+fPnw/Yfqurq7du3Tp9+nSKogwGQ8D226lQyp6WwcPD +EF+EiKnTWCCh9dn4+ff//735MmTx40b989//lPAMj7++OOsrKzs7OzPPvtMwDKahUz2XBs8PIwf 5A+hcNoEMnh4fS1+Dh8+PGPGjJtvvvmDDz4QQ5dXQ0PDzp07x44d+6tf/ergwYPCFhMa2XO94OFh /CCfC/rTJvDBw+sj8VNXV/fSSy8lJycXFBTU19cLXU4rDQ0NH3zwwaBBg9Rq9ZUrV4QqIwSyp+Pg 4WH8IN8K7tNGqODhhXz8OByO7OzsWbNmnTt3TuharsvpdM6ZM4eiqDNnzghSQLBnT1eCh4fxg3wo iE8bYYOHF8Lx8+2336alpW3atEnoQrrkrbfeSk1NPX36dOB3HdTZ0/Xg4WH8IF8J1tNGDMHDO3Dg QEJCghgq8aH//e9/APD+++8LXUg3rF+/HgD2798f4P0Gb/Z0N3h4n376aVJS0jfffOOnqlAfEZSn jXiChye2enqpvLw8Ojpa2MFsPfPvf/87MTHx0KFDgdxpkGZPz4KHh/GDei/4ThtxftCLs6oesNvt Q4YM+fzzz4UupIe++uqrlJQUm80WsD0GY/b0Jnh4GD+ol4LstBHzR7yYa+ui+vp6mqZffvlloQvp FY1GM3XqVK/XG5jdBV329D54eBg/qDeC6bQR/4e7+CvsmEajmTlzptBV+IBcLs/Pzw/MvoIre3wV PLw+Hj8XLlzYv39/VVWV0IW0r76+Xgx3411P0Jw2wfKx3nGd1kK1QqWWAwAoim0sIcRWrAEAACrf YAlspW25XK6kpKTjx48LW4ZP2Gy2hIQEp9MZgH0FUfb4Nnh4fTN+ampqli5dOmDAgNtuu23UqFGB nYOzS/r16xcdHT1x4sQtW7aIM4GC47QJluDhdVCtRUcDqCxOp1FDg9rI2YsAqGIbw9iLKYBCGxv4 aputWbNm1apVAhbgW88999yTTz4ZgB1BkGSPP4KH19fi58SJEwkJCStXrqyrqxO6lo7U1dUdPHhw 6NChABCY72HdEgSnTe+Dh3U5HQ6Hw+Hs+kc7x7Isy/V4j9er2ayRq8tchBDWqgPQHNDSkG9q+hEt 11t7vMde8nq9qampVqtgBfjcqVOnEhMTA/DpEBTZ47/g4fWd+Dl+/DgA7Nq1S+hCuuGNN94YPHjw Dz/8IHQhrYj9mdm9fR6P9+z21TlRCSlpaWlpaSlRkrydFTUAAODeniPJ21LRuJi74vksiUSyvLwG wHt6y+KsiKioqKiInOd3nPX2ZLfTp0/fvXv3/fffX1JS0uZHUf0BADiuDkAaBkBFRvCvcwCDEqJ6 sjNf+Oyzz8aMGZORkdG7zbi350kkz3/e+J5Vl+RIJIu3N77J7ootEknW5+29oe7yjRLJxhoAb83J Q+Une/SWtzVs2LDbbrvNYDD4YmPBjX8ez1//+tcHH3zQT7u45557tm/fPnv27CNHjvhpF2Lw008/ zZ49u7CwcO7cuULX0g0rV6586aWX7rrrrvPnzwtdSwtCh19Het3icepoAKALy6wuhnE5LDolBQB6 C0MIo6OB0poJIYSxqAAAFCYnIYQrVgOA2uJiXTajHEBVbPdh/WaNPN/kIoQwFi2A9qxFC5DvIIRw VgWA1sL0eF+d6vg76Zo1a3xycd6skwOoHYQQQhzFagAAWscflUUvB1DZ2mtMci6r0WjlCOEsGgCN r3oeN27c+NRTT/loY9cl8pPI3y2elkK+9fPoo48+/fTTQlfRQ2vXrv3d734ndBVXife06X1Xm7NM A20voji1NICikCWMjgZaZyWsRQkAoGr62GcLFZBv5PtGWT0NoDH14iDaHoVZI9c0Zw+lY4irUNn4 JYBWG/yXPEVFRQAwaNCgF1988dSpU9cuMG3atK+++qr3O2IsOgDK6CSEcAYlAE0D0HwvY6EcQGXg CGHsRrWcAgCg5NpiGyGEtRlU+QantYjm3wpVoU/eikOHDmVnZ/tiSx0Rc/YEMnh4IRw/5eXlKSkp ly5dErqQHnK73YMHDzaZevWB5kMiPW18MrjArKWB0rpav2jRyYHSugijowEUaiUNAApzex911iI1 AOgtrnZ+1h2dHgvjdDpdfmzxEEK2bdsWExMDAJGRkVKpdMKECdu2bWOYqztNT09vN5O6jbXIAfLL XITYFAB6i0UDoC5zEWJVNDYiGS0AKHQWm82oVwHQJoYwZg2A1snYDVolgMJgard11G3nzp0bNGiQ L7bUEdFmT+CDhxeq8TN9+vSCggKhq+iVoqKiW2+9VSTD3sID07PXLb29xtMkOi4NILKdI7T8xHgh Mg6gYMNWAICC9754YeL8Vpc6ag5tHrNgg9pgezgzvjc1QNO1n7y8vB07dtxwww2EkHZ/96ev8/r1 lu/W69988w1fTF1dHQAcPXpUpVI9/vjjM2bM+Mc//pGamlpTU5OUlNTLIwUAkA7Lk8NrX5969sbK ApC/kJl5KR+mFH+3bkRNAUAxlQbgpYsN5uyZmfFw9koWwDEAgAgpAEhl6XfPHAcQOXPyCJ/8XSYl JdXU1PhiS8EnANd4rqf52k9xcfGtt94a4L37SWVl5YkTJxYtWiR0Ib1y3333rV279siRI5MmTRK6 FhBj9sydO/fDDz/sZfAAwBXGAZZLHgBZixe5Ogao1IRwqAMAWuMoebry+ezcBQtpu3lOevO74f5I uQryja/MGdHLGnh8/MyZM0cmk8XGxvbr10/SHv+9brfb25R0+fLlmJiYvXv3ut3u1NRUAKivr/fF scqm5Mktuw/sG/ANyO8fCeCemQ9T9u2b6AJQU0PCAbxXXMeUKXJL4/LyiBYrsxwA1HEAUl+Uwmew L7YUZAQMHl7oxc/WrVuXLl0aFhYmdCG9IpFIli1btnXrVjFkjxi7Cw4cOJCUlPTll1/2cjv89R5d qwv4djUAlV9GGq/3WAghhLUqAYDSOK4uxhbnqw12n91tI/j9SXq9PjY2lv+Nx8TEREZGzpkz58sv v2xuId10002+mgONtRbyO1IV2QghhDHJAQCAyjcSQji7AQC0RivDEsKaab7PzaIF0DLk6j98wuFw DB482Ecbuy6xnURCdbVdK2Q63zweT1JSktjGKPfM+fPnBwwY0LK/XShiHGM9bdq03bt3P/DAA3v3 7u3NdpJvX6KhYAU1ffv+SrfHU3O2fGPOsA1Av77idn6BC3UcAIA0489mHVjWrtx8qHndlKzRcMHd m70381UXYm9IJJLa2tqoqKibb775L3/5y/nz5w0Gw1133SWRSPgFhg0bdvLkSZ/sSzpyohIAgKIn pQMAyMbOlgMAzL8zEwC8rAsAhqWnycKrP85fUgpw2d1iTDUHAD853T4ZZQ02m+2mm27yyaaCheAt npZCZuD1gQMHMjIyhg8fLnQhPpCSkjJ9+vQvv/xS6EJE9pWtJd+0flibVkldPVpKaWxszTA6GuS6 q9PYlGnkAFBka/op1TQCu3cEb/HwLl269Pjjj//3v/+93gIvvvjiCy+84KO9sUVKACq/uR1p0Sua RrsRQhxaeeNvg1aqFRQAaM9YtEBpGUJYWxEAALQdIdIz+fn5a9as8cWWOiKek0g8LZ6WPv3008TE xCNHjghdSM+p1eoXX3yxgwUsOjl/LwFj0bX6eKUURZZOJhSwGfLlqqKeNUMYiw5AYelmB82rr766 cuXKHu3Ql8Ry2rTLV51vjNNht9vtDqdPRk91nUiCpytKSkoCMBy5CedyOpwulhBCOJZpPX8Ex7Is 55tf1PTp0z/77DOfbKoDIskecQYP75NPPklKSgre+Lntttv27dvXwQIWHQ3U1ezRm6w2q9VqNelU VMfZwNmLAABoXc++bDEWHT9StFu+/fbbm2++uUc79CVRnDYd8FX8BF4QBQ8hpKGhYcSIEaH0LOSK ioq0tLT6+np/70gM2SPm4OEFb/wwDBMXF/fLL790sEzr7JFfDRunAQC279khp1SmxnhhilRyVSE/ eZVdzTeP5Lpr4sNVrG289U+lNTKEEM6mUcjVWo2CAgBQ6U1cU/b857/FckpZ1vjVuuX2r2vQoEEO h6PjZfxN+NOmU8EYP8EVPLz/+7//++1vfyt0FT6jVCo77ifxFcGzR/zBw+skfliLWq5UK+UAINcU s4QQxqqRUwBAyTW9vsuu577++utJkyZ1vEzr7KGMDpZjWZZ1lemUALS5xqIAUPJDb1xlVNMAKKMa QFVkKlTw67Zk0tIAVKHJZi3TAwCtNRPGzPdV64rLinVKANBbWT57zC6bEkDB543TCG0HWLVj5syZ AegS6FgQZA8h5MCBA4mJiXv37hW6kC4JxuAhhFy5cuWGG274z3/+I3QhPlBeXj5o0CC32x2AfQmb PcESPLyO4oc10wCqIovTbqSBMjq5IgWAupjhmOJ8CuSFAe4wb7Z9+3aFQtHxMm363FpS6kwcHzNy PUuI3aDkJ51yGPMBFDZCbHo5ULpW3XKNN2g3XiiyFSqA0jKsWQ6gLnYQQghnlQNoza7G7GGISUPx F5zsBiWAqtN5wJ544olNmzb19C3xjeDIHhI88ROkwcN79913s7OzOR9dbhFKfX39r371qzfffDMw uxMwe4IreHjXjR/GJKc0LkIIYXUU5H9VSgPVeCWDNdHdv6LuK88//3ynUx22yZ4ii91ht9vttuap 81k+JFimUA60zkJYqwIA1EVWm1mnBABVsdnKNJ92jLlpchBCGue8V9rcZvrqlI+MjgJNi+xhrXoA ysQwRXKgujAN2ObNmwUfbiDGMdbtmjZtmsFgWLhwodFoFLqW6xLDcOreWLJkyahRo5588kmhC+mV 3//+9ykpKY899pjQhfiXqIZTd8rr8Xg8XgC499579Xr9rFmzzGZz24US+VuKuTqAyAiIg8QI/sZj DgCS4nxyv3H3VVVVjR49ujtr0DeNSh+Snp6ePmJIcmPR0sxZaih9b6t+mwFUvxkDwEVTQO1ZMGZk 9oqtALBpdvb/nWCvboIBGDCw8VZ3x3cHgBqXwv+Pa7z9oK71LqUZM/PB8q5e/6YB1t6X1WmJo0eP rqqq6s5B+YGw0dddYm79BHWLp9nPP/88cuRIvV4vdCE99N577w0bNuz8+fMB26MgJ1GrFg9j0+cr aZqWq7TmDsdyWrQ0penRnQOcy1xmdnGNPWNac3cuv3B2naLxPgdaXejgCGm39XO13cNoKdCYz+go UBsdpLHT6dqr8QEybdq0TjuiW7d72h94ZtbJAdoZVsC2cz+1S0cDyLV2lnAus4q/Hb7VO8+/Ra6W u7PoFAAAlKYrD4k7fvz4uHHjurCgHwVZ9hCxxk9oBA/PbrffcMMNAeuz8qG33norIiLCVxM0dFHg s6d1V5sjHwBodXGZUSOHjvv6rboeZ48ZAMwsIcRlLjZaXV3vlb3uQ0naxg9jktP8fV2MjgKtmXFZ Cpu+IdNFVn9FT1VVVWxs7ObNmy9cuNDuAhRFHT16tOONtL6/R95u9yBnN1AA6mueycI03dzWamFH maK5fSDX2FhCWIvi6iCCln1ujbvjHMUUgEJvIV1w+vTpoUOHdmVJ/wm+7CHii59QCh7e6dOnAeDe e+8VupBueO211yIiIlyuQI+ICnD2tLnG4yzLB1A2fp5xNl2+zsYSa5FaqdFrFCDXmglxGTRKAKAU ahUNdNs7pq8Zy8ta85XqwiItDQBAa4uthLPl8w+3oFQWl12rUhXbWEKIvUzf+LJCY3FxhBBrkVqR r9UoaQCgFFobSzp+KEnnA69Zxul0Mv68/vj3v/89Ojqan2hq1qxZn3zyidfrbbnA8OHDT5486ccK rot1OhwOR5dz3l4EQBm79ufvcrkGDhzY89J8ISizh4gpfkIveHgXL14cP368SqUS+UPpCSEcx61Z syYjI0OQGbcCmT3XDi4wa+UAco1GRQHIlVp+LLKF795R5BvMZ41qCoBqHpgr17XKnnbG8rL8WF65 wWIz6pQAoLOctRRrKaC0BpOrxkwDaMwuxqoHAKXOaLeZ8mngH4HI71euMZiMehra5ly7DyUR/L6f v//9781THQJAXFxcXFzck08++d133/E3hyUnJweyC7dHWEO+AgBA3dVPIY7jwsLC/FpTp4I1e4g4 4idUg4fndrt/85vfUBRlsXSpIS+I48eP33LLLbNnz7548aIgBQQye1JTU/fs2dPylcZefoXGUFyk ogBAaWWJRUc3PS7WrgZQNzY7SLGq9UxR1x/L2/SiS0sBpTETzkIDbWavXu8xaVqMe3aVUQB6K2PR 0qAo4l80a6iW/XsukxYA1IZ2ukPLysoGDRo0ePDgVCEMGDCAf7RVS+Hh4QDAX+aJjo5mWYHG2HUV ZzbodfpiR3caiFFRUR6Px28ldU6Mz1DoIn7km1wu//DDD3NzcwNfQLCPautUbGyswWD4+9//npOT s2rVqlWrVslkss5XC5TLly//v//3/1599dUNGzYsXbq0X7+gGbTZY9u2bXv44Yf37NnTYg58N0C+ 4701QwDmTDaWJOR+fPzPd9UBNWuSDADcF0wAeU0jptIyaLjUYnMcBwDND1JJmzgdLOVO73QG6JkT kgEAIJ5eSr/jAfByjYs3PvGi9ujnFnphZuOaUQOHAziveDkAatJN/IsR0kTwNO/pug8lsVqt999/ /9/+9recnBwixAMvioqKXnjhheb/RkZGSiSSsWPHPvnkkxMmTACkWgdWAAAgAElEQVSAqKio2tpa qVSgYXZdEj5xzsMTu7NCfX19XV1dZGSkvyrqgiDOHhA0fkI+eHgSieThhx+maXrdunU33XTTM888 8+STT177PTHAWJZ94403Nm7c+Otf//rw4cN9Z7Lqe+65R6/X33PPPc3xw9UxQKU0fiOQJQ8HGBBx zUnd9MoV5wVo/WlzzVjeSSnhAFB60uWdLAsH8Jh3l8KsxsyJuPqopfDBo6DUebHxf9yVUwB50eEA 0Jw3XOsK0uerDb+d2qYuMQwTHzhwYENDQ79+/WJiYqKiopRK5dKlS4cNG9a8QGxsbG1trW+erCga tbW1LXsahSFgm8tXAt/5FtpdbddTWVm5aNGi5OTkV199VaiLQBzHbdq0KTU1df78+R1Myx1IgT+J Pv300+TkZH7yPdaqBwBNsZUjbJlOwY96Ml8dS904WtfGEsZWfM01mPbH8soBQKF3EuIw6QEg3+gg jJkGKLQ4m/vc7AYVAGWwughhDGqKH1/XYr+t/k0IazboDeZWo39FcmPs119/DQALFy7ct29fuw8C Hj9+vCB9zmYNBfmd3yXaM//73//S0tL8tPEuCoXsIYGNn74ZPM3++9//3nfffTfccMOzzz4byLlH zWbzc889l56eLpfLOx3zGkiCfIFrET+cWa9q/iqpNdpJ6/t4OIdR0eK7ZpuxBu2N5TXLAWi68TVa bWAJIZxNTQEAZXI2j/R1Faqan05CF1lcbfbb+l6itg8lEUnw8K5cudLBT6dMmSLIRFNOa1lZZ89f 6DGr1Sr4VNYhkj0kUPHTx4On2bFjx/7whz/cfPPNN95449NPP+2/k/PQoUPPPvvs8OHDR44cqVar zWYfPFTJt4TqPGjZ+uEYl9PZ+FSKdnCM0+G47k/bjOVlzfywAtbldLpa3nbCsWzba9mM02G3O7o7 BlpUwdOpOXPmGAyG7q3DOflx7QCg0pfxb7zLWqzkx60rtc1D0vmh8Pc+v/Haia5tBk1+kZUQwjlN ajkFAEApiswOQghh7XqVnH+l0NST6aj3798/ffr0HqzoQ6GTPcT/8YPBc62KioqXXnpp3LhxQ4cO ffjhh1977bXS0tKampoeb7Cmpmbfvn1arXbJkiXDhw/PyMj4wx/+IKqGThsCdly3jB+fYUwAUOa3 WQSCK3gIIc8884xGo+nWKk6jGkBebLFZjFoAUJe5iNNIAdD5RRZrmZpunH3g6lD4/3x17UTXZi0F GlPjcxbkGrPNolcCgMrGuXQ0AKUyWiwGjQIAiuzdvgFq69atjzzySHfX8i0JEWJsif8cPHjQT0MP +sjggh6rqqr66quvjh07dvTo0WPHjsXHx0+YMCE7OzshIWHAgAEDBw4c0CQhIaGmpuZSk4sXL166 dMnlcpnN5mPHjl24cIGiqKysrAkTJkybNm3cuHFCH1knJBIhT6I9e/YsWbKk9ci33vFWl+w2Z+TN GuKHcUhiGFzQXVu3bj18+PC2bdu6vkrl9sVjlkCxRXNXZoqzwnwhbjR8voRake0gLw4B8JzeGTVs gcHODf98JvXhQqZkuQyg5HlJ7nE9u/vh8x8vHyZPdJBXftqcs8Tz6oHZ38RRK4xOkpMM4Kl4ftnu eb8fOmnCkiIbO3+EFODsekmaWWfZvTyzWwf17LPPJiUlrV27tptvhi8F9zi3a/lp5BsGT6dGjx7d POUiIeTUqVN8CFVVVTUHDK+6ujopKak5ivhYSkhI+O1vf5uVlTVixAiJRCLssQSRa0e+9VZ4cs78 WT7YzjWCMXgAYPTo0QUFBd1aJeO+Nfm7qdlUAQDQSu2rf8qOABnAujTJuuZl7BfYG5qHwgNMfUAH 1D+Oe+6rfHcrrbMMAfipccE6AHUGP+JdmvnKe5meiu0AsGBkVPOm5HWtBxV2QVVV1dSpbYcdBpqw zS4/OXDgQEJCgq86x7CrzbdC7K9ODIfz6aefJiUlffPNN0IXcl1B19XW7Ny5c8nJyd1ahbFbbU6W Y5yWsiIlAKUxm7U0UFonxzEMy7rsxuIyJ9dmKKBdDaDSamkAg4MjTQMFGbMWQG7hO9VYmy5fd+w/ 2sbH0zEMyzKWsmKzvds9pKNGjTp+/Hh31/It4U8bP/FVYGDw+JwYPqx9SCSHI+b4Cd7g4Y0ZM6Zb g1xM+QCU1sERQlyFCqA0ZmdZPgBVaHESwpZpaQC5tW32tJ3ouvGnrjIKQFVoZglTpqUBlLYasxxA ri1jCXGa9QCgMXVvDsNTp04NGjSoW6v4gyhOGz/pfWxg8PiDSD6sfUU8hyPO+An24CGEPP7443/5 y1+6vjznMMqvdi0pjHaWELZYc/U1vdlJrnmkRZuJrpt/ai/WNK/Ij6F3mq4+HVWuMXZ3pMG2bdse fPDBbq7ke2I5bfykN+GBweMn4vmw9glRHY7Y4icEgocQ8s9//nP27NndXIl12O325geX8i+5nI6e TcvNMk6nq9UQd5ZxOJyuHk3x/cADD7zzzjs9WNG3RHTa+EnPIgSDx3/a/7DmHGVGoR6L3Cuiyh4i pvgJjeAhhNTU1MTFxbndbqEL8YG6urrExMQzZ84IXUjwPDO7x6ZPn7579+7777+/pKSki6vgqLYA 8mzPkWyu8ICX+fbIqW6P1+nKlvuYe+65Z/v27bNnzz5y5IiAZQTpqLZ2DRw4kB9PKHQhPvDRRx9N mjRp6NChQhcisq9s/tP1dgy2ePyt5V+drYifD0ZpcVo0+UUMYYpUCpVaAQAKjV6frwAAWm1gCCGc Q6/iH0qm4R/eyNgM/HwwinyDixDGolfpLIQQwppVSv3R5i37+WHL4jyJhG39hEyLp1lJSUlmZqbQ VfjAjBkz/vnPfwpdBSF9oc+tWVdCBYMnAFp9WLM2NYDKYOUYE01pXPzEX/nFTodJAUDnFzscZiVA oY01qgHUBhfHlGlokBeynE0JoC62cawtH0BeaGNMGpqfe5HfVPOWA3k4YiJU/IRe8BBCvF7vTTfd ZDL5a3LPwLBarampqSJ5HFHo97k167TzDbvaBCBNSadg8A1p4QBxIAWAOqBfe2JW8pCs6RQ8+tu7 hgwZO5GCkz//78geUAys3f9Z6fmULDD8WG3dsxW06lkjwqUjnjVrDNv2112d4R/iWm+5bxKk8y2U utpaCgsLe+WVVx577DESzBPBPPbYY3/84x9F8iyiPpQ90GH8YPAIynv1H4lxEeEAwNYlykckhANw dQCR/dznLJAk/cXlctVClr7ojigAoCL5uOE4gFEJ4QDAvxABTDtb7osCHD+hGjy8hQsXRkVFbd++ XehCeuhf//rXhQsXHn30UaELadS3sgeuEz8YPMLx1lmaHzTWclxAOAD80vy/sMFZNMDomQ8//LB8 hHNJgTVy1HTa8ua+s14Azxevr6XGDQ8DKP1PpQeg4oMNpSANb7Xlvitg8RPawcPbuHHjCy+88OOP PwpdSLf9/PPPKpVKo9GEhYUJXUsToTv9hNHyug5e4wmwNn91Jq0cQG4+a5LTWhdxaWl5GUMIYZr/ oaNAa2ZYm6HpmTJUkZUhhFgKlU0vqK0MIS7T1UfR0Dqmect9cqxBG/6+9hOS13ja9e67744YMcLp 9NeTdfyBYRgA+Otf/yp0Ia0EwWnjJ3zk7Nq1C4MnwK79sL72wTDt49g2d9ixjNPpdHEtFnC1euRM l7fcC0GRPcSf8dN3gof33HPPxcXFifm5Hi19//33N9544/r164UupK3gOG38ZP/+/bGxsRg8ARYs H9ZdFESH44/46WvBw+O/s7700ktfffVVu0/aFoODBw+uX78+MTHxzTffFLqWdoTa83u6S9iHr/RN IfaeB9fh7Nmz5+GHHy4uLr711lt7v7W+cI3nes6cOaPVasvKyiwWyy+//NL5CoEVERExbty4O++8 c+XKlaNGjRK6nPYIG30+4TLraGURSwghrEEl15ldnNOkogGa7jokxFmUrwAAoJRGe6ux7aHxDgSX EHvPg+5wfNX66ZstHuQroTDOLX74qNKtbx5zA3iOb9p0atRwdkPKlCiVlWPtmTvlT+2o9FTuWrAu 2sYR24uQO+fvbqELRkhA/Mi3WbNmmc3mHm+kL7d4kE+EQvZA/FQ9XWo4WuM+vqeUXj0VKncCDKyt +uzfx1JyKMvJS+ERiQBb/7huy4mhTzgOLJUJXS9Cwupl/GDwoN4LiewB6cw1qg27ir/YuVOpov9/ e/cf50R95w/8FUzcXSDI7rrUgyLiCi5ahitbC9QfdRbkoFSCP7gqhPuK1oBWIVuvYPxW7lzuiqE/ NDyszeJXwymx5+22GhED2rA0WglHs5XZalYNNbQGISvZOkEm6wQ+3z8mm132F/sryWbyfv4Bm2Qy 8/lM8plXZuYzn0H0uAC+8MtoNBrFrOpHF07Wlt8eCfjmj2/eOJebtGon7fcQ8t3vftfhcAwifih4 yPDI9kG/YSL6DADA+0TGZMEAuMKMMea18ga7EHKZYPEyxljEDZhCnd6nnjWQO1S2znO6Ort27br4 4ov/+Mc/9nN6OsdDhksON5tzyS4TYFR6HLCgy9KerZaAdM5Vh0b7OaMB5vSGI0epbJ3nenX6Hz8U PGQY5VL30D7FdlSN+9uW6KNzipXHiXhrq6QtLta3DyUZbzkWRVFJWfE54+jlVgdZdVDZOldBdV57 7bXVq1fv2bOnsrKyt2noUBsZXjnfbAAg3rSsiHPx9ui+NcUDfKsKNhw5R2XrXB3V6Tt+KHjIsFND swESsZik0+sHMTK4OjYcuUVl61w11ektfih4SDqopNkMmmo2HDlEZetcTdXpHj8UPCRN1NHHmhAy DLp0vKbgIemjnp9sg6OmH625QmXrXGXVQfvez29/+9t//ud/puAhaaK2ZjNQ6ttwjHwqW+cqq47i zTffXLhwYX19/W233ZbtshB1UmGzGRBVbjhGOJWtc5VVJ0Wt9SIjBJ3vIYQQkmmUPYSoWWPtmuoX mwEgceSRqjWNMRw7uKNKo9FoZm1+tRlAa1P9slkajUazatu+eJYLS/IIZQ8hajb5qq8+ufKNGBAX dm9p+Ork+J5Jc58wB6JS+IkGw4wXj3z2P8bl+kdDTA5evH7+9iYaaJdkiPb8kxBCclbZvGUGcO/G 1o3Z/SxvfwnNdQB36sO33sCXs4Ajn8kzOOxc/uNr6lbeHYzMKKcbjJAMof0eQlRNO3OtCb/du6d+ E8w3XyH+7RPwF395KhqNnprlcCycXHz7MxGfe/7Hro3cFROepf0ekin53pWFOvNknsrW+civTqxx 27jK9eBt0X3rippri2YcDbOfTETL1lkTLtr5XjN3583Rw1XF2FetcVwbeuH2Kcq7Rn69SE6jY26E qJyeW2LG+s++v6QYQMUKl8UwSaMBwJnr3p551Ud2rrJEwwECjL5NU7JdWJIv8v2nDf24yzyVrfMc qE68aVnR+ofEfde3n82Jt7ZK2qLi9tF3460tUQklE8s6j8abA/UiuYzO9xCiZrGmWk0RB9uW6zt1 IygsLi7uNOx7YXHZxHODh5B0y/efNvTjLvNUts5HfHXisVZZXzzgDmwjvl4kt+X714saWOapbJ2r rDopaq0XGSHomBshhJBMo+whhBCSaZQ9hBBCMo2yhxBCSKZR9hBCCMm0PB3XwGw2Hzp0SKPRALju uusAcBz3i1/8orCQLnIghJC0y9NulFdfffX777/f+ZmxY8fGYjSQYiaorPOuyqqTotZ6kREiT4+5 /ehHPxo7dmzq4ZgxY6xWaxbLQwgheSVPf9p88cUXpaWlbW1tysOCgoLjx4+PHz8+u6XKEyr7Qa2y 6qSotV5khMjT/Z4xY8YsXbpUOd+j0WgWLFhAwUMIIRmTp9kD4P7771cOu+n1+h/84AfZLg4hhOSR /N2tZoxNmDDhs88+Gz9+/GeffXbBBRdku0T5QmUHc1RWnRS11ouMEPm736PRaNasWVNYWHjXXXdR 8BBCSCbl9U+bTz75ZPLkycFgsLy8PNtlySMq+0GtsuqkqLVeZISgrxfJNJVt1FRWnRS11ouMEPl7 zI0QQki25HX2/PznP9doNJs3b852QQghJL/k6XhuAB577LGXXnrp2LFjixYt+uKLLx5//PFsl4gQ QvJFnmaPEjy///3vy8rK9u/ff+ONNwKg+EmrxsbGgwcPKn//6le/AlBZWfnNb34zq4UihGRHPp5O 7Bw8yjOtra033njj4sWLKX7SR6PR6HQ6rVYry7JOp2OMxePxs2fPKqNL5C6VnZM/fPiwz+cDsHbt WrvdDuDrX/86/UQgw05VzaY/ugePguIn3R577LEtW7akxtC78MIL161b99Of/jS7pRo6lWWP8hNB p9N9+eWXF154IWNMkqQzZ86MGpXX54bJsMuv71NvwQOguLh4//79brf74YcfzkrZVG/16tWdd3Eu uOACk8mUxfKQHm3evPmCCy44ffp0IpFQ/l2/fj0FDxl2efSV6iN4FBQ/aXXppZfOnDkz9bC8vHza tGlZLA/p0erVqzvvxul0OvqJQNIhX7LnvMGjoPhJq3Xr1injt44dO/bBBx/MdnFIDyZNmjR79uzU w8mTJ1911VVZLA9Rq7zInn4Gj4LiJ31uvfXWM2fOAJBl+Y477sh2cUjPHnzwQb1eD2DMmDEPPPBA totD1En92TOg4FFQ/KTJ6NGjly1bNmrUqEWLFo0bNy7bxSE9u+WWWxKJBIBEIrFy5cpsF4eok8qz ZxDBo6D4SZP77rvv7Nmz999/f7YLQnpVWFh42223jRo1qqqqqri4ONvFIeqkqu6hXQw6eFKo4/Ww O3PmjDJwuFarkuuaVdbHWvHOO+9ce+21r7322pIlS7JdFqJOKmw2iqEHj4Lih/RNldlz5syZ5ubm 6dOn63S6bJeFqJMKmw2GL3gU+RA/o0aNUuU3QaPRnD17Nt2LUOWqIyStVHi+Z3iDB/lx7oepV7ZX bU7y+XxlZWVvvvlmtgtCVEtt2TPswaMoLi5uaGhwu90Wi2UYZ0vICHTgwIHvfve7drt9xYoVe/fu zXZxiDqpKnvSFDyKkpKShoaG119/neKHqNiBAwduvvnmX//617fddtuuXbuMRiPFD0kH9WRPWoNH QfFD1C0VPDfddBOAuXPnUvyQNFFJ9mQgeBQUP0StugSPguKHpIkasidjwaOg+CHq02PwKCh+SDrk fPZkOHgUFD9ETfoIHgXFDxl2uZ09WQkeBcUPUYfzBo9CiZ+VK1e+8cYbGSsbUbEczp4sBo+C4ofk un4Gj4LihwyjXM2eQQRPItba0tLS2hofxmLkW/zEW1uOHTvW0hob5Ntj8cTwFogMwYCCRzFv3rxX X32V4ocMg2xfdT4Y//7v/z5jxoxIJHLOs5LfeE7NDHZPMPWax9bp3ouGGn9E7jJPwcZzVj+T/Dxg 80eZHPV7/dGuU/Xs5MmTHMc9/PDDQ65Z1pz/myCHHGa+0zq0Cv1cO0lRh4kDYBOCDg41/ugQCjsA GfiG52gjeuedd0pLS994443Bvffiiy/eu3fvsJeK5I/cazY9Bw9jTPIbAJPTGwwGAgGhzmoEYK4L MsbCbgvAOX1BUZIiQa8ZAO+Qzn23X8keFvW7PYGozGQ/AL/UdSG9yfX4Od8GNGLjARhd/pCyDi0c wNm6fQa9kwUeqPGEGZMDXk9gYLk1eJQ9PRpK8KTmQPFDhiLHmk2vwcNYcpdFEFNP+Kw8YArKzG/j wdlSL0gBp9FkD5+79Utmjxyymc3u5vdqlJ/4nFkQGZNCDrMBADij0xfurWw5HT99b0CjfhuAumDH KpNDLl5ZOSzqbt+nNNs8ImNMDlqNBovNauQAwOzwyUysU/aZOKM7FPFYLa6gxBgLeewGAJzBaqsx mWwhmQWcZrNTUBYRcJrNzgCTg1aj0Wq3GZT90f59Fv2s17DIuewZevCk5pPP8XPgwIE77rhjxowZ I3Oob51ON3369DvuuMPj8WR7VfUsl5pNX8HDWMfhstQTgh3gfSILe2oAgDfZnC5/ICT29Js7mT2i nwes/r8KbhsHzubyReWonQc4s0cQXFYjgLpQr7/Zczd+0OcGVAnvHg+T+Wy8sk8Z8DoA8DY/E/0G AIDd7XXbTQAcASnosQGczeWNSFE7B6svKgoOAEa72+9xAAAMPpH5bRysvvaFcrD6UnMzWx1CJNL/ z6I/9RoWGVjEMBqu4EnNLQ/jR5bldevWXXLJJc8999y7776b7eL0qqmp6fnnny8oKLj++utlOUNH GvovZ5rNeYKH9ZA9omAHeL/IGGNBj9Ns6DhdYakTGJPDAUEQBEEIRKT27Ok43yPw4P0SkwIOAHVB 5ehbuAYw2IU+ytln/Ih1ZqPZYgIAg1WZZdBtBQBwNa6+ZptufW9ABTsPWHvIHkkwADXe5IcSdBrB 2UTJbwAs7jBjjMkBw7nrkzHRxsHqj/qtHEx1SoOI+qzKJ9V+5JOxTmfgDIDZFWJswJ/Fees1LHIo e4Y3eFLzzKv4OXPmzLRp02666aZoNEPnLIdIFMVbb7113rx5ktTvUwgZkRv93AbZnVpuAyADsZaW CTeseOKVfUyWwkGf3cxvWb7+YCy2cwbHcRzHzXC839r1vQkZgCwDMgAsv6JIo9FoNJM2AWiT+1hm 3z3fTu7b+aR0UzgatH688dl3WhJH669Y7HQHRTFkrTdwLx4Zzj54w6lgHIBzuqgljr64rbapRSlw 8g6kk2ZfB+G9SAIicMkkPQBoJy3mEEen9Zl06pBT4K6+XHmndvRF3ZfZcrxB+UMEpk4tAQb8WZDO BtGrrT/yrefb6tWrx48f73a7c+Vu4nq9vr6+furUqStXrkz3vawGJAeyZ2DBo0vdiTm+t3Y9wF+u b/3VhAnjftEIANrCieVz1mz6MdBwIqpfJyb9cHbPXyOdDrIsApwnLMmiKEmi4HVvMkzruwi9x0+i rZT31Nw+sbh86f38lj/8JeB6GjXbF5Xr9VMWOaz8/7wVOn8Fs2Ha3GXAxt82dXStPva72pXrnz6N C0TgovHJdR7+89vgrp6gPJKTUdXW8ywLp1RB+Lw9OeROUxUqR89jH+1GaWH7k3ICGMxnQRRpCh5F /sTP008//dFHHx1o+OVdWm3VI3tSv8aad6zSVNX2cuVB4mjTwaajMQCNW2dpNh8cWhFitbM0Wxu7 /VbuTbxplUaz/c+ndu7ceerUqZ07dw5t6cNppGfPgIJnHPCe/1Bzc1NT41s7HvnO8u2weu8pQ/G3 rTw2rq5960g8kYi1Hq3/6X8Ahqlf0Rbqk7Td5yUDaGj+qEU/7ToDhG31hxJ6fez933A3LP7d8fNf o6LEz+7dux955JEuZVS2rKfbwBXogOS/ygK/UlJ03jlnRWHFEhuPtZzhxYNHYvHYkbdqJy3eAtPm yslTv8dj/aOOo3EkWhufWr6Tu/3r+n7NUjvjWhM2meqbWuItB/+1cj0wTgki4dlXjsQSR/f9aq2A cee+Z3CfBUlr8CjyIX5OnTq1efNmm812wQUXxICGLYufbc8AuS2Mk729L7GHm8u99BGAyUuf8i67 fGilGGC/BlkOA21yQqPRbNu2rbq6+rPPPhtaAYZPtg/69eX853g663J9D2ewuwPtr4Wdna9NAe/o 1kWq/eyCYATsgsjkoIUDwPlEFvHZU+80WD39P2d38uTJmTNnWiyW9ieiNt7gFRlr79ogCjagJswY kwPGczvpDbvXX3+9ra2tt1fP/00QA8mOa8p6qKlTPhU57DV2WjtBiXWsQ8YYE+0crP4ok/w8eJ+Y fMbmFxkT3dbkW3kOgCUoMzHoav+ceCMHgy35iaTWzEA/iwx8w0d4I0rHOZ4+lqXicz8bNmy46667 GEtezmEwALCEGGPKCVHOLjLG5LCzJvmtNtbURRgLOM3KQ0tdIOiy1tQFAk4Lb3Ymv9BRn4k3ukJS 3x045YjPYuAAmKw2E2DzR6WA02BKzqTj725L73IWvLq6+t57703/quqXkdtsBhY8/SBFI6FQKBzp /6UlsiS1TyuJ4XAk2mMPuT6dGz8d2SPYeN7mZyzqbL/mlbe40pc8L7zwAoAxY8Z8//vf/+Mf/9h9 gn5uQMVoJBwOR6JdTlpKkXA4HB7YNTsRwe10JS+gingtQHsneFmMRKJSH/MayGeR59mTyeBJLVGV 8SOKYnFx8YkTJxhTNugGf9hvAgx2P+uUPYKNAwwufyDgqzMAFk9YDHqMAAxWf1hUum5GfVaA80QY YyxUZwLMwb4708oBEwDe4vF5lV9rNn9U9NuAZNfT1N/dl94le2KxWElJyfHjxzO78no2QpvNsAdP FnXb++lKjEQi0TTu8TDGnn322TFjxgDQarVjxoy59NJLH3/88U8//TQ1QeY3oFG/FYDBYnfazQBM zrR088vn7Ml88KSWq774qa2tvfXWW5MPJD8P3i+ziNsCwB1lQYdByZ6I4HH7w4zJYjRQw4Gz+hiT HDx4u8A6LiIMmpJdNyUHD87q67sDpyTYlQMwjDEmC0rHUVGwpX6upf7uYendev/efffdVqs1I+vs PHo405F1WR8kdHiVlJTs37//xhtvPHv27FVXXcXat1apf7s87OPJQU/v8/mUPxKJRCKR+OKLLx57 7LF/+7d/q6io2L1796RJk9K7CnpSPHtDWPjGLvcfDjUXOb2hFddPyXwZVCwD53h6o5z7Wbp0qdPp XLhwYYaXnibPPPPM5s2bOz8jSyhbZLEbtix+eIdnXuos56mXV09aLCQfGO7XJTvSdO6QqS031nA3 PHdoCz/5iQY86qiEGACw/IqO072GTtPLaANWXq4sQXvZYg6fn1u2TqeAui+9K5PJtHLlyg0bNvS7 6ukyErPn5Zdfvvfee9URPIqSkpL77rvvqaee+stf/lJUVARAo9Gk/u3ysI8nBz39Z599lsohhSzL F1544dGjR9vaeumJln4TZ1atmVmV7qVceOGFstxXV+xRo19KQRMAACAASURBVEYNpe9paiWPHFkM HoXK4ue99947efLkokWLur2iv8fmevoyw/ztgOE6IPZro8G3xBXev3BiMXZUFT3fS9u6Znk1Nu38 L8dXBM42f4pWblQ6cB68QS8ndPjo0B/kSzt14JQBNJ1MoEwLINIo4OrkC8mReWMtx8Fd0s+lz5kz R6/X/+EPf7j22muHsk6GQaZ3tPohGo1yHLdx48ZsF6Q7WZL6OhPRm6wfQnzuueeUY24A9Hr9mDFj TCaT3+9PTTAyvwlDp9Z69SFbh9pGckmG6Kmnnrr77rs7Hnd0nGGMMb/dAAAGu8iiNg4Gh19mctBj A8BbfYxF7Ry4GrfIOl86Ha7hAMBUF2SMKYN3GGxeibGI3wHA6ut04WrEwwFmp19islBnQcf5Hjj8 ETnqMwLge1l6t2NujLGHHnpo8+bN6V1l/TBCW2aa4keOBn3+oMyY6Lf2fKF+78SAy9Ae2FZX4Pxv aJf14GGMPffccwAKCgpuuOGG+vr67h3ehrKNHspaVUgBB2Dwi90HI1eGg+tTxGvkLUIvl2znW/b0 urmX/EaAt7hTKzPgMIK393KaUQ4JPiEkMsb8Vg41vuEvT0655ZZbnE5nx+NzsyfZJ9ZgFxnzO5K9 2sAZa8y8cp7GbzcC4Kx+ofOwHQ4jYPC2t5a+O3AGXTXtL3IA7H6RsbC9vanwvJI9PS09InTvQLt7 926e59OypgZi5LbMdMSPLFgBq8SYHA14PIEB7MHIQRNgsHmikijUWdD5m9enkRA8jLG2trZf/OIX ffRvGVL2DHqttusY/UgZQcfpCwYDgUDA46xBanienkWsHJSx4HqUV9nT14Zeah9kr/0ncEe34J6m tgOw+hljkYDXKwzp2zuQ+InajQZnQGSMScE6g9EhMtmnbE85oysQZYxFhToDBwBGmyczQ8ScOXNm /Pjx/e8bJkUjkWRnWlkUk90x+3W8pM8OnLIYCYcj51ZZjka6Tt/j0rs4derU6NGjsz7Ezohumf2P n5DXkRx42pi8r4wUrDOZrHaltztv9oYkKVCnTMObnZGgy1yj9GnuzzDMysBlhuSPa9ELwBE4f/iM kODpjx620T2uB8YCLltyVRssvrDcfa1GAnUGztx+zECsMxvMzgBjst+pHGbgzHZPl3XXOXt4wNax FyM7eHBbXrEZeatbuZSChT1W3uRQZu+z8gCX3GfqZ71U6jyb+IxfkjKAsnXirVH6hjG/jYfFG/FY AEtAlMJeK2AMyKKdg7EuxOSgOc3Xw6W89957M2bMyMCCMulb3/rW22+/nd0yjPSW2Z/4EQMOACa7 JxT01fBQrtYUBTsAGO2BoN/KAzA3t4ZcNhNgdPmCrX6r0iO+n8Mwdy6Rw9jRgPuQQ8HDetxG97Qe 5KATgNnpDQX9NiNgcMTEbmtVEoypA9lRLwfYBTFYZwJgc/n8Hju6jQHaZb/H6g0zWZIkKex3coDF c9RtBniHyBhjooMHajyMsajPBhj8Yb+x993QPMme82/cM3xJyiBKqBQz4ABqoixqBewByVvDwWh1 uVwul50D5xWlOiMAo63OLQS73f8xPV555ZXvfve7GVlU5qxatcrhcGS3DDnQMs8bPz4rB4Mz+UWM ejnAERBFwQaYkgeAIh4OsPlFOWAD7FKqR3z/h2FOkj0WDjB4z/e1z63gYT1uo3taD3I04HL5RMZk KeqxJm+s0HWtMuaxAAaHxFjIZQIsYRa1ceBtySPdfruhyx0ZOmdPl/M9ylgJot8GcN5o8vN1BiUl Gq0+kbHUCNn9q5fq9GuzntlLUgZfThYyg3N6nBzMISbVGcGbbU6HwhWSGJMiPrfDbOTQMXZGem3d uvWHP/xhBhaUSZs3b+7jisPMGOnjuQEoLi7ev3+/2+1++OGHe3o99u4egV88M9lbvGj8VCByOgEA 3OxJyrP68VMBICHJOKenfbLrbT+GYU4uyl+9RXAEXri+rK++6aq5Pqn7etBqdZ82WMZpNLqikvkb G1BaoAW6rlXgW3fa4Xr+/XjsD89t5+13Tox/ckhAw/pKjUaj0Wgq17pQWtDbQmOAxSVEwqFQKBQK ReRXNpQXQj97iRmC+08tLQd/K6DmpnLU/2ulC6ZvjA43vuU/iZOH9h882pqPY7sNqDt1+yUpWPzw jqM455IUjUY3rmTGJgFTL+r1kpQnnzsUjx1+ogGPfq9yEGOKz5s3b9euXXfeeeebb77Z+1RTVtmm rpy/stR2xxQUfu06vgHTV9x1112G8udX14k4Wl204Is5dz3xwmGPGW9/ED1vlYfugw8+uPLKKzOw oEyaPn36hx9+mN0y5ED24Dzxo/uHaWiI/D35SD79MTBhtBYAhI5rsESgx4uZBjYMc9HFK82266/o a7RM1QRP0rnrofk3D619cpo3FJEZC7vNONnz9QuFMxdZ0PDCdsf/c8F88wxoR48GTHUBWZZESYoE fO7Hvt3bShSBS6ZeVjZxypQpU6ZMSYV8+R1WfovD4bA/aXAsL4P8JXhwvvncjMobVgsQ1i6e6/q4 l3GE1WtQ1/Ho77G5uO2r56/eianouCgkKin7NGIfl6S4dv6X47nkJSmDGlO8P/HDGYwAvr9kFoCK //O0Zd9ijUajKblhVt3/nVk4ZZWdm1+imaXRzH/S+MD8TFyPHAwGhz97Eq2NbzX2/8dSrGmbZta2 Yfx+V1RUBIPB4ZvfYORG9qCv+CmctcSMTQ+82twKxF7dYhJg5iv0QAGwcUt9MxDbs62mAcaFV+kh AzgeibV/5vqBDcOciJ3+6qzL+hhrWm3B043cBqD00klliWMHH1v8JEoRB7quVQCYcrvd8OT69Q0G Oz9RC+2UJSZs3/zqUalQL4eemDF38c5QX3uOcg+NsvK2+7Fz40YXt25JBaBfUbuPHT7MWPvRJImt 6+VGGGo16AtItVOWOuyp6wUSAKZO/+qEYu2RfdtXNwBxGUjgJE5+Hum8sSusWFjDudau3256dEnx EMYUP2/8SOJJwLq4vFBZ6k8Oy9FIRJTkJ26vADB7zQtSNOIORyT2wpyMfOCnTp1KXRs3fD6uvKHy 4wHtqAvnn6T/xowZE4tl+7dadg/5DVQv536iTnNqiGW+ToiyVF+DdjZPmDEmBeuUR38VbOBsYv+H YVYedB5YqZucO8fTWQ/fhJ7Wg9QxzjSUG7ByNn/3tcoYk0MuDrC0d05jomBJfURcTeDc0zOdr+8x 9HocP2LlAaOz62tdLrY4b71UYcDXzWT8kpTBlV+wGwHYfJm7JaggCAB+8pOf/O1vf+txgunTpzc3 Nw9pGXLEZW3vTOvwSnKwJtlV1CyITAx5lDGqwRls7qDyjpDHnuw+arIFoh1nUpkcspt4Q417iP2j T5w4UVZWNrR5DFXutczeuh6IkXAoFE51aBf9NnB2kcmRc4ddliVJ6nrr8sEMw9xFTgcPG9A2WhYj 4YgoKX+KymULPa3VHt4ZjQxqMPAhUGX2DPsFm2m6JKVvPdei14tS0uWZZ54pKioqLCwsLCysrKx8 9tlnP//8884TTJw48ZNPPhnKIiIeC2BwC0HBYwNg8f5VcNs4cDaXLyqLNgBGuxAMehxm5cJBUUh2 3A0ILiOAGq+yNZOUn18wD72PxRdffFFUVDTUuQxNTrbMfnW8Huw19oOQ68HDVLqNZmqslzpGClCM hLo899xzY8eOTe3AjR07tqCgYMmSJbt27YrH44yxcePG/f3vfx/KIgIOI2B0C2GZyWHBJ4SiTE51 zpQEt8sfkZgshQWHkj1+K9d+RQGLeG2mGneLYAcMZiMAS2CYLgnVaDRnzpwZnnkNykgcS/S8lHM/ N954I4DHH3+8x2mKJi+ocyMD9wFV/TkeMnJkfZDQ4aWc+7n55pu3bNkiiuKZbhKJRPcnh/d5SZJG jeo47X3q1CkAr7/++u7du71e7/XXXz/0albctqHmFW4xtxMAb7L97D8qkZChdLMtxOnoYdMEQ2rs aR1ih/YI/PcqlRPPZdevq70esaZawPXkTgAnlXepQE5mD/oRP9qy2bd3H3Z2uFHwkExaunSpaoJH MW/evNdee23x4sULFiyYOnXqBe20Wm1BQYFWq72gJ8P4/Msvv/zDH/4wVZ4xY8acOXNmyZIlDz74 4Lx58wCMHTv21KlTF1100aDrGIvqVjwjWV6IBd79/VM3LF9dft3hdQCg0yFx9I25KzfZPIHV36rQ o7Gq6F9lpePu0Rblva2N9c8c+srd32oDzELk7ucmcNymW+QnFg1xw3369OnCwsLOoZsFWdznGrqT J09yHPfwww9nZekqONSWkuvfhN6orF4HDhy4+OKL9+zZk+2CMMaUs3xDPQCU9cNu//3f/z169Git Vjt69Ohp06Y99dRTXY6wXXnllYHAAMYO7s5XA3C2sMwYizqN4Kx+Jvp5wClElEt0XUGRyRGXhQN4 T1gOu80A5wpEZTFgAWDxioINnE1iLOK1otu41INw/PjxCRMmDHEmQ5TzLTNb8aOm4GGq20anqK9e Q4mfQY4XLgYdNSae5w1mmz85oofsd6Z6x5m9oUEmUNaDhzF2+PBhAPfcc8+f/vSnHieorKw8dOjQ UBYhhz2GjjVt9ISkZD9DcD4xbGt/jTdZjBwAW5RF6yx8avX6o7LY0YNUdJoA1Jx3TK++BYPByy+/ fGjzGCo1tMzMx4/KgoepcRutUGW9Bh0/gxovPFwDgLe4vR6rAYA51H4Bg8MflsSQw5QcP2mgRkLw KLrfUqSzb3/72/v37x/yQqRwKBQ6ZyBqub0jodL/U+k5KontvQvFaCQSTdegQYcPH541a1aaZt5P KmmZmYwf9QUPU+k2mqm3XoOLn0GMF/6htwYwJZ+Sg/Yae1BiAacplTehOqMyLO+AjJzgOa977rmn trY226UYZi+99NJtt92W3TLkzLgGfSspKWloaHj99dctFktaF0SdC8hIMHfu3F27dhmNxr179w5u DuOA+N+jSMTj8fixxv95ogFLvvn16Rc3bNzaEAOA2Bv/sbHhq5fG/uQHTry0tXqWRrPsB7u/9cCa 8kJUrKhlr9xVCCSO7Vu9fCdX87W+hpnqJrd661155ZUffPBBtksxzD788MPp06dnuRDZjb7hle69 H1Xu8ShU9k1IUWu9FAPd+xnEeOHKQAMwWl3uOjMHwNRxfYkUMAEwOQe005NDezwKuodCmqitZaYv flQcPEy922i11ivlwIEDpaWle/fu7c/EXc73nDNeeHKSoBmweCIRtxmoiTAm2A3KDbEYYyzq4dAx xFTIZQbMwYGUNueCh9G949ImV6/v6Y1y8I3neQBbtmwZrtmq/lCbcneDbJdi+KmyUp0pB9+WLl3q dDoXLlzY/ze2jxfe5WhZ+R1Wfq7DMT72pMERKAP+1iaCm5CcSF82FbhIl9xo6IorzNYpk/q9xNw6 1JZSUVHx6aefnjhx4itf+Uoml9u4dVZl23b26Jxhn/MXX3zx7rvvVlZWDvucBya70Zcmw7v3o+49 HqIC77zzzsUXX3zevZ+ufQ16ukxETo4Mm7xLqXIBitUdkJnktRuRunM8YxHB7XD1dtO+HkqYc3s8 KbfccovT6czwQiMBr1dIyzZn9+7dPM+nY84DopK+Bl0MY9cD1e/xEBWYN2/eq6++unLlyjfeeKOP yXS6AmCc8vc4oEDXw2EPbfm3rTxg3HhNGQAUVhj9DvPGxTN0mqIb1u60eWwz2wd0Od6wdbXhbakf xcvRPZ6U+fPnezyeAbwh0fLq1jXKsYTqHW8pN59sbd6zpkqj0Wiq1mxrak0AaK5/ZM3WHVtXaW7+ vz9dNqv6YKvy5lh99bLqF5vFDw/s/+AkgETLwUeWzdJoNJpZq+objwFA/OiO6mXKMy8ePDbQ6uzb t6+qqmqg7xp+2Q6/NBr63g/t8ZAc0s+9n0GQxWgkcs548P2X03s8ij//+c9Tp07t//TdBq6OsoiH A/iaOiHgtfAAZ20/lwYYa1zv/N4ImOqCjCV7edgF0W/jYPUxFrIAMFj9QcFhAmAOylE7D3BmjyC4 rEYAdaGBjfz9j//4j1k/2cPU19egi6HEDwUPyTnpi5/BUUHwKL7xjW+43e5+Ttx94OrOXTakUB0A V0gW7Dx4u3L5qMeSvEQ35DIBljBjfhvPWf3KZbzK8U8mCRZjzaF3HQDqgsoPgXANYLAL/a+Iz+cr Ly/v//Tpo/LsYYONHwoekqNGTvyoJngYY7W1tbfeemt/pxaFmo6Rcmz+iJzsqt6JzS/6O92XT1JO xUmi0wDeLrCO7LEpUZQiCY4uszLY/P2vyN133221Wvs/ffqoP3vYwOOHgofktJEQP2oKHsaYKIrF xcUnTpzo18ShQDAiyWJE8NaZAM7q99t4cLaILIuiJEVDHrc3IrPO2aMcWzPbbDzgCssslT1+G2AQ krfzC9pr7IffsQGcJyzJoihJouB1+0P9HXonFouVlJQcP358wPVPg7zIHjaQ+KHgISqQ3fhRWfAo NmzYcNddd/Vnyu4DV0e8NQDnFCKMSV4bDxgCXbOH+ZXTP4bkUbjkq1EvB5idfomJXhsPmIKtfgNg sHklxiJ+BwBrv28xXl1dfe+99w604mmSL9nD+hc/FDxENbIVP6oMHsaYKIqXXHJJf8a07mHgaia5 rR3POfwRxphwbvbIIRcHWNrH00u9GnJbO47UeUKMsYjP3nHAzerpZ0+D5ubmkpKSlpaWAdc8PfIo exhjJ0+enDlzpsVi6fFVCh6iMpmPH7UGj+KXv/zlvHnzEolEP6btPnA1k6KRcCQiDqxXmvJOMRKJ SvI5z4TDkWi/53X27NmFCxf+53/+58CXnS75lT2s9/ih4CGqlMn4UXfwKP7lX/5l6dKl/YufkeLs 2bM8z996661nzpzJdlk65F32sJ7ih4KHqFhm4icfgocxJsvyggUL/umf/ikaHerNQzNDFMVbbrll 7NixX375ZbbLcg51jmvQt5KSkv3797/22muPPPIIaOQConb9HPVgKHJ95IL+02q1e/fuHTt2bElJ icPhUG57OjL9+c9/fv7556+++urS0tKTJ0/qdLpsl+gcGsZYtsuQHdFo9MYbb/za17727rvvUvAQ 1Ttw4MAghhzt55zzJHg68/l8Npvt8OHDwWBQluVsF6crnU43derUysrKe++9VxlbeaTJ3+wBEA6H q6qqGhsbx4wZk+2yEJJ26Yif/AweMnTqOObWWrtq2YvNMQDxI/XLVu2IIXFwR7Uy1t6rza0AWpvq leH4Vm3bF29/26RJkz788EMKHpInlINvK1asePPNN4dlhhQ8ZNDUkT3FV013WV99H8D7u592TS6P 79s0d3VRQJTCT800zFjXnIj9j3G5/tEQk4MXr5+/vSmW7QITkh3z5s3btWvXnXfeOfT4oeAhQ6GO 7ME1yx3Cxjda0fq79Q32f7mm+Q+7YRz/YcMbf2y9iIPQIulKOexc/uNtr3x0dzBy/8wB3V2eEFUZ lvih4CFDpJLsKazgzah373M7YV5UgRMfCvzFhaei0Wi0oNqx+VJd4e3PRHzu+R+7NnJXTHiW9ntI fhti/FDwkGGQ7U7ew8ZvMwDgbT7GWMDOw+xmjLGol4dRkEJmcJ4oY4x5zDDWhVLvUtMaIGRABndF Tp5cx0PSTT1bXjlUB8Cp3NZCCli4ZLia6wKMMb/dCIADAGPnkfcoe0g+G2iQUPCQ4aKePtaxptpx 3OdRtqE4+USitaVVqy/WFyZvDBxvbYlKKJlYVtjpXRqNetYAIYPQ/wNodKiNDCOVbHmbaldxa3fa fNF1c4rPP3UnlD2E9CdUKHjI8FLLljcRi0lFer12oO+j7CEE54sWCh4y7PJ9y0vZQ4iit4Ch4CHp oJI+1oSQIeqx4zUFD0kTyh5CSFKX+KHgIemT70ec6JgbIV0okVNbW7tmzRoKHpIm+b7lpewhpDuf z3fTTTe9/PLLCxYsyHZZiDrl+5aXsoeQHlHTIGlF53sIySfxpkeWrXlkzTKNRrNs6544AMT2bF2l 0Wg0muQNRwjJAMoeQvKK7HNtl27aHAl5xI0b32nB0fr7F2+cHhSloHu6Yca65kS2C0jyQ77vVtOB BZJfYgeXXfd7x+ENxYjXziqKbP/rBNOlnzvEDbP1QGzbrHEFL0lrKgpBTYOkGe33EJJnSpURDeU2 oEAHlKJQp7yQiIMrLRrw4CCEDAJlDyF55mS804Ox31rGr//1IQDxI+6NQunlX6HsIZlA3zNC8kxy vwcFAKCdufpnpnGVmi0AYKkLzC7s/Y2EDJ98P6RLB7UJAeItLTFtYXFxp9F4qWmQtMr3rxc1MEJ6 RE2DpBWd7yGEEJJplD2EEEIyjbKHEEJIplH2EEIIyTTKHkIIIZlG2UMIISTTKHsIIYRkGmUPIYSQ TKPsIYQQkmmUPYQQQjKNsocQQkimUfYQQgjJNMoeQgghmUbZQwghJNMoewghhGQaZQ8hhJBMo+wh hBCSaZQ9hBBCMo2yhxBCSKZR9hBCCMk0yh5CCCGZRtlDCCEk0yh7CCGEZBplDyGEkEyj7CGEEJJp lD2EEEIyjbKHEEJIpmmzXYDs+NOf/vS///u/yt+1tbUAZs+efc0112S1UIRk3+HDh30+n/K30jS+ /vWvf/Ob38xqoYgKaRhj2S5DFmg0mgsvvFCr1X755ZcXXnghY0ySpLNnz2o0mmwXjZBs0mg0Op1O p9N1bhpnzpwZNYqOkZDhlKffp02bNmk0mtOnTycSidOnT585c+ahhx6i4CFk8+bNF1xwQappJBKJ 9evXU/CQYZen+z1//etfp0+f3tbWpjwsKip69913p0+fnt1SEZJ14XC4vLw81TRGjx596NChq666 KrulIuqTpz9nLr300pkzZ6YeXn755RQ8hACYNGnS7NmzUw8nT55MwUPSIU+zB8C6devGjh0LYOzY sQ8++GC2i0PISPHggw/q9XoAY8aMeeCBB7JdHKJOeXrMDcDp06dLS0vj8XhBQcGJEycuuuiibJeI kBEhHo+XlJRIklRQUPDpp58WFxdnu0REhfJ3v2f06NEGg2HUqFELFy6k4CEkpbCw8Lbbbhs1alRV VRUFD0mT/M0eAPfff//Zs2d/8IMfZLsghIws9913HzUNklb5e8wNQCKR+OCDD6688kqtNk+vsSWk R2fOnGlubp4+fbpOp8t2WYg65XX2EEIIyYqR+Ht/1KhRqkxEjUZz9uzZbJeC5DBqGkQ1RmL2MMbU 2sCyXQSS26hpENXI674GhBBCsoKyhxBCSKapKnuaapdpqmpjPb4Wb6zSaLY1tiLR2vhWY2ui0zM9 SbQeOdh4JJHO0hKSMdQ0yEgzEs/3DIGIk728Ujj1Z27P6Kl6QKi8odIvseKOZ3ryyW/mVkJiG1S2 gki+oqZBRhZV7fekNNc/smrztq1rqjQazaxV247EgYT49t5dociHmxdWAqicU93UKr69d1comgDQ /Oq2Ko1Go9HMWvbIwWOJeHP9Qm4jsPE71S/GgNbmPWuqNBqNpmrNtqZW+sFHchg1DTJSsJFn0KUS 7Dw4u8iYYDcAMFhdPo+DB3ibn4l+HrD6/yq4bRw4m8sXbVWeicpBJwCz0xsK+m1GwOCIiSGXzQQY Xb6gHPFwAF9TJwS8Fh7grJGM14sQBTUNohoq3W9uE2Gsq9+wVAv8zPrE6jigA4BCjJ25gC/FK9ct nFOMRgCFAEpmu1w+fumconjr12bycIqyfsp3Fl4NFCycUx6ofUhATfjR2ycC0xx1Wy5bfuDoD5dO Uel6I6pHTYOMDOo85iYD3DWXK41AV1h6zmsJGYAsdzyh1eo+bbCM02h0RSXzNzagtEALSDKANhkA 9MCmSRqNRqMpumw5gNBJKUPVIGS4UdMgI4Q6swcA4sn/5Z5e7DxIVfNvHlr75DRvKCIzFnabcbKt 85RyWxicLSLLoihJ0ZDH7b2T6+UcLCE5gZoGGQHUmz29kQE0NH/U0vFEG4DSSyeVJY4dfGzxkyhF PDnZ8UgsMfnrPIRn3wy06vU49MLq+Yt/3lt3IUJyGzUNkkEqOzg7DqVA8gh2UvvfuklAgU6Loovm cljJLSiP7FSembbgbh6Gy3RbAJgtJmxZv2DbdQeXTATWXzHukij7kdvqX8xNWAkAcPgjFSpbZyQv UNMgI8tIHMdao0l3qRLxOAoLOzWURKwlEi8sKdMXIhGLJYr0hVok4vGEVluo1QKIt7ZEE9AXl+mH 0LrSXy+ictQ0iGqMxI9crV9EtdaLZIxav0JqrRfpQ/6d7yGEEJJtlD2EEEIyjbKHEEJIpuVk9sSb d2g0yxpjQLxxleYc1TsOnmdUqZa3VlU90hTveyJCctIgm0bsyI7Na6qqqpZVb2tsoWHZSCbkZKdI WW4DROXvGGB2+h6Yc5Es41hj3fyVc4suCf9k0cRe3tqydcENOwXDA7IyZgghqjKopnFs87grNvEW 92PfE34+v3LCxyH2xJQMl5vkn5zc7+lMBKbOnFVeXlFRUVG1wuLgsfvdQ9tWVW3dc1SZ4Ni+rVVr dii3Ijm49XsbBQ7nXuWgOPrWjuR4vau2NrUm4s31y2ZVH0zewSRWX72s+sVmINH44uZZGo1GM6u6 dl8MQOLI1lWrttZuW9b7/U4IyYp+No2P3np2E0yhfT9ZdH3VhvqgvaYice5RAWoaJC2yNYhpH85b KlGwA7xfZEzyGwCrN8xkSZKksN/JARbPUbcZ4B0iY4yJDh6o8TDGoj4bYPCH/UbwPvHcGQYcAEx2 Tyjoq+EB1IQlwQiY6oKMMRb1coBdEIN1JgA2l8/vsQMw2AUm+g0AALPVIUTkIdaLkL6lo2n4bQbA YLWaOcBgsgnRc2dITYOkx0j8yAfUwIxdstRgDUpM9NsAzhtNtg1nUFJagtUnMibw4P3SOTP0WTkY nMn2EfVygCMgeiyAwSExFnKZAEuYRW0ceJtfmcpvRnV8tAAAB9hJREFUN4CzRSW/ATC7QsNSL0L6 lo6mIdiNAGC0utx1Zg6AKdCpdVDTIGmSk+d7OosBFpdQ/Y1xp2UAoydNKdMCmL3EjPXuP7VUfPlb ATU3laN+TaULpnWjw41v+U/i5KH9B0vnVE4pVqofe3ePwH9vZnJdFI2fCkROJ+640w7u+ffjtzU/ t523CxPjnxwS0LC+UrO+fdn8YihHNqaWZL7ihPStf02j8PjvYkBN+IUNE4Glczz7Sua/+v7jFbOL lXlQ0yBpkvPZIwKXTL2sbGKXAXTL77Dycx2O8bEnDY5AGeQvwYPzzedmKC+vXTzX5o+uK1YamO4f pqEh8vfkW+XTHwPLRmsLKxZZsPaF7Y7DLpifngHt0dGAqS7wy2WXSQnEQ4f9LRfpcRoAZOoaREac /jUN/K1NBDchOZG+bCpwkS61WaCmQdIm2ztePThvqTofWOABmz/afRo5WAcA4DxdbqYo+bsfcwu5 zADnCkQZE10WDjArRwr8dgMAGOwiY4zJLhPAWYMiY2LAAsDk7qMAg6gXIX1LR9OQAg4AVndAZpLX bgQMQqfWQU2DpMlI/MjP+0WUAg7AkDqhahfEnqaKWHnA6Oz6muTnu/U1YCzqNHPtcczXtZ9vlUMu DrC4249Zi4IlNRVXE5AYkwQjYOu5AAOuFyF9S0/TkP0Oc+rHqM3T5QwNNQ2SFiNxCL9sDSwYazkW PY2SSRP7HJE30doSSWj1xcUDHreXBkwkQ5S+r1Ai1toaT2j1ZcU9XfdGTYMMu5H4kav1i6jWepGM UetXSK31In3I+WtLCSGE5BzKHkIIIZmW832s+y95RFurL+7xkDYhhJBMUdF+T9eBe5fV7juSem3f tjW6cSUTJkwoKSnSLNvcfbDepm1Vs7Y2It5YpQw/lWhtfKuxlS5OIOoXP1i/bdWyqqpla15862hf 06UGySZkyFSUPUAMMDm9wWAgEBDqrPq186+orj8C4NiemvnrfU5fUJSkSNBrdm2q/N7OLndRkJX/ Cqf+zO1ZOFUPfFx5Q+XHlD1E7Rpr75i7/Nlr7v6xuQorb7hsR3Ov9xfRAoAoZ65oRM1UlT0icPXM fywvr6iomHn7hhd8Vv7J5VuPJHD8Qx+4e26eU64vLCwrv35LwGmc1hbtMVcS4tt7d4UiH25eWAmg ck51UwyIH91RvUwZyPfFg8cyXClC0ijeVLPWZRMOrltatXRdrc9hu0Qnx4/Ur6qurd9RrezlHN1X W6XRaGat+tETTwDjuo8BT8ggqCp7gHPG8Ji1+HvAR59JuORrPIT146rWbHvx1cbmo/IVK16oXTOx x1Nd0slXnnxS+EK/bIONA2fbfMdXi1prv3PZ6n1TPYLgWomVcyfVH6W9IaISiRMfuIDP39m2apZm VtWqIzNuX1Sul0+f3Pnk2uWrP7Y51+mFbZfNXzvJ6vI9NX/fdiHb5SXqobrs6UQ5OKADJlY9GvQ4 zeM+Wr/SUDnjsnE6zSP1TUDiWHNTU1NTU1NzS+owgw4ACjF25gK+FKXXLZxTFHStbUDdb7dUzZy5 dIO1Bti5J5ClChEyzCTxJIBNa/fM3+yunhtbOXfS1oMtAADOE31l3YqqmP8VGJyODUvnXH/X235b 6sZ0hAyRqvu5yW0AZCDW0jLhhhVPVK14IhE/dvTwrqcsa5evN4i/+f0MbiMAwOqPLujy3oQMQJaT Cbb8iqLUK4Y2OuJNVMUZeH1FRSGWXtu2e9zTv//LfYsBlI7XAoj/5VADV/Wz5GZCV5DNUhJ1Ud1+ T8cQvPG9tesB/nJ9668mTBj3i0YA0BZOLJ+zZtOPgYYTUf06MemHyRHju81MB1kWAc4TlmRRlCRR 8Lo3GaZlqC6EpJlOVwCgpFS56kBXUIouN/X9EhA+/6J94gyXjqiZqrJnHPCe/1Bzc1NT41s7HvnO 8u2weu8pQ/G3rTw2rq5960g8kYi1Hq3/6X8Ahqlf0Rbqk3rY+5MBNDR/1KKfdp0Bwrb6Qwm9Pvb+ b7gbFv/uOJ3vISpRWMFbgI1P1B+Lx1uaXnuiAbfPm6y8JANA4bXLTdj0QH1zK+JH/+s/1wLjsllc oibZGsS0D4MsVZcbNXIGuzvQ/lrYaeY7vcY7fOEu7xZsPGf1K4Pv2gWRyUELB4DziSzis6feabB6 znP732GvFyHt0vEVEgOuVNsw1LiiyRsxpO6kEHGakiNUc0YDYOxy/5FhQU0jD43EIfzSNLBgvLXl hHhaN3rchLLi/p3mSsTjKCzUAkA8diwaLxrMEL0daMBEMkTp+gol4i2RKIpKeh7FGmhtOZbQ6suK 9T2+OnTUNPLQSPzI1fpFVGu9SMao9Suk1nqRPqjqfA8hhJCcQNlDCCEk00bi9T3KUKDZLsXwU2Wl SCZR0yCqQYdZCSGEZBodcyOEEJJplD2EEEIyjbKHEEJIplH2EEIIyTTKHkIIIZlG2UMIISTTKHsI IYRkGmUPIYSQTKPsIYQQkmmUPYQQQjKNsocQQkimUfYQQgjJNMoeQgghmUbZQwghJNMoewghhGQa ZQ8hhJBMo+whhBCSaZQ9hBBCMo2yhxBCSKZR9hBCCMk0yh5CCCGZRtlDCCEk0yh7CCGEZBplDyGE kEyj7CGEEJJplD2EEEIyjbKHEEJIplH2EEIIyTTKHkIIIZlG2UMIISTTKHsIIYRk2v8H5K9XZnIN pHgAAAAASUVORK5CYII= --e89a8f22c70535b6dd04bf832e07 Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; name="Screen Shot 2012-05-08 at 10.50.04 .png" Content-Transfer-Encoding: base64 Content-ID: <12B5505F-66D7-4CDD-A6CB-9EA466AAF93A@cisco.com> X-Attachment-Id: be2604c289354f54_0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAAkIAAAJrCAIAAACDZmupAAAX/GlDQ1BJQ0MgUHJvZmlsZQAAWIWV eQdUFM/Sb8/MBpaw5JxzkpxzziA5KzlnlhxUQECCgoAiAoqCiogKokRJoqAIfwQUVEQliARRMSAo IG/AcO+733fPO6/P6Z7f1lRXV1d1qNoBgO2WZ0RECEwDQGhYNMnGSJfHydmFBz8JEMAICEAASHt6 R0XoWFmZg/9avo0DaOf5WGJH1n/n+18LrY9vlDcAkBWKvXyivENRfAsApMU7ghQNAHZHnkBcdMQO Po5iBhKqIIov7GD/X7hlB3v9woO7PHY2eiieAoCM0tOT5A8A1TJK54n19kflECkBwNGF+QSGoaw8 KNb0DvD0AYDNA+XZExoavoOPoljE69/k+P9fMr3+yvT09P+Lf81lt5DpB0ZFhHgm/H+a4/9dQkNi /ozBhVbKqGBbM/TJhNot3tvTwBbFLCjOC/A1Mf9NvxQRrWvzm94eGG1it2MjFD8JiDG2/40XYoLt dVDMgeLN4HCzHX7UTjBLmNdeSxTToVjAO0rP5ZdMWDExwM7xN4+5j6++AYrRVQQ7kcJt/vAHRMXa /qEnJgbo7f3DH+RpuuNvIopzPEm7c0F1gEt8Q4x2xuVD8dWIaCu732MNhYXs/T0X+I0fydDmN/7h G7U7392xogPsjH/JR2ii0QXwSybC4RdoaPJLB0Q6gGT8h64dEbK7ptG+iB0pxmbHDgIo9vMNs/8t E8nx8dQ3+2UTpBwYAk9AAr7AC4SBLcADzIEe0P/d8qD0MLT1BuEgBK0kHuo/b7BvsSPYGewYdgr7 /C+33h8+EAh80Ocfuve/0W1BIniPSvUFUX9Gw7BhNDFqGHO01UarLEYZo/Ln3dBy8/JfrX7p6o/2 lfhN0f2tfey/a+8emEb6jz5ef3v8T50MwZtdqb85pGulF6U3//T/14xxBjh9nDHOECeKZCE3kfvI HaQfaUeaAQ/ShbQgg0jHDv6PUTx/W4W0O18zdERfELP7K+x/1SjmL8dvKlGMqABsdvmD0XeBf0dw 2NU68H9IiUGrFyopCH1n9neOfywthFpXAaOL0UDtjNoYw4RhAxIYedTiOhgt1AcKKFXvP3v9biWA 364tY3fnEgzeojg02jc+emeh64VHJJAC/QOieXTQ09J3D49JmLfkHh5ZaRlZsHP2/traX2x2z1SI 6dG/aOEyAKjsnJWH/0Xz+ABAcxB63ND9iybUDAC1LAD9p7xjSLG/aJidBgvIATW6+lnRk4MfiKB6 ygJFoAa0gQEwBZbADjgDN9S6ASAU1TgOJINUkAlywXFwEpSCClAFLoNroAE0g3ZwB/SBATAMxsAL MAXmwDuwAr6BDQiC8BAVRA+xQtyQICQOyULKkCZkAJlDNpAz5AH5Q2FQDJQMHYZyoUKoFDoP1UA3 oFboDtQPjUDPoWloEfoM/YARmBJmgDlhIVgKVoZ1YDPYDt4P+8ORcCKcDufBJXAlfBVugu/AA/AY PAW/g1cRgFAgTAgvIoEoI3qIJeKC+CEk5CCSgxQjlch1pA1di4+RKWQZ+Y7BYegxPBgJ1JPGGHuM NyYScxBzFFOKuYxpwtzDPMZMY1YwP7FUWA6sOFYVa4J1wvpj47CZ2GLsJWwjthfdz3PYbzgcjgkn jFNCV7szLgiXhDuKO4Orw3XjRnCzuFU8Hs+KF8dr4C3xnvhofCb+NP4qvgs/ip/Dr5NRkHGTyZIZ krmQhZGlkRWTXSHrJBslmyfbINAQBAmqBEuCDyGBkE+4QGgjPCLMETbIacmFyTXI7ciDyFPJS8iv k/eST5J/oaCg4KNQobCmCKRIoSihqKd4QDFN8Z2SjlKMUo9yH2UMZR5lNWU35XPKL1RUVEJU2lQu VNFUeVQ1VHepXlGtE+mJkkQTog/xELGM2EQcJX6gJlALUutQu1EnUhdT36R+RL1MQ6ARotGj8aQ5 SFNG00rzlGaVlp5WhtaSNpT2KO0V2n7aBTo8nRCdAZ0PXTpdFd1dull6hJ6fXo/em/4w/QX6Xvo5 BhyDMIMJQxBDLsM1hiGGFUY6RnlGB8Z4xjLGDsYpJoRJiMmEKYQpn6mBaZzpBzMnsw6zL3M283Xm UeY1FnYWbRZflhyWOpYxlh+sPKwGrMGsBazNrC/ZMGxibNZscWxn2XrZltkZ2NXYvdlz2BvYJzhg DjEOG44kjiqOQY5VTi5OI84IztOcdzmXuZi4tLmCuE5wdXItctNza3IHcp/g7uJe4mHk0eEJ4Snh ucezwsvBa8wbw3ued4h3g0+Yz54vja+O7yU/Ob8yvx//Cf4e/hUBbgELgWSBWoEJQYKgsmCA4CnB +4JrQsJCjkJHhJqFFoRZhE2EE4VrhSdFqES0RCJFKkWeiOJElUWDRc+IDovBYgpiAWJlYo/EYXFF 8UDxM+Ije7B7VPaE7anc81SCUkJHIlaiVmJakknSXDJNslnyg5SAlItUgdR9qZ/SCtIh0hekX8jQ yZjKpMm0yXyWFZP1li2TfSJHJWcod0iuRe6TvLi8r/xZ+WcK9AoWCkcUehS2FJUUSYrXFReVBJQ8 lMqVniozKFspH1V+oIJV0VU5pNKu8l1VUTVatUH1o5qEWrDaFbUFdWF1X/UL6rMafBqeGuc1pjR5 ND00z2lOafFqeWpVas1o82v7aF/SntcR1QnSuarzQVdal6TbqLump6p3QK9bH9E30s/RHzKgM7A3 KDV4Zchn6G9Ya7hipGCUZNRtjDU2My4wfmrCaeJtUmOyYqpkesD0nhmlma1ZqdmMuZg5ybzNArYw tSiymNwruDdsb7MlsDSxLLJ8aSVsFWl12xpnbWVdZv3WRsYm2ea+Lb2tu+0V2292unb5di/sRexj 7HscqB32OdQ4rDnqOxY6TjlJOR1wGnBmcw50bnHBuzi4XHJZdTVwPek6t09hX+a+8f3C++P397ux uYW4dbhTu3u63/TAejh6XPHY9LT0rPRc9TLxKvda8dbzPuX9zkfb54TPoq+Gb6HvvJ+GX6Hfgr+G f5H/YoBWQHHAcqBeYGngpyDjoIqgtWDL4Org7RDHkLpQslCP0NYwurDgsHvhXOHx4SMR4hGZEVOR qpEnI1dIZqRLUVDU/qiWaAY0yB2MEYnJiJmO1Ywti12Pc4i7GU8bHxY/mCCWkJ0wn2iYeDEJk+Sd 1JPMm5yaPH1A58D5g9BBr4M9h/gPpR+aSzFKuZxKnhqc+k+adFph2tfDjofb0jnTU9JnM4wyajOJ maTMp0fUjlRkYbICs4ay5bJPZ//M8cl5mCudW5y7edT76MNjMsdKjm3n+eUN5Svmnz2OOx52fLxA q+ByIW1hYuFskUVR0wmeEzknvp50P9lfLF9ccYr8VMypqRLzkpbTAqePn94sDSgdK9MtqyvnKM8u Xzvjc2b0rPbZ6xWcFbkVP84Fnnt23uh8U6VQZXEVriq26u0Fhwv3LypfrLnEdin30lZ1WPXUZZvL 92qUamqucFzJr4VrY2oXr+67OnxN/1rLdYnr5+uY6nLrQX1M/dINjxvjDWYNPTeVb16/JXirvJG+ MacJakpoWmkOaJ5qcW4ZaTVt7WlTa2u8LXm7up23vayDsSO/k7wzvXO7K7FrtTuie/mO/53ZHvee F3ed7j65Z31vqNes90GfYd/d+zr3ux5oPGjvV+1vfaj8sHlAcaBpUGGw8R+FfxqHFIeaHik9ahlW GW4bUR/pHNUavfNY/3HfE5MnA2N7x0bG7cefPd33dOqZz7OF5yHPP03ETmy8SJnETua8pHlZ/Irj VeVr0dd1U4pTHdP604MztjMvZr1n372JerM5l/6W6m3xPPd8zYLsQvui4eLwkuvS3LuIdxvLme9p 35d/EPlw66P2x8EVp5W5T6RP25+PfmH9Uv1V/mvPqtXqq2+h3zbWctZZ1y9/V/5+/4fjj/mNuE38 ZsmW6FbbT7Ofk9uh29sRniTP3VAAQSvs5wfA52o0b3EGgH4YAHLir9zod0HQ4ANGn3g0UjBFI4BZ SAy9t7thVjgankBMkLsYI8wTbCiOFteDTybTJOAJL8lbKcop86mqiZM0NLRmdNn0/Yy0TPuYr7Ji 2DzZOzh5uI5yr/P68E0I7BXsF5YSyRN9J26yp0Lim5Se9DGZYTkqeV2FKMVypW7lKZUtNWZ1cQ0V TQMtG21vnSjddL1T+rUGXYaPjRaNt00ZzfaY61m47g20jLXKsC60qbCttWtGd/2A46jTc+fXLrOu C/ve719wm3Qf8ujyrPM6633MJ9HXz8/aXy1AIJAY+C3odXBfSE3osbCIcNsIpUi2yE3Sq6ju6KqY jFi/OJN48QTyhKXEwaT65JID6QfjDkWmkFIT03IOn0/vyHh9hJClnh2RU5U7fow8Tz0/9PjZgqHC rRN7TroW55xqKpkqpShTKHc/k322oeLFeUylRJXDhUMXL18aqV6v4bliXpt8teHapzrV+vwbH2+6 3nrUZNn8pFW9Lfp2TftkJ0WXXLfDnciejLsF94p7i/sK7mc9ONx/5OGxgWODGf9EDzk+kny0Mdw9 kjSqOPrt8dMnrWOl4weeuj/TfS44QZh4/2JksvFl6asDrz2m9KdFZ2hmvs++fTM+1//2zvzthdbF 1qWL7/KWY9+7fTD4KL5Cs7L6aeJz55fzXzNWA76ZrUmt06+vfZ/80b1RuZm+5ftTf5tvexv1Pw6w odFhPOhFIzpz6Dj0GpZDY68viDsyjkZNL7EROCKuGe9LxkY2QSgn96fQpdSgsiMGUKfQnKO9Q7fI wMioz5TAXMfykU2SncTRzkXB7cBzhXebX0cgVbBLaFNESTRI7Iz4wJ7PkoxSctLGMq6y/nKR8gkK BxQTlYKUXVXMVTXUpNX5NBg1yTR/aL3XntYZ032o16l/06DasMQoyzjOJMDU2czYXNlCeC+jJcby q9WM9YhNt2293Vn7LIcoRzcnE2c5F05XnOsH9KTvcKtyz/EI97Tzkvem9J7xafXN9/PzVw+gDXgb eDuoINg3RDWUOnQ2rDk8K8I5UhxdF0NR56JJMXqxjLHzca3xRxPcEqWT4KSnyXUHcg+GHrJP0U9V TVM5rJFunOGUGXbkSNbF7Ls507k/j3HkqeQ7HI8qOF54taj/xNti+BRHieJp69LQstzyq2eGz347 x3feqvJwVeuFT5ckqyMv36pZq1W5mnytsw7U69w43NB7C9to1JTVfL8V32ZwO629o+Nrl1C37Z2k nrN3b98b613sW3uA6ad/yDsgNajxj/mQy6OA4biRzNGTjyuf1I21j/c/HX829/zrC2SS4aXgK+XX 5lP+01Uzi2+E51zeZs5fWbi/OL20vkx8L/hB66PrSsqn4S9yX4tWv6zZrN/6wbKRsbn+M27X/xhA C8TAXpACutG4XhWKhpphGLaAz8EbiBvyEKOOacIqY3twVrhZfBIZO9l9wjFybwp1SnbKn1QzxAHq RpqLtCV0efRZDBmMmUy5zEUsFay1bC3sHRwdnJ1cXdydPLd5G/lq+c8I5ArGCO0T1hbhEwWiL8Sa xXP3OEjwSCxJNkqlSJvJMMlMy9bKxchrKRAUHiueUQpQlldeV+lUzVAzU6dTn9Co1AzSktXa1O7T KdDdryemt6Z/1yDf0NVI2OizcadJjqmDGa/ZO/Mmi5S95pZMltNWtdZRNmq2sO1Du0J7Fwceh3nH 604xzmousEu/a/4+2/1M+5+7lbnv9+D0eOl5xmu/N4f3hE+Jr4Mfvd8j/9wAg0CArpfYYJng5ZDq UK8wjrCn4UUReyPJIu+QEqPkopajL8a4xTLHPoo7Eq8Vv55QnxiYxJP0PPnEAbuDrAfnDrWknEhN SPM7vC/dOcM10/dITFZGdnHOpdymo33HxvLm8r8WIIX0RXwnpE+qFuudMi2xPu1c6lUWXn7oTNHZ qxUD5z5WClYlXBi+JFx98PL4FYna9KsvrsvUZdW/alC8mXvrdZNc85GWyTa52zntM53qXSXd33rs 7jb2CvddeCDR3zsQ/I/A0PLw/dEbT2rG65/dmXj5EryWnq5+kzmfs9T8gfpT1irLeuOm447/f/1H tlNwigBcnAXA4TwA1q4AVIsDIFgGAJEBACsqAOxUAKybD6DnpwFkdP3v/UEFhIEhmg0fQTPHfvAO IkIykD2UCJ2B2qEX0Caa32nBXnAmfAV+BH9F2BEdJAA5jrQiMxgKNMP2QDOyFswbLB1WCxuGPY8d w5HjdHDxuAbcMl4E74+vxi+SSZLFkHURKAguhKvkELkTeQMFkSKMYpRSmfIcFRkVieoV0ZTYSi1C XUpDRZNKs0YbjuYr3nSv6b3o5xlCGb4xpjIRmc4wSzHfZXFlWWUtYJNhe8wex8HJMcx5hEuXG3Df 4cngteBj5Vvgvy1QIBgkZCgsKEIpsio6IzYqfm9Pm8RNyXqpOukGmRbZbrkB+VcKn5Qwyowq/KoS ajLq0hpimjxadNqw9kedF7pdepX6WQbhhk5GusZSJlym1GaI2br5isXS3jnLGatp6zc272y/2G05 EByZnYSdVVwsXL33Je0/6VaP3mPvvYjecj7Ovof8qvx7A2YDt4LpQnhDxcIkwyUiRCP5SExRhKgf 0YuxbHEW8ekJXYk/kw0OFB18l2KRevuwfHprpsmR2ewjubxHr+dp508VFBQ5ndQ4ZXI6rqz3LPs5 YiVc9f3i5+oPNcu1y9c+1q3e2LpF1sTeItWm3+7cGdgd23PwXkrfgQexD0MGPYZyh1tGl8Z4n+5/ XvHi7SuZqdSZsTnx+azF+WWjD1c+0XxJWn2/7vdjfiti9/ygBpLAGsSAUtAF3kAUkCzkCqWjGf8A 9BHN7lVhDzgLroefIwiaszsjGcgN5DWGCj1VgjFlmH/Q/FsG64MtR/1OjTPHZeMe4MnxFvhC/ASZ IBmJrIfARAgh9JHzk6eRz1GYUrRRilNWUDFSHSXiiGnUgDqVBqHJoiXSnqLjo6uj16YfYwhlxDFW MukwzTBnskiwjLOmskmzTbEXcRhzYjh7uA5zG/JQ8ozzVvJF8RsKcAmsC44LNQufEzklWiCWJ563 p1CiVPKSVKP0A5lXsmvyjAqqit5KecodKh/VBNXdNco0X2hz6fjo1ultGBgY5hoNmGBNlcy8zDMt Lu29YzlhtWKDsWWyE7PXdnB2jHLKd77uMuT6aT+Tm4a7n0eBZ6fXBx9+Xye/fP++gK0g+eDAkLOh I+FwhGykBykv6nb0Qix1nFK8R0JuYkvS/AHmgyaHDqQ0pC4d5k/fn1Ga+SyLOds552zum2MSefH5 fQUsheFFgyeli8tKiKezyyjLT54Vrrh/PrCK8kLDJZfLmJr6WvdrNNfv1sc3SN1caKxuDmyVaPvc 3taZ1m3ew3x3trf+fnK/6QDr4PCQ/aPZkcTHXE+GxnOf2U4ITUIvZ173TdfO5s+R5m0X2ZcqloXf 3/iouTL02f3Lx9WUNer10z+4Niq22H7m7/qfGeiACFABHoFt1Pd+0GmoF/oC88E2cDrcDC8jvIgT ut/7MQhGE5OIacasYhWwsdgOHBZniSvDLeHV8MfxC2T6ZBcIZIQIwiS5OXk3hRLqaV3KQSpnqiXi QWpG6noaS5pPtMV0mnSL9GcYbBmpGB8yZTObs9CxTLBeZCOx63DQc7zj7OO6wJ3JE8xrx6fDLysg LMgtxC7MJsIjKi6mIm62x1MiWbJUqkP6jSxRTl2epHBd8aOygkqq6qi6iEa65lttc51mPXH9C4a8 RlUmoqaN5voWzywjrClt6u1c0f3a4RzrKr9v3a3b45iXm4+iH6X/88DSYJOQxbCE8M3IaNJctFXM zTjaeFLCkyTV5PMHKQ7Fp8ynOR0ezNDNbMuSz27K1Tjan+ec/67gYBHticpiqVOtpzVLu8rVzzRV YM+Znz9Z+fqC2MW4S72XGWv8rrRdJV7zud5ez3gjomHglgia+bxvsW5tvs3Vntnxocux+06P+N2T 97b7gu4/6dd+WDvI9E/U0MNh9pGA0auPl8b4xx2fpj27/PzhxNyLzZc0r7hfi08pTKvOaM5qv9Ge 03yrOq+0ILMotsT3jvhucbn1fdwHhQ/LHy+uOH8i/9T+2e8LzZeWr/tWwWrlN91vM2uH1jnWW7/b f1/5cXRDeKNn021zfavop9TP/m2fHf9H+cnJ7l4fEKUuANhX29tfhNCkohCArYLt7Y3K7e2tKjTZ mASgO+TXd5fdu4YGgPKq//b94/8AmJfCLqRoihwAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURB VHic7N1/QBR1/j/w1yDIDwVFBRVS/IVh5VB6qVlqC2Z6qUv+6Jd4XXYH9Evg7srwTr+Fn8ugOl2z XO2upRQvhc+da9fRx1pIrFzqlnIwl2xJuFyrRRddkF3chfn+MQiIKCwMzCz7fPwFy87sa3aW93Pe 75l9D8PzPAEAAHgmH6kLAAAA6D7EGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDE GAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGAAAeDDEGECrS5cuSV0CALgHMQZA //3vfx9++GGWZYcMGcLI0qhRo375y19mZ2c3NjZK/W4ByAtiDLzd9u3bp02bdscdd2g0mrq6Ol6W SktLk5OTdTqdr6/v6dOnpX7PAGSE4XH3Z/BiW7du/fOf/3zkyJGYmBipa+mS119//dlnn/3iiy9Y lpW6FgBZQIyB98rJycnIyDh27Fh4eLjUtbghLy8vLS1Nr9ePGTNG6loApIcYAy/1zTff3H333V9/ /XVkZKTUtbhNrVbv3r37k08+8fPzk7oWAInh3Bh4qfXr1//hD3/wxAwjoqSkpLq6ugMHDkhdCID0 0BsDb/TRRx+lpKQYjcaBAwdKXUs3HTlyZNWqVd9++21gYKDUtQBICb0x8EbZ2dmbN2/23Awjojlz 5kybNu29996TuhAAiSHGwOucOnXqq6++SkhIkLqQnnr88cffeustqasAkBhiDLzOX//611/96lce 3RUT/PKXv6yqqvrmm2+kLgRASogx8C48z+/ZsyclJUXqQkQwYMCA3/72t++++67UhQBICTEG3qWi oqKxsXHy5MlSFyKOuLi4oqIiqasAkBJiDLxLYWFhXFyc1FWIZtasWUaj8cKFC1IXAiAZxBh4F51O Fx8fL3UVohk4cODs2bM/+eQTqQsBkAxiDLyLXq+fN2+e1FWI6e677z569KjUVQBIBjEGXsThcPz8 889jx46VuhAxTZo06bvvvpO6CgDJIMbAi5hMpgkTJvj49KuP/eTJk0+ePCl1FQCS6Vf/zwDX9+23 3954441SVyGy6Ohok8mEWeXAayHGwItUVFSIEmNlOclX3Js5YVNZjcudFbiqykrKqmp7XgkRBQUF hYeHm81mUdYG4HEQY+BF6urqgoKCRFhRw89EGYbKSpPJZDQUpJ3ayC7f404ouT5kZ7H7RDuhFRQU VFsrTigCeBzEGHiRurq6wYMHi7EmGykms1FREydOjJm2MPlJBRXZXERENR9ua+6opW8rFILFVV26 KSFW6LXllJwhovK9GSlEtG76+vxyMYqhwYMH19XVibIqAI/jK3UBAH2ntrY2ODhYjDWFUNHRA4UT h5Gz7r+fbUgpStSoQolKti1flHouV2+adunIlLnxx8hQuHb4xvDpm5VZBtM/LB+8sGhW5ECjbcnM JYm0dY8ya8Vsce52hhgDb4YYAy9y8eLFkJAQMdYUTLRrZbqeJeI4jojG/3Cq1kGbU4syiy2PzAwj mmjK1U3K+vRHhf9mYvW7n5sWTLR2m+pve7IOfvfIc7PjFWRetGhahCiZSkOHDsWgIngtxBh4l8bG RjFWYyZWbTuWLKTQmZKdkbOURcu/IKKW/6nIaXcRV1rdeDPRqsnNaRUYwRIFEJGzgYganGJUQkTk dDr72bcIALoOH33wIsHBwSL2Wvwu/xARe6uCqNJ60UY0ZGhzjJmPf0rszWFNRFT28+XLGM/1zuWE 4p3zA/A8iDHwIuKdQwohrvzLsvKysrKy0sJNv5xVRErFL2IfVFDqBk2Vg1w1pdtX7mFX3DZ6zC0s 7dm5v9RFdObIrpQielIRTeSic3TugkWsREWMgTfDoCJ4EdFizD+YaOtcdmvzr4o0XWXm1IDgKXuK P42cOy4wlYhImWV6dg4F0D+0mZOU07euIiJKUusfnxpMRLc/mcilLLrL33DsuWk9L0e8S1cAPA+D L/+D93jttdd++umnV155pTdfxFF9xuqkwPCI0JaDRFdtjaXW7hc4LCw0oPV5DodvQIAoB5I33HDD F198ERERIcbKADwMemPgRSZNmtT79zQJCLsqTnyDQyOCQ9s/LyCAxFBbW1tTU4MMA6+Fc2PgRfrl LLonT57sNzezBugGxBh4kYkTJ1ZVVblcbs1/KHeIMfByiDHwIgMHDoyMjKyqqpK6EDFVVFRER0dL XQWAZBBj4F1mz55dWFgodRVi0ul0d955p9RVAEgGMQbeJT4+XqfTSV2FaOx2+5dffjl37lypCwGQ DGIMvMv8+fN1Ol2/+Z7Jp59+ettttw0aNEjqQgAkgxgD73LDDTcMGTLk+PHjUhcijsLCwrvvvlvq KgCkhK8/g9f5n//5H7PZvGPHDqkL6alLly7dcMMNR48enThxotS1AEgGvTHwOmvWrHnvvffq6+ul LqSnDhw4MHXqVGQYeDnEGHidiIiIu+66Ky8vT+pCeurtt99+/PHHpa4CQGIYVARvpNfrly1bZjKZ goKCpK6lmz788MNnnnnmxIkTfn5+nT8boP9Cbwy80axZs+Li4l566SWpC+kmp9O5du3abdu2IcMA 0BsDL/Xdd9/Nnj37888/98QpMLKzsw8dOvR///d/AwYMkLoWAImhNwZeKjo6+q233po3b15lZaXU tbgnOzt7x44de/fuRYYBEG7UAt4sISHBbDZPmTKlqKho1qxZUpfTJVlZWc8//7zZbA4PD5e6FgBZ GPDCCy9IXQOAZGbMmHHLLbfcc889PM/zPB8REeHrK8dju9OnT3/44Yd/+MMfOI47evRoZGSk1BUB yAXOjQFQdXX1xo0by8rKDAaDw+GQupwOjBo1aubMmXFxcc888wzDMFKXAyAjiDGAK2zbtm3Lli3F xcVjxozp+1dvbGy85557ZsyY8fLLL/f9qwN4IlziAdBK2gwjogEDBuTn5+/bt++9996TpAAAj4Pe GEAzyTOsRVlZWVxc3KFDh2677TZpKwGQP/TGAIjklGFENHXqVLVanZCQUF1dLXUtAHKH3hiAvDKs xYYNGw4fPlxYWCjPiycBZAIxBt5OnhlGRDzPL1myZNy4cdu3b5e6FgD5wqAieDXZZhgRMQzz97// /eOPP/7rX/8qdS0A8oXeGHgvOWdYC2Hux4MHD95xxx1S1wIgR+iNgZfyiAwjoujo6HfffXfFihVm s1nqWgDkCDEG3shTMkywaNGitWvXJiQkNDQ0SF0LgOxgUBG8jmdlWIsHH3wwMDAwJydH6kIA5AW9 MfAuHpphRJSTk/PVV1+pVCqpCwGQF/TGwIt4boYJ/vvf/86YMSM3Nzc+Pl7qWgDkAjEG3sLTM0xw +PDhBx54QK/Xjx8/XupaAGQBg4rgFfpHhhHRvHnzNm7cuHTp0osXL0pdC4AsoDcG/V+/ybAWjz/+ +IULF/Lz86UuBEB66I1BP9f/MoyIduzYcfr06T//+c9SFwIgPfTGoD/rlxkm+Omnn37xi1/s2LFj yZIlUtcCICXEGPRb/TjDBF988cV999135MiRmJgYqWsBkAwGFaF/6vcZRkQzZsx49dVXlyxZcuHC BalrAZAMemPQD3lDhrVIS0v79ttvP/jgAx8fHJWCN8LnHvobr8owInrttdccDscf//hHqQsBkAZi DPoVb8swIhowYEB+fv6+ffvee+89qWsBkAAGFaH/8MIMa1FWVqZQKD7++ONbb71V6loA+hR6Y9BP eHOGEdHUqVPVarVSqTx79qzUtQD0KfTGoD/w8gxr8ac//enIkSM6nc7X11fqWgD6CGIMPB4yrAXP 84sXL54wYcLrr78udS0AfQSDiuDZkGFtMQzz97///dChQ2+//XbLg2fOnJGwJIDehhgDT9LY2Hjp 0qWWIQRk2NVCQkLef//9559//ujRo0SUnZ09d+5cDLpAP4YYA09SUlLi7+8/c+bM+vp6ZNi1TJ48 +Z133lm2bJlSqczMzPzpp590Op3URQH0FpwbA09yzz336HQ6f3//kSNHEtGRI0eQYR06c+bM3Llz T58+3dDQ4OPjk5iY+M4770hdFECvQIyBx/juu+9YlnU4HETk7+8fGxtbVFQUFBQkdV2yU1ZWNmfO nIsXL7pcLuGRwYMHnz9/fsCAAdIWBtAbMKgIHuOll15qaZcbGho4jrvjjjvq6+ulrUqGPvroo/r6 +pb3ioh8fHw++eQT6SoC6EWIMfAM1dXV7733Xtum2dfX99y5c+hhXO2JJ544ePDg6NGjBw0aJDxS V1f37rvvSlsVQC9BjIFnUKlULT8PHjx4woQJO3bsqKqq8vf3l7AqeQoMDFy4cGFVVdUf//jHoKCg gQMHNjU1/eMf/2hsbJS6NADx4dwYeAC73T58+PCGhgZ/f//bbrvtxRdfnD9/vtRFeYYff/zxmWee +fe//83z/L/+9a/4+HipKwIQGXpj4AEOHTpkt9uXLVtWUlLy2WefIcO6bvTo0fn5+TqdbujQod98 843U5QCID70x8AxnzpyJiIiQugoP1tTU1NDQEBgYKHUhACLD/KFex8fHp18euzAM09TUJHUVfQf7 EUCAGPM6PM/31+ZP6hL6FPYjgADnxgAAwIMhxgAAwIMhxgAAwIMhxgAAwIMhxgAAwIMhxgAAwIMh xgAAwIMhxgAAwIMhxqBjjprqM2fOVNfUdnPxWoer82dBr8N+hH4PMQZXcVXlpMcFDguPjIwMHxbC JGSX1bjVlNXkJMcGhgS+WVaRE8tsKq3prTrh+rAfwTsgxqCd6m0Lxj22NVJrqLTZ7RZTccapdezd b1Z3fQWu0+/u4jJ15rVTo2Zt160cH9x7tcK1YT+Ct0CMwRVqSv+eWkR5Js3SaVHBAQFhE+dkHtQq 6NRPtURU8+G2ZIZhGIZJ31ZYS0SuiuzVCeu3Za+OZRiGSc8pcVFt/rOpRUQb09d9WFVz5ujHJ60u Iqoq3JnAMExsQva2TcnJ26pcVL43PX1vmfCi5XvT0/eWE1F5/vrk7Jzs1UzCtlIiV+neTbEMwzCx 6TsLuzko5q2wH8GL8OBlrr/TDSoFsSprR3/SqxREbK7eZCzWEJFCZeBtBiUREakLigvUSUSkMdpN OhURq9IWW+xWNUtZequN0xBRorrAoNMQEZFSb+MNKpay9JdftPlnTq0kIkrM1BosprwkIlJp9Qad moiUaq4n29X/YD8CCDDDPVzBz5+Ic3TwB0fZ5tSizGLLIzPDiCaacnWTsj6tTbqLiDIKzMkLI8gV pkzZZau3T5yrUNCBuxbMCQuobSAiP/quYAsl5WmSF/oSWfWWYbM+9CMiGs6SX/OLtv5sI4Xatjs5 mGq2PbZLoTKsXTqNaKZBXTD9zaKa5KmhffMueD7sR/AeGFSEK/mHENEVVwK4qvZu21lWLbSJzcc9 kdPuIu4bi4tsRKMig4mIfCMXseQgIpeTiJzOluXrvszl2JsnCEv6Bg25+jWrfyoSfnA2ELvw9mAi cpz+kqOi1OnC2Nf0FC0N9xd1O/s77EfwGogxuEL0rASidf8oaz2FcebjnatS36ynATaiIUObmz/z 8U+JvTlc+M3Z3Fo2dLzKgKg44i5cbg6dbZ4VIBy51373AQ0PuHIh36AgoqQ8o9Npt9ntFqO+4MV5 uMag67AfwXsgxuAKATH3qRSUwir3llTUOmorjuyMXLSZkjZNHzP+QQWlbtBUOchVU7p95R52xW1d a498p9yZRBuT8suqHdUlf5ieShQitIXc3w5U1LqqCnekcBTSfqGo+5Jo16aDVfaAYGfllimzFu2p xAh412E/gvfAJwraCVurNTqefHDVrEnC78rMvLc2LPUlenxP8aeRc8cFphIRKbNMz84hKosk8vdr /hT5E7U7G+NPROQbteLVgqwnF7HhRKRgibibRgRS+H1pilTlpJCNRIpEloReg1/ror5LX+Uy7mIn hawjImIzjaqFvbnV/Q/2I3gLhu+P90GH62CYLu302prqWrvTL3BYWGjbcSJH9RmrkwLDI0K7fgRU XfbhR6fCly2dFkBUfWR9+NxRNn5tMBG5aqtrXMGhoQHXXJerptri8g0ODQ3u9OW6uF39BvYjgACf GK/T981ETWn2sOnrlBnqB6LKV6VsTcrldj4yVfRX8bbmD/sRQIBPjNeRpJk4U1b4fsFn5T/ab1+W /MicqN54CW9r/rAfAQT4xHid/tpM9Nftupb+ur39dbug9+BKRQAA8GCIMXCDq6aipLTCRVRbms0w 2d2Y89xRnsMwCaW1RI7S1cwV0nNKrj0Bu6Mkf9vqhLi4hOS9R6p6sAVAJOV+FNTsTU/YdLCiW7UD tIcL7sEdp/931nSy888Fjl+q01E3vsfqdDYQ2YSfa4nScvVPzxzidNKZ0rz4VbMCR5lfWhhx9VKl Ox+alXJKpd2ysnKfcu64S0b7r2MCrn4adJVE+1FQlrN21VatYvzGDd0tH6At9MagwwnOiYjKD26L YxiGYWIT1peccTnK8xew64jW/TJ9b4315Pufnawpz0+ITS9pPpivzU9PSN9b3vUZzW1E46fGTpwY ExMTE/dIhkZBH3A/lO9dH5e+t3mpmpLkuNUHT/4nM0Wr4krWLo1bunanXqMa5ee89lq9mMz3Y5WD iBzlOexje4goBJNSgVj6diZikF4HO72jCc6dplwiSsstrjQZVIlESk2trVKrSiJK1OpNNYYsIpXV ziUSJeWZeJ7nrcUskZqzXX9GcxunJlIYbDxvNyiJsorNvNNut9vNhlyWKENntuqziFidhed5vjIv iSitvCKPiDLVWYkssYrEXL25q9vVr3ncfjQ5ed5pTCLKLOZyE4lVGbq6XQDXhU+M1+mgmbAblEQZ BWae53mnUUmkMlidVqNWq7fxvNNu1WU13/XDaVQRqe08b+NURCobz+syiJQaO89XapOIMsy8VcWS 4nILZVAr290upG3zl9jukEqZZbLzvNOURJSmreR5u0ZBbJbexqmJiEih0RZoMpRElKW3dGm7+jWP 2488b9cmEaUV8DyvUZDiGnds8bb9CD2Hc2NARO0nOL9A5Ovr92NRRoiyec5yUjzoS2R3ElFD2xG9 2Q+riX33hGN5+du7FGouomVG89TLz1AsutaL1hJlaLn0X4TUO4koKDIqzJeIaGJiJjv37S83K8Zs KaINmulk+5qIco3/fiQmgJbe2fBByJuHv39uZpjob0I/IOf9eObDjcpdlFUQXl5WeOwcFX1aVDp/ 1LSJ2I/QUzg3BpddOcF5+f/+PmVrdHGlxcnz5oI0OtfxvOcBUxdmUNHuXZq/ailtyRS3ZjS3EY0a Py4sIioqKiqque0jIrp9ZTpp97yjeZtjVfFRvn5+/kQ0rHnudD//4XTFpH3Qjlz3o81qJ2LXLZo+ hY3fyhHtSZ3+wke4GTT0HGIMOuZsIKLhYyPDXGdKXly0lYaTg4icRPSTpbbtBdVRK9TKrampRUq1 IsLX7RnNnR1cmx0QsyCT1aak7kracF8oUUCMIoNo3Zb8Mw5Hddm/thTRijvGiLqt/Zl89mPMI1t4 /hjP8zxvUyuIVRn43Y/gpi3Qc4gxICK/dhOcE1H0/DUK2jzOjwmMnBWUkURFqfO3lfoNiSDaPCnk zfNExDYvzC5cwxJlpCwUBrOWvspl0LpJIQwTMmXzVTOa+/n50+W7eYS0edErRSSkJxIpE+MnEhFR VIZRO3zzysjAwHB25fhM7dNzMBLVIZnvx1b+ROP90aUGcWDeF6/jxmQ/rtpqiyNgWFhwALlqa12B wQG+5HI4XL6+Ab7XP6vqxozmXeVyVFus1H6m9lbeNomRp+7HznjbfoSewyfG6/TXZqK/bte19Nft 7a/bBb0Hg4oAAODBEGMAAODBEGMAAODBEGMAAODBEGMAAODBEGMAAODBEGMAAODBEGMAAODBEGMA AODBcKMWr8MwDMMwUlchvn65UdeB/QggwLwv0ItWrFjx0EMPrVixQupCoEc2bNgwcODADRs2SF0I QAcwqAgAnfDx8WlqapK6CoCOIcYAoBOIMZAzxBgAdAKzzoOcIcYAoBPojYGcIcYAoBPojYGcIcYA oBPojYGcIcYAoBOIMZAzxBgAdAKDiiBniDEA6AR6YyBniDEA6ARiDOQMMQYAncCgIsgZYgwAOoHe GMgZYgwAOoHeGMgZYgwAOoHeGMgZYgwAOoEYAzlDjAFAJzCoCHKGGAOATqA3BnKGGAOATiDGQM4Q YwDQCQwqgpwhxgCgE+iNgZwhxgCgE+iNgZwhxgCgE+iNgZwhxgCgE4gxkDPEGAB0AoOKIGeIMQDo BHpjIGeIMQDoBGIM5MxX6gKgH6qrq/v888+J6Oeffz527FhISEhwcPAdd9whdV3QHY2NjU1NTY2N jQ6Hg+f5gIAAhmGkLgqgFYa8QXzJycm7du0aOnRoY2Ojj48PwzDnz583GAzTpk2TujRww7Fjx269 9VYhtBiGYRimsbHx2Wefzc7Olro0gFYYVATxPfroo4MHDz5//nxtbe2FCxfOnz8/YsSI2267Teq6 wD3R0dGBgYE8z/M8L3TIQkJC0KsGuUGMgfhmz549ePDgll/9/f1/+9vfYiTK4wQFBS1fvtzHp7WV aGxsXLx4sYQlAVwNMQa94oknnggICBB+ZhjmN7/5jbT1QPc89dRTQUFBws8DBgx46KGH/Pz8pC0J oB3EGPSKxx57rOXnmJiYCRMmSFgMdNusWbOGDh0q/BwYGJiUlCRtPQBXQ4xBrxgzZkxsbCwRDR48 +JlnnpG6HOi+Z555JjAwkIiGDBkyY8YMqcsBaA8xBr3lmWeeGTx4sNPpfOCBB6SuBbrv17/+dWNj Y0BAQHJystS1AHQAMQa9ZdmyZXV1dffee2/byz3A44SHh8+ePdvhcPz617+WuhaADuDrz9BbAgMD 8/LybrnlFqkLgZ76/e9/P2DAgDFjxkhdCEAH8PVnAADwYBhUhN5SW1ubkpLyt7/9DYdKnu6rr75a uXIlx3FSFwLQAcQY9AqHw7Fs2bKzZ8+++OKLO3bskLoc6L7jx48vWrTorrvuuvfee0+cOCF1OQDt 4dwYiM/hcCxZsmTkyJHvvPPO6dOn586dS0RPPvmk1HWB244fPz5//vxt27Y98MAD4eHh8fHxOp3u pptukrougFaIMRBZ2wwbMGBAVFRUcXExkswTtc0wInr44YeJCEkGcoMYAzG1yzDhQSSZJ2qXYQIk GcgQYgxE02GGCZBknqXDDBMgyUBuEGMgjutkmABJ5imuk2ECJBnICmIMRNBphgmQZPLXaYYJhCSL i4srKiqaMmVKX1UH0AHEGPRUFzNMgCSTsy5mmODhhx/meT4uLq6wsBBJBhJCjEGPuJVhAiSZPLmV YYJHHnmEiJBkIC3EGHRfNzJMgCSTm25kmABJBpJDjEE3dTvDBEgy+eh2hgmQZCAtxBh0Rw8zTIAk k4MeZpgASQYSQoyB20TJMAGSTFqiZJgASQZSQYyBe0TMMIGQZHPmzGEY5oknnuj5CqGLRMwwAZIM JNEXMcbzPMMwDQ0N/v7+ffBybnG5XL6+yPKuEj3DBEKSzZs3j4iQZH1D9AwTIMm67tKlSwMHDpS6 in6B72UFBQWLFy+OjIyUYYYRkZ+f3+TJk1esWFFUVNTbb4Wns9vt8+fPX7Vqlcvl6o31nzp1auzY sW+++WZvrBzaKisrGzly5L59+3pp/bm5uaNGjTpx4kQvrd+jVVVVPfTQQ1OnTg0ICJC6/evYyJEj Fy1alJWV1Uv/6aLrxRhzOByrV68eP358Xl7e999/33sv1ENlZWW7d+8mojvvvNPpdEpdjkz1doYJ kGR9oLczTIAk69Drr78+fPhwlUr1n//8R7YhYTabDxw4sGDBAiL64YcfpC6nc70VY8IQ4oMPPnjx 4sVeeglx1dbWrly5cvbs2Xa7XepaZKdvMkyAJOtVfZNhAiRZO1u2bBkxYoTRaJS6kK7atm2bv7// sWPHpC6kE70SY42NjUuWLFm0aFFvrLz3NDU1Pfzww8uWLWtsbJS6FhnpywwTIMl6SV9mmABJ1kKj 0YwaNernn3+WuhD37N+/PyIi4r///a/UhVxPr8TYSy+9lJ6e3tTU1Bsr71VNTU3z58/fvXu31IXI Rd9nmABJJrq+zzABkozn+ePHj48YMeL06dNSF9IdO3bsmD179qVLl6Qu5JrEj7Hq6urhw4d7UMe5 nW+++WbEiBFnz56VuhDpSZVhAiSZiKTKMAGSbOnSpS+//LLUVXRTY2Mjy7L79++XupBrEj/GkpKS 0tLSRF9tX0pNTU1OTpa6ColJm2ECJJkopM0wgTcn2aFDhyZMmNDQ0CB1Id1XXFw8ZsyY+vp6qQvp mMgxZrFYQkNDL1y4IO5q+9iFCxeGDRtWXV0tdSGSkUOGCZBkPSSHDBN4bZLNnz9fDu9/DymVyrff flvqKjomcoy9+uqrjz76qLjrlMSjjz766quvSl2FNOSTYQIkWbfJJ8MEe/bsGT16tFcl2ffffz98 +HCP7ooJDh48eMcdd0hdRcdEjrHJkyd/9tln4q5TEp9++umNN94odRUSkFuGCZBk3SC3DBN4W5Kt X78+PT1d6ipE4HK5IiIijh8/LnUhHRAzxvR6/S233CLiCqV1yy23lJSUSF1Fn5JnhgmQZG6RZ4YJ vCfJmpqaxo4d++2330pdiDj+3//7f88995zUVXTAR8QpTD755JO4uLguPLE2J4FhmPQyx+UHHKVx TFxJbRcWjGMScsqIaveujmXaiEveVuG45mLVZR+uX50QFxe3fmdhTZc2hYgoLi6uqKioy0/3eL00 X6JYxo0bd/jw4ZdffnnHjh1S1yJ3vTRfolhWrVr1yiuvxMfHG41GqWvpXRUVFY2NjZMnT+70mWU5 yQzDbCupvvxAbU4Ck7CzrPMFdyYwcTtriWrLdrZtEpnY1fll1ddftuLgrNuLVAAAIABJREFUpoT0 /M7b3ctk2ySKGWOFhYVdizHB1sRXjrj7Eg1Ep2xOIqo1c2xGntFkMhqNnF4bvSt1Ump+h0HmqMgP ZxedmJr44p9+pU+JH5Zd0sXXEqY3dbdCDyXzDBMgybpC5hkm6GaSOcrWJySvT05gGCYh+0MHEdWW ZyfEMgwTm5Bd1vVD1L7iRpPYUE9EqbNeqnBdfsBGpxqcXVjSRudaf9HojSaj0WjUq+O4lezvyq59 cO+qyp+k3Kg9ds51zae0N2vWLKPReOHChS4v0VfE6tY1NDQMHjz4/PnzXXiuTaNsfnWN0cbzPG83 KEiht/E8z1cWaxRERMQmZnHWdjMc2tQKUqgMl3/gWv5gVCmIVZ0x5inZNL21+cl5acq03K9zlUSZ xcJDVkNulkbfxcmmzp8/P3jwYA84N2vnMpRJGUlKIlJmFdh5nrcZs5QsEbHKLM7ahRXIeCzxahhd vA45jyVeze3RRbtBQZSWx1kqdQpidRZnXiJRRoHNaSvIZEmZK7cZUR944IGcnJyuPJNTJwpNoiJL z/N8m7aOd1oMmUqWiIiUGr35qgUVxKptPG/j1ERKrqV1s2iJKOeDvVc1icI3eiszhNdTqm3ubNGC BQsOHDjgzhJ9QbTeGMdxN95445AhQ7ry5AYbKTXF2gx6bMrWM20ery3PGTf3sWi1rtKkX2Fexw7b fOaa66BzjvMucjkcjtrqsoOFRTR+ROi4G4O5rW/rKoiIar7etFUbMzX8ko1Y69FNq+MYJu6VL0c9 8euZXZxWesiQITfeeCPHcV17uoSceu0u+z2bLJU627p1n1e78p+csu6mLJvTljU9l31s7/WPtjyi H9aW0CfbvHmzWq2WuhZ58Yh+WFtu98mczhA2a+OKqWFRsx9kuc+Mn765h9VnLAz2DV747C6FtsB4 7c6HJPR6vXD7oS4wkzLXqFcVrZuVX9H2X7ZqY/j0jbTKYDIVqIIfmxW5t/w6o4Cnqq0Ol8PhcNQc +ccHRIqps2+5qkmMJKLC9eM2p+XpcxPplHtbdPfddx89etS9ZfqAWHm4d+/eBx54oGvPtakVpFAb hWOrxFwTz3NCb0yf1eaQylrMtnTX2i6oMrTtz12myOOsPM/rMoiUGjvPV2qTiDLMTpNw0JGkyivI zSIiyijo+iHbgw8+mJub2+WnS8SmV7JZVp7nebuapczDRQpiha4tb9crKJG7dvfTs/phbZ06dWrM mDE7duyQuhC58Kx+WFtu9MlseqVCZeV5nrepWMr6vEhJCoO9+U8KSqvs1ULdZLfb/f39uzhBq9Cp svPO3EQiVmXj7RoFKVQGG6emln9n3qpiic0yXL3g5d7YFZLUeufVTSLPm3WZRIkmnjdplMSq3ZoK ff/+/cuWLXNnib4g2h0jT5482ZUzma0a6ilg2lt5SZNW/jZp5uZIIqLarz/kFA9Oba4pcOh4Ikt9 x32JBhuxmdqClF84653kopDIqNAAIqLZD6uJffeEY3n527sUai7C5TxHpMjS71w7k4hMAysmrSw2 v7Qwqms1Tp48+eTJk25slFSGCz1MZwORvx+F0HA/P+EBIhoRco3up4j9MEdNtdXuJPIbFhHWxc6u y+FwkW9AQDc/gePGjSsuLp47dy4RpaSkdG8l/YZ4/TBX9RmLk4gCgyNCg7u4iMPh6v6OJFq1ahUR xcfH63S6zu+0ea5Nh8t/4iK2KP/zM9PiIire317E3jWsuzX0BpPJNGHCBB8fN0a8nOT7yF90WeHx mw/OvCVSOOfVQLRqcvOuCIxgia77D5bHVc4OISe5/IIihf/F9k2io3x1/EbKyHNWlB4+qiVu/Cel 5XeyMcFd23/ybBJFG1T89ttvb7zxRneXmrjif1SKornLkvZQiB/5jY6mIsv55r85608RhQdd890d PuSGiLCIqKioqInNGUZEAVMXZlDR7l2av2opbckUCoicpqAiEhp1Ch8z0a3y5LnPOtDR/zYRVby/ vYiN6fB/W7QMc53JSY8LHBYeGRkZGRkeyCTkN59qr82Ja3OpVW3Z+liGYZJLa4hcVTtXx/oFBgYG +sWt33um66eYryQk2UsvveTlo4tiZZijojCZ8RN2ZOSwkNjkbRXC8NWVFxJXl+xkGCZ2/Ycuotry gwmMX2BgoB/DZB8s7/ZLuzG62HzERv5EATT0gT25m+MjGYaZtMqct++RLgZv3+hek0hhcfs0iZuV s1btofH+wpFo2c+X/0fOma+/sGJCdJTQJrYcT7ZvEskZxBL7wcopk6an7CKirYum//k7e1eri46O NplMPM+7vV29Sqxu3YwZM7744ouuPdemVhCrau4a2015RESkNNj4Sm0aEas1Wnneps1gqf0oQcuC rec/r2ZQK4laT13qsxREScWVNqfNlKUgSszr+qDiF198MWPGjC4/XSJtRlrULKkMNiuXe3n3KvKM HZzBFW8s0aJWEJEit9hotdmsZk6dxBKRhrNdsZdtXBoRUaLewvO8syCDiDI4q91q0imJ0gp6NBTk 5aOLYo0lOs0FLBElZukrLTabrdKQl0hElGFyXnEFlqVYRUSUlmfjed5pSiJSqnRWu43Ly6DLz+m2 bn6fzG6zWCw2uV3dwfNZWVnr1q3r4pNbxgZ5nud5cyZLRKRUGXiLjiVKyzU4ed5crCIiNWfrcEEb p77WLmjXJLawcyoilbs7bezYsXK7l6ZoMXbTTTd1+QveNrWClOrW6wz1KqUQYzxvzU1jW5vg9pfZ 2dQKUmo44dzYtWLMWalliTJaGkdnpSrx8irZDIPFjc/7N998M2XKlGv9tbq6+o033pDpDaOv/b8t 4vkwS3EWEeWa2o6uW1QKosRce+sZUC6JiCjt8n+fPTeRMnUW4WeNgqj50qzu89okE+98mLMgjYgy r7gMzqwloqQ8kxBjnLM5wxSZBc37284pWy6NsxVT+zPZ3eFZ34zevXs3x3HX+uuGDRtefPHFLq6K 0yhJ0RozdmMuESWqOZ7nTdrMll6HcLrrigXVzQu2v1KxjfZN4mU2TkWs2zEWExMjtx0kWoyNHTu2 slKcM6w2i7my0izu4ZXNarVY2l+/36mqqqoxY8a0e9DpdB44cGD+/Pn+/v5EpFarxSqyD4h7TYdB pSBW1e5Yg1MriVVZeZtaQZSYkaQgokRDR/8rxrwMItJ05TsBnfHCJBP1mo4Ohzcu96ftBgUp1MIV Uh1f1G7VJBJRhij//56SZGfPniWioKCgSZMmbd269eqZxNPT01977TVRXstps5rNZotVFjem/8Uv ftHlgbc+IlqMhYaGnjt3Tqy1ycS5c+dCQ0Nbfj127NgTTzwRHBwcEhIiHBwFBQV5UIyJfl2iUZPY ZiSkGadWEmVUOq+4mjQtr/3956x6FRFlaE2iVMJ7WZKJfF2i05hGHcSYRhj8sBsSW/ekUmduF2RO XQZLpCx2Z5zj+jwiyc6ePRsQENDSDvj7+99zzz1arbZleOY3v/nNrl27pC2yN9x9992FhYVSV3EF 0a5UrKur6+KXxjzIkCFD6urqiOj06dOxsbEOh+PSpUsu1xXXJOTn53vGZSBEx48fHz58+LvvvuvW 1VPXUW8zE3fBQdT21LqzwUbsqGG+1EBEiixz4e/K10+PX/mgotKwNKrl81a7PymVMnUvLXXvopvr GDdu3KeffrpgwQKXy/X000+LtVoZMhgMy5Yt27Fjx/333y/OGn0jYxR01Yw1lmNFZFtYT+RXS5So Nux+PCjZb0p84puWwrVhLc+qNaRv5jTGT+eEidaYrFq1ys/Pb8GCBadPnxZrnb2BYRjhh/r6eiL6 6KOPSkpK6uvrn3/++U2bNl28eLHleLc/GTp0aG1t12ew6guiffIYhnG5XB7x/dmuc7lcwifVz89v zJgx5eXlfn5+7WJsyJAhEREREhXonh9//PHs2bOXLl1qOYrsoTG3LSRa94+yJ5KntgRZVX5qEZv5 YjAR2Ujx4KII8o3YuC9p8xTl0r+Yjz13+Z3yi1qRof3VbFHKaHH+/Hmr1eopu6PbwsLCfHx8RG3i A6NmEZe6u+LJaRMvNwm1ZUe2Eqnn30T0nY0UGx+dRr70sl61a1bq73betTt52uVFR6xKU82ZJPJF gmazeeDAgT/88MMNN9wg7prFcu7cuRtuuMHhaL1IeMCAAY2NjcOHDx89erTwSGNjo0TV9SKn0ynW cbBoxOrWDR8+vP/dZ/Ls2bPDhg1r+fXHH398+eWXx4wZM2jQICGwPWtQsbGx8eGHH77nnnvsdrEG 2S1ZLBGxmmKjzW63mg1ZCiJSFFv4dtejWg1qIlKqWq7msBu0Gq3BIlIZPM/zx44dCwsL+9///V8R 1ylbVVVV48aN27Ztm1grdFZqiYiUmfpKi91ur9RrWCJSamz8FVcq8jyvy2SJKNfY/BFyWrlcjbb9 QGPP/OUvf5kwYYLcLodrp+2gYnBw8KBBg9asWdP2pFFSUpIHNQ5dN2/evKKiIqmruIJoMRYVFXXq 1Cmx1tZVdoOCSGUQ4RqBDlVWVo4dO/bqx7/44os1a9YEBQURkWzviNoh8ZPMblIlsa2HRWySrrL5 2rV216MWZymJKM90+a9sa8j1nFdlmED0JLNyeW3nxlFk5DYfZVwZY7zTlMESsc2XNV45zYQIPCLD eJ4/d+4cEfn7+8+ZM2f//v0Oh6PdE373u99JcutdQxZLmT29+vc6pk+f/uWXX/be+rtBtBi7+eab y8rKxFpbl1kNBTqj21cgdlVZWdnNN998rb86HI7333+/l1669/RCn0y4uLSy0izeWX53eGGGCURP Mp63N+9JiS6K85QME3z88cc//vjjtf66cePGF154oS/rEViMxcWcmOMc7UyePLm8vLz31t8Nog1x hoSECFdDdJ3jTMmmBOG2YQn5pcKtcVylezfFMgzDxKbvLBROI5bnr0/Ozslezcx/dE1c+t7mc4s1 Jclxqw9WVH/6f+9XWl1EVFW4M+7yvcfKa4iIaso/TI5rfqSspjtzRdTV1V3nJK2/v//ixYu7sVpp +fj47NmzZ8SIEUuXLm07st8TwcJ0KhHineXvMo7j5s+fr1arly1b1ucvLrGxY8cePnz4tdde2759 u0irDGjek6HinD11y5YtW7Zv33748GHZng9rJz4+ftSoUdf6azeaRHJVH8xOFu4Xlp5zRPjnvLod a2kSl/zxlYTY9JLmO9TU5qcnpO8tt508+sm354jIVV2yXmhgY1fnl54hInJU5aQnCI/sLbnOvOvX c/HixeBgWc2XIt65sdWrV2s0GneWsOcqiZRqo9mkzVQQsQY7b8pLIiKVVm/QqYmah6Q44SvoiZm5 ORuJWOGLs5V5SURpphqDgijLYLVxGiJKUuuMnDaRiDKLhW+/KzLzOGNxhoKIzerG8YlGo1m9erX7 y3mA3uiT9T2v7Ye1VVVVFRUV9frrr0tdSI94Vj+sKw4cOLB48WK3FrHoMoiUBZyJ06mIKKPY2mE7 1tIkaj8/nCh8RZ1vnktdzdkMKpay9M23YlFmGUycJomI0kxOq1pBxKbpOE6blUhEeZVuj57YbLag oCB3l+ptosXYpk2bMjIy3FnCpmaJktQmi513Wjk9Z3VaVWzrl1cMzd+i5Tm1ovn77U5TElGatlKY /YHN0recGzNksaTQCOPzlmJVUmbBl2ply6wE9so8ItK6v88yMjI2bdrk7lKewtOTDBnWwtOTrP9l GM/zJ06cmDx5sluLGDWJRIkFnNnJO82cnqu0ch21Y61NYkcT2BtUCjZLmBqfLs+Ww2UkZn75tYZa T06bM+mKU9dd9J///OfWW291d6neJlqM7du3b/ny5W4tYtE33yGTiM1Q66x2LpGupFBbL+8VYZHi TJaUeXabnhUOJZpj7L9qBSmu3CUtt6FroepwJonrWr58uSfe+aLrPDfJkGHteG6S9csM43m+oaHB 39/fvcnqbFzm5ctsFEkqg8XZYTvWtkm0c2oihcFuy1U2t4GXY0wlpFoLO6dptyql+9dYuXNDrr4j 2rkxYeZjd5aotQ2Zo3U6rWajLnfF5pT4/eVNQURJeUan026z2y1GfcGL89oNwd6+Mp20e97RvM2x qvjW79L6jo6moirh7BrVlOZn7zxS12AmVmVxOm02u91aqSsofph1ezzXZDJFR0e7u5QH6Y3zZH3A m8+HXcvYsWOLi4tfffVV8c6T9QWPOx/WdQMHDoyMjKyqqur6IrVWv0fesjttFq44L3pX6mMaztlZ O3bVBPaXOYnoxDnhkgBHxc5NO0/W2YhYndnutNnsdhtXXLBR6XbjVlFRIccmUaw8dLlcISEh7nx1 zJREpFQLd+nWsURqzqpNImKzTDaetxkziCipgL+yN9Yy93PzcPDlQUVzQfPU+E5hwYxiS3EmEZvL WXjeXqxSECmNbo4pnj17Njg42OPuJ9kNntUnQz/sOjyrT9Zf+2EtEhMT3ZqPSp9JxKrMTp7nrbmJ xGYZOmzHrmwS209g3/xXa7EwNb6dtxWrFERJphqDkkipKrbzvMWgIaIsvdtfVbr77rv//e9/u7tU bxMtxnieX7x48f79+7v+fKM2oyVN2SSNhed5G5fR8h0kNlP4hiV35T7jNIlEymLh/bdzic13LrDm ZbSMUKYZrE6etxdktX4NRuP+N23379/v7hlaz+UpSYYM65SnJFm/zzCe5zUazYMPPtj15zvNujZf 3UvUVdo7bMfaNYntJrBv+WtlQVbLgipdJc/zFn3rnfmUWTp3Lxaor68fNGhQXV2dm8v1OjFjbMuW LcnJyW4t4rRZKisrzZa2Z62cVovZYu3OBPc2q8ViveIEmN1qMXf3XkTJyclbtmzpzpKeSf5Jhgzr IvknmTdkGM/zP/zww4gRI5qamtxZyG6urKw0W9r+E3a/HbPbLBar3XnFI+Zutq/8oUOH7rrrrm4s 2NvEjLGvvvoqOjpaxBVKKzo6+quvvpK6ij7V2Nj40EMPLViwQIZJhgxzi5yTzEsyTDBx4sTr3JPM szz//PN/+tOfpK6iA2LGGM/zsbGxH3/8sbjrlMRHH30kw+tK+4A8kwwZ1g3yTDKvyjCe5zdt2pSS kiJ1FSJoaGgICwszmUS7s5KIRI6xN954Q4aXY3bDAw888MYbb0hdhTTklmTIsG6TW5J5W4bxPG82 m4cOHXrx4kWpC+mpffv2xcXFSV1Fx0SOsZqamqFDh549e1bc1faxs2fPDh06tKamRupCJCOfJEOG 9ZB8kswLM0ywePHinJwcqavoqXvvvTc3N1fqKjomcozxPP+HP/xhzZo1oq+2Lz3++OO///3vpa5C YnJIMmSYKOSQZF6bYTzPHz16dPTo0R7dISsoKJg0adKlS5ekLqRj4sfYhQsXRo4caTCIdg+OPmYw GEaOHHnhwgWpC5GetEmGDBORtEnmzRkmWLVq1R//+Eepq+imS5cuRUdHy/DrYi3EjzGe57dt23bH HXd44heHXS7XHXfcIYcRGJmQKsmQYaKTKsmQYTzPnzx5csSIESdPnpS6kO7IysqKj4+Xc3veKzHG 8/zq1auVSqWct/xqjY2Nt95666OPPip1IfLS90mGDOslfZ9kyLAW//znP0ePHi3BvYV7Jisra9y4 cT///LPUhVxPb8WY0+mMj49fsGDBuXPneuklxHXu3Ln4+PjExETPit6+0ZdJhgzrVVVVVWPHjt2+ fXsfvBYyrJ3t27cHBAQcPXpU6kK66uWXXyYis9nc+VMl1VsxxvN8Y2PjihUrGIZ566235Pw94q++ +uqtt94aNWpUamqqe9NRe5O+STJkWB+orKyMiorq7SRDhnXon//8JxFt3LhRp9M5HA6py+nYDz/8 sG/fvoULF86ePfv06dNSl9O5XowxwdGjR1etWjVlyhQ/Pz8RZjIWm5+f35QpU1atWuVBh0hS6e0k Q4b1md5OMmTYdVgslpSUlDvvvDMgQIJbbHfFqFGjlEqlSqVycxotyTA8z0v9poHHaGpqWrVqldVq 1Wq14v4T4t4rfayqqmrevHnPPvvsU089Je6a+/G9V0CeRLvfGHgDHx+f3NzcYcOGKZVKEe9Phgzr e1FRUYcPH37llVfeeOMNEVeLDIO+hxgD94ieZMgwqYieZMgwkARiDNwmYpIhw6QlYpIhw0AqiDHo DlGSDBkmB6IkGTIMJIQYg27y8fHZs2fPsGHDEhISupFkyDD56GGSIcNAWogx6L4BAwbs2bMnNDTU 3SRDhslNt5MMGQaSQ4xBj3QjyZBh8tSNJEOGgRwgxqCn3EoyZJicuZVkyDCQCcQYiKCLSYYMk78u JhkyDOQDMQbi6DTJkGGeotMkQ4aBrCDGQDTXSTJkmGe5TpIhw0BuEGMgpg6TDBnmiTpMMmQYyBCm BgbxNTY2JiYm1tTUHDhw4OTJk8gwz1VVVTV37tx169Y9+eSTyDCQJ8QY9AohyX744Yfy8vJdu3Yh wzyXkGQrV6785z//iQwDGcKgIvSKAQMGvPXWW/Pnzz906FBCQoLU5UD3RUVFabVaq9V66NAhZBjI EGIMesvgwYOPHz/+/fff+/jgY+bZBg0adOTIkYkTJ0pdCEAH0L4AeIOanasT9pbXEpGjIj9hdU4t uUpy0hmGYWJXHyyvIXKV5W+KZRiGid1WWCV1tQBuQIzB9dSU7oxLzncQETkOpifsLK1xVZekxzEM w6zedLCGiGpKNyXEMgwTu3pblWj30QTRhd40WZt18AQRnfjgTe2YiY7CjbMeCzTa7ObtU5VT1pbX GVNXbtxQ6bSbNqTGP1Z65a7keZ5hGGkKB+gMYgyuJ3R8dNGuN4/VEjlObN16Knq8fXP4rMA0o9Ne OTVfuXZvefn+P2wM3uTk7ZuCUpfuKpO6Xrim21dquHWHaqjm49Qi9a9uL//sA0ocerLo0H9qhrDE VTuDoolW/mnjv74bY7JopwVcsSxiDOQMMQbXFTpboyjSfl1Te+KDIkX6bCrPJxpad/Lfh46Fx7Fc xQW/4dG0R7lx579GPm369MmpUpcL1xQQo0ij/ILCglxKWxhDP5/kFCMC6qxWq9U/XbNpbOBElcVY ED9Uu27WpPDVpbVXLIsYAznzlboAkLmABc+lPfaPgmmB+UlpB8n6GUeKxy9ZrVai2PQNU8ZMnKky 6u8/+F7urJSVSjV3IBlJJltRq1Xjp8evUqj0URRgv0tRVD658NcLqeZI3LBdt86jcROOWfkNC3/9 2Bgm/Hura1pwa+OAGAM5Q4xBJyLufEi5aNZKUuhtUQGBNiUVjVtQuDSCjmTHvdYwfeDbkfoHrS9t WfjYkjHhmlOEGJMxVplIqdrf3BdLRDGPvpkxc4qQTWl5xlvHD1cnKocxG4mIEtWWqCtaBsQYyBli DDoTPH1NEmnrn4wNJqKpr2kzJkUKLVqG0T515K1q5axhm1kijtR6i7SVwvXZbeeIshZNDCAiCoh5 6Zjz2eoa3+DQ4ABfIkrezT/wlzN2Co4IC5a4UAB3IMagU3brd5S5OV446z9x6UtO+7M1dt/Q0GBf IpqZzNsfOGO1Bw+LCA64/npASmU7V7Mpe1R6a2jrY76hYWFtnxMaFhHafjki9MZA3hBjcF2OsoRA VqtQW2e2tm++AaFhbRMrIDSi49YPZGTq42/aHtEEB3fnXx4xBnKGGIPrCpiy22bzC0ZHy/P5Bgd3 d7AQMQZyhhiD6+tB4wf9BWIM5AzfGwMAAA+GGAOATqA3BnKGGAOATiDGQM4QYwDQCcQYyBliDAA6 gRgDOUOMAQCAB0OMAUAn0BsDOUOMAUAnEGMgZ4gxAOgEYgzkDDEGAJ1AjIGcIcYAoBOIMZAzxBgA AHgwxBgAdAK9MZAzxBgAdAIxBnKGGAOATiDGQM5wvzEQ37lz53Jycojou+++e//996uqqsLCwn71 q19JXRe4LS8vr6qqqrKy8scff/zLX/7CMMzy5cvHjh0rdV0ArRie56WuAfqbNWvWaDSagQMHtjxy 6dIljuOmTp0qYVXgrp9++mn06NF+fn7Cr0KHbMaMGUeOHJG0LoArIMZAfCdOnLj99tvr6+tbHhk/ fvz3338vYUnQPbNnzz569GjLr8HBwQcOHIiLi5OwJIB2cG4MxHfTTTeNGTOm5degoKCnnnpKwnqg 255++ung4OCWX/39/RUKhYT1AFwNMQa94plnnhk0aJDwc2NjI06Meaj777/f5XIJP/v7+ycnJ+Na D5AbxBj0ikceeaSl+bvzzjvDwsKkrQe6JzAw8P777/fx8SEihmF+85vfSF0RQHuIMegVoaGh8fHx DMOEhIQ8/fTTUpcD3ZeSkiJ0rG+++eZx48ZJXQ5Ae4gx6C1PPfXUoEGDmpqaFi9eLHUt0H1z5swJ CAgICgpKTU2VuhaADiDGoLfce++9dXV1y5Yta7liGzzUmjVr6uvrly9fLnUhAB3ABffQi6xWa1BQ UEBAgNSFQI9cunSprq5u2LBhUhcC0AHEGAAAeDBMRuV1fHx8+uWxC8MwTU1NUlfRp7ArAQgx5oV4 nu+vbZ/UJfQ17EoAwiUeAADg0RBjAADgwRBjAADgwRBjAADgwRBjAADgwRBjAADgwRBjAADgwRBj AADgwRBjAADgwRBj0G21OXFMQk4ZUe3e1bFMG3HJ2yoc11rKUZK/bXVCXFxC8t4jVX1ZLlxL2c4E Jm5nLVFt2c62+5GJXZ1fVn39ZSsObkpIz6/tm0IBOoIYg+5rIDplcxJRrZljM/KMJpPRaOT02uhd qZNS8zsMstKdD81a+bfb1/wpLY5WzR2XU37NuIM+ZKNzrb9o9EaT0Wg06tVx3Er2d2XX3kWuqvxJ yo3aY+dcfVAjwDUgxqBHhrf8MOrGmIkTY2Jips5cmq5SkP7Msb3r49L3Nh+n15Qkx60+ePI/mSla FVeydmnc0rU79RrVKD+nVJXDNSinx8ZMjImJiZmZvH4T0Z7Swr98FIkGAAAgAElEQVQnxKaX1Ah/ rc1PT0jfW05ERFUbx60kIgrB3KwgJcQYiOOc47yLXA6Ho7a67GBhEY0fETVxaNHWrC+riYiqdG/v Khpxo2+llujC59tWxzKxcasrpqxYODFY6sKhnVPVVofL4XA4ao784wMixdTZtwRzW9/WVRAR1Xy9 aas2ZmokERWuH7c5LU+fm0inJK4YvByOokAE/iHErZvrt67lAUUet2jUFGsSrXv/aFXc0pFFb+5i s/QRF78moo0pH2q0BfF69apZkaf1ludmhklXOFyNi48MbPklSa1nh059LIPi9xxRrZj485E9HGUs mRp8pnBT/OZEE7+CcvYQEW7vDRJCjIEIGmzEZmoLUn7hrHeSi0Iio0IDiCg0MZOd+/aXmxVjthTR Bs10sn1NRLnGfz8SE0BL72z4IOTNw98jxuQmj6ucHUJOcvkFRUaEBRDR7IfVxL57wrG8/O1dCjUX 4ShfHb+RMvKcFaWHj2qJG/9JafmdbEwwmhOQAj53II7hQ26ICIto9+DtK9Np4553NCM5VhUf5etX 7k9Ew4YHEBGRn/9wwnG8/CgmREdFBFzxUMDUhRmUsnuX5piW0t6cQmQMYon9YOWUzcLfty6aftZg 2z0NI8QgBcQY9Mi56/41IGZBJvtYSiol5ZlCiShGkUG0bks+u3Gx33f/2lJEK14c0zd1Qtc5nUQB 7R6LWqFWTk9JJaVaG+FLNHXnsebbdTrKtgWyZOPXIsJAKrjEA3pkfIgfEfmHXOvvEQnpiUTKxPiJ REQUlWHUDt+8MjIwMJxdOT5T+/QcjCjKQUjrJacUEtRRD5lduIYlykhZ2C6unETE9mptAJ1g+uVN 0OE6GEbqne5yVFusFDgsLLT9MX9PSL9dfa6/bnJ/3S7oJfi4eJ3+2kb01+26jv66yf11u6CXYFAR AAA8GGIMAAA8GGIMAAA8GGIM+khpdiyzqUTqKqCnakuzGSa7RuoyAFrge2PQR8Ys3V7snCB1FdBT geOX6nSEb4mBfKA3Bl3gqj6YnSzcgio954hw446a8g+T45rvLlZW4yKi8vz1ydk52auZJX985eo5 0W0nj37y7TkiclWXrE+Ibb6dVekZIiJHVU56gvDI3pIzEm2kV6j4cGdc863EtpULdx+46s13VOSv Tt+Zn5POMPc++1Bc9ofNt4U7U5gdl5xTbT35/mcn7URENZc/FbHrmz8VrtK9m4Rdm76zEDchgz7C g5fpxk636DKIlAWcidOpiCij2MpbdCyRIjOPMxZnKIjYLAvPc2olEVFipvbzw4lESXkmnud5azFL pOZsBhVLWXqer8wgImWWwcRpkogozeS0qhVEbJqO47RZiUSUV+nsm+3ydG5vst2gIMrUGipNxRlE lJjn5Dt4822cmoiIlKrcQ++tJVJobDzP8zaNgihTZzNkEamsPK/PUhCxuXpOn5dJRGrOZspLIiKV Vm/QqYlIqeb6aLvAu+Hj4nW60UYYNYlEiQWc2ck7zZyeq7RyaiVRppnneZ63V+YRkbbSyakVpFDb eJ7neV0GkVJj5/lKbRJRhpnnDSoFm2UQmkidRViSy0jM/PJrDRHlmew8z/O8ObO7zZ8Xtn1ub7JN ryDKzNNb7bzdYtIbTLXGDt58G6cmYnVWnud5m0FFxBZbmw9Hck12G6ciUtnsXCJRRkHzR0CbmaQx nFSxpFAZhJcyqJXEqqx9s13g3TCoCJ2LWf5cpnLPIjbSj/FL3F7iDAomCibaGMkwDMMEjltJRJXn 7M4GYhfeLpw1mf2wmrTvnnDUfvb2LoX64TZzBjcQZcQIU1AFTH1p94ZbfIiIVk4KZBiGYSI3ElED 7qXZO4Jvek6VtHHlrGGBTOD8Fyou+vo6iTp+84cP9SUiCp52XxpxBV9VV5f8g6PMeyZennjF6TQT jQoX9nbA0g07f32T40uOilKnC4PP01O0NNy/7zcRvBBiDDpXa/V75C2702bhivOid6U+puGcDWZi VRan02az262VuoLih9krzvoHTF2YQUW7d2n+qqW0JVNa/+AkohPNN713VOzctPNknY2I1ZntTpvN brdxxQUbldF9uXXew1VrHXff//BOe6VRr7nPvGru1pOOTt/8iQ9lKTZrNBr1VqVmZfsZMJtnX3Qd 2Zl9sMIZRJSUZ3Q67Ta73WLUF7w4D1eCQB9AjEHnTrw7ZdL8XZbAsKlz4uclEhGNuU1B3N8+MtYE B9OXux+LX/TaVVPdR61QK7emphYp1YqI1gtig8ffxpL27f2lDqo9suu3KRtLB025S0nctvwvXcHB tSf+l5276OOfXH24cV7EVamdMin8YJUzKmamYu4sIhoSc803v6VHPH35k7Rn3Totu/a+mNZ1BUf/ SkmpGzQVta7q0j1zU9ZVNo2/L4l2bTpYZQ8IdlZumTJr0Z5KXAkNfUHqUU3oa93Y6U6zTtn6kUnU Vdp53l6Q1fqYxmDheZ5TKdgsQ+tSlVqWKKOgUvi15a+VBVktC6p0lTzPW/TqlkeUWbruXODhlSdU 3N9kiyapdTr6jDwj39Gbb+PURErO3rpUloIoMVc462njVMSqbDzvtOiTWhbM1Np4nrdxGS2rZzON 9o6L6IXtAq+GKTi9TnfnXXWcqfrZ6Rc0UrgfsPBQTbXVRcGhYW7f9tdRW13rCg4NDfBtfeSM1REY HBra3VsIe+F8st3b5JrqM7Z6ChkW3vpWd//Nd9RU11JA2wVdNdUWl28PdqRX7kroCXxcvE5/bSP6 63ZdR3/d5P66XdBLcG4MAAA8GGIMAAA8GGIMAAA8GGIMAAA8GGIMAAA8GGIMAAA8GGIMAAA8GGIM AAA8GGIMAAA8GKbu9DrCfTSkrkJ8/XKjrg+7EoDQG/NCTU1NfTZl5/Lly/Pz8/vmtZqamqR+a/ta n+3Kjz76KD4+vm9ei/fKXQk9gRgDgE5gkkOQM8QYAAB4MMQYAHQCvTGQM8QYAAB4MMQYAHQCvTGQ M8QYAAB4MMQYAHQCvTGQM8QYAAB4MMQYAHQCvTGQM8QYAHQCMQZyhhgDAAAPhhgDgE6gNwZyhhgD AAAPhhgDgE6gNwZyhhgDAAAPhhgDgE6gNwZyhhgDgE4gxkDOEGMAAODBEGMA0An0xkDOEGMAAODB EGMA0An0xkDOEGMAAODBEGMA0An0xkDOEGMAAODBEGMA0An0xkDOEGMA0AnEGMgZYgwAADwYYgwA OoHeGMgZYgwAADwYYgwAOoHeGMgZYgwAADwYYgwAOoHeGMgZYgwAOoEYAzlDjAEAgAdDjAFAJ9Ab AzlDjAEAgAdDjAFAJ9AbAzlDjAEAgAdDjAFAJ9AbAzlDjAEAgAfDQRaI74UXXnjxxRf9/f2dTqeP j8+AAQMaGhqOHz9+8803S10auOHnn3++/fbbL1261NTUVF9fP2jQoMbGxkWLFu3evVvq0gBa+Upd APRD0dHRgwcPrqurI6KmpiaXyzVgwICoqCip6wL3hIeHX7hwwWazCb9evHjRz89v0KBB0lYF0A4G FUF8y5Yta2xsbPmVYZj77///7d1/WFt1gu/xz6mJhGqwUEEX2mnpj1mq24NTxtvOrD8mQTutXRus /WULs1YdqKMr4Fztg4/yPEt3phd21jY464bu4033WjptwSo6M1R3gCt1dujjhhmDNqzCSp3SnYJN xqS3CT1n59w/DtBAw+/85vP6i+aX3+PJk3e+5yTfPHTjjTdGcEg0DYIgPPXUUwkJCcOXaDSa4uLi CA6J6FrMGAVfYmLiww8/PGfO4LPrxhtvfOqppyI7JJqeJ554QhCE4X9+7WtfW7FiRQTHQ3QtZoxC 4sknn5w7d676d0JCwr333hvZ8dD0LFmyJCsrS/37hhtuePrppyM7HqJrMWMUEt/+9rf1ej2AhISE wsJC/3f0FFuKi4vVA8KyLO/YsSPSwyEajRmjUHnyySd1Op0gCE888USkx0LTt2XLFlmWAdx7770p KSmRHg7RaMwYhcquXbt8Pt+f//mfZ2ZmRnosNH033HCDyWRKSEjgEUWKTswYhcqCBQtycnL42hcH nnrqqYGBgQ0bNkR6IEQB8OvPREQUwzgbo1CRZfmrr766dOkS3yrFOp/P53K5BgYGIj0QogCYMQqV V199NT09fcGCBWfOnIn0WGj6Ll26ZDAY1qxZs2PHDkmSIj0cotGYMQqJ6urq/fv3d3Z2Hjx40Gg0 fvLJJ5EeEU3HpUuX1q5de8cdd3z88cdXrlzZvn07S0bRhhmj4FMb1traunDhwq1bt77yyissWSxS G5adnf3qq69qtdoTJ06wZBSFmDEKMv+GqZewZLHIv2Hqt9dZMopOzBgF07UNU7FkseXahqlYMopC zBgFzVgNU7FksWKshqlYMoo2zBgFx/gNU7Fk0W/8hqlYMooqzBgFwWQapmLJotlkGqZiySh6MGM0 U5NvmIoli06Tb5iKJaMowYzRjEy1YSqWLNpMtWEqloyiATNG0ze9hqlYsugxvYapWDKKOGaMpmkm DVNt3bq1uro6NzeXJYugmTRMxZJRZDFjNB0zb5hq27ZtZrOZJYuUmTdMxZJRBDFjNGXBapiKJYuU YDVMxZJRpDBjNDXBbZiKJQu/4DZMxZJRRPBnM2kKQtGwYceOHSsuLm5qarr99tuD/uDkLxQNGyZJ 0qZNm7Ra7fHjxzUaTXAfnOhanI3RZIW0YeCcLFxC2jD4zcm2bdsmy3LQH59oFGaMJiXUDVOxZKEW 6oaptFrtm2++OTAwwJJRGDBjNLHwNEzFkoVOeBqmYskobJgxmkA4G6ZiyUIhnA1TsWQUHswYjSf8 DVOxZMEV/oapWDIKA2aMxhSphqlYsmCJVMNULBmFGj9wT4FNo2Gyx+XyyRqNPjlZF6xh8FP4MxTZ hg2TJOmhhx5KSEg4duwYP4VPwcXZGAUQuGG+9gLBX15Nc/fwdc3VRdqklLS0tJSURCFvb3v/6Pfd HdXG7Kp2+NqNglDd7oLsaj/V7pro3TnnZDMxvYb1d5x8oSDPaDS+UNPsGu+Gnppsoap93JsM4ZyM QocZo9HGmYd5gMLa1q4uh8Nhr6vU785dVlrfDeD8yYrc4rbati6319vX1VrSUJ6z7bBv5H0HF3XQ Zf6ksWltph74POeenM8n8YLGkk3P9Brm665PE9efWZn/ty9+r213bkrV6bFvq53SeFgyChWFyI/Z bF68ePEXX3wR4DqvzQCY7e7hC9oqDUBhl6TYzAaI5uErvI7a/EJLrzTi3jazQay0KVKPuaSksfOT CgMAQCyxuxXF22MtMQGAmF/b1htwYEePHr3llls+/vjj4GxnvPN4PN/61rd27979pz/9aSr389aa gIpW9R9OW22ltc0rdVXm51dazCbAbHNKfW1lJhFAYaW5EDDbnFMa2JUrVzZs2LBp0yZJkia+NdEk cDZGV03qfJh09X109vptwGdfenHrXxhgL04yFlUfebu986y0bMfrNUXpAc+AeC++deCA/f/p8543 ixDNe7cvSHTVPLB4V3Nmk93esBM712TUnw3wVl2dkxmNxjNnzsx8S+PbDM6HSVfcEJ2/2VtgFATj 339465OPrtZ5v/q3w4f37C7OrLQa/qz3qbQ1+9wbmtpal3YUH5z62Dgno+CLdEcpWow3D1OpszG/ d99uuwUw2NyKoihdTbUlJsPw86qszq4oUq/Dbrfb7XZHn3doNjb8IJLdAIPNq3gdVgB1XV5FURSl twIwWexjDeFnP/vZLbfc8sknnwRts+POdOdhiqIoitRVBgAoNNc11lYCQFmj5LWZgJKGHkVRvHYL ILap827Jbpr6bEzFORkFEWdjBEz7s/XSAAAJ8PT3p92zY/9bzYrk7e1qs5QY9m0pPu3xHF4hiqIo iiusZ675IIAsAZCkwZNmW5YlCoIgCBnlAAbGXBx9+/btBw4c4JxsLDP9XKIsXQQMlW01z2xet+P5 rrpC7GvtBdxAZmYKAAkDwM4legCAZvF6Eb7xH3AMnJNREDFjNMWGaYePFfrerSkGDEv0rn9KS0t6 uR0ANLr0pauLyl8EWi449c+4Bz27Kjnwg2khSW5AbOr1Sm631+u2tzaWm5aP899nycYShM/W6zJW GdAy9NmNtIVLr16lHkyWAHRcHOxOX7sd0/5qBUtGwcKMzXZTalgS8Intw87Ojo72U4deeGDLQVS2 Pp6K5HsrDdizq+ZUt0+WPa6z9X//d4Ap8xaNTj8owGkyCUBL52f9+uV3mWCvrv9Q1us9Z94Q71n/ qz9M8KLGkl0rSN8P09+xzoA9NafOemRP9z+V7UH+qgz/qxf+hYjDNcfbfZA76l+bxrkxfywZBUek j2pSJE18Psyf15bv/9QRTZZGx9B1vbUlBr/rDNZrPnBoHzw3Zs8HLHa3InWViVBPtPS1WYbvaaps muTZEp4nGzaj82GjSD3m4d0sltn6JHWXDX9CtauhYvhqABabe/zHmxDPk9EMcRWP2Svoa035XP0X 3Je1c5PSUpMnt06D7PNBp9MAgM9z3ulL1CcnB5q5jeXo0aMlJSXNzc233XbbtIYcD0KxTofH5fLJ SB5jP8qe/j4PUtJTg7VYy5UrVzZt2qTT6Y4ePco1PmiqmLFZKrLrJQbRLC9ZlKw1NXMsGU0bz43N RnHTMMzu82Rx0zAA119//YkTJ3w+3/bt23mejKaEs7FZ5+WXX37ttdfee++9jIyMiW8dI954441n n332rbfe+sY3vhHpsYTJxYsX8/LyUlJSGhoaIj2WoJEkaefOnQCOHz8e6bFQzOBsbNZZsGDBl19+ +cc//jHSAwlI9vl803gr3tvbO2fOnJtvvjn4I4pWSUlJ8+bN02g0kjTm1+wiSfb5fFP+UtnAwMC5 c+fmz58fihFRvGLGZp2tW7e+8sorRqMxFCvtyq7u0+3dMuBprxKEqkktfj7E0/l2nqBNTEzUCkLV 252Tv2M8HSOdPK1We+LEiStXrmzfvj34JRv+/YHhXySYyp3bj5QK2sTExEQhu/TU2cnGzP8Y6TSG TLNXhD8pSRFy7NixtLS0oK+0K9krgUqvokhOR1OTYwofoJa6CgGTucnpddvrygBD2+Q+yD217wzE nStXrvzVX/3Vpk2brly5EszHlWwAbF5FUZy2xiaHcwp70m23ALDaer3uHmshYLJ6J3GvYH5ngGYZ zsZmqanOyeT+9r152erPjB06fR6Ar7u+qKiqZm+BIAiCsfTUWZ+vs36tuAfY80DpEZfz03d+/akX AFwnq4vUHygrrW72AJC7qwryXqiuKsgWBEEoPXRaBiBfvgDT3kJjsk6/8rvrgRZHr2fCUc3OeZi/ qc/Jrtkdvs69RS8cqa82CoIgGKtPdkLu3rs2B0DO6tIOl/uDd9/pccoAzp46ZBQEQRCyC6o6XDKA zvoXCvZWVxUZBUHILqju9gFAb0c7TNbtq9J1+kWG+/PR4PZONKZ4+qwKRUCkO0qRNOk5WU8ZAFOl raur0ZwPoNbhVt90I9/i6LJVGgCUdLp6GsyFQH5DW5fLVgmYnYrSZjYAYm1bl6PVCsBgtilumwkA YGlsbbQUArA6/N+vO635AMp6JhrTLJ+H+Zv8nCzA7vCqu8PUYO9qshQCsNjP2xvNIkRzQ5vTZTMA lTan22EFUGhp6ulqqzAAqOhVFLvFBMBU2dDWZDWoj+ZH6m0yAGLFBN9n5zyMZogZm+0mUzK3/7rm itMsQqy0ue1moHDwuGFfkwiYbW7JYQYsXkVx282A2e21m4CK1j71nl21+RDNbq/NBJQ19iqKokiO kaukS01lImBq7ZvgKBYbNsqkSjb27hi6cHDnDv/+wPAvErRVijDVDu4VZ6sIWB1uu9mA/Dr1Qlul KFb6ZczrKARQWDv+AvhsGM0cDyrOdpM7ujgA7Py6uq45EtNFDK4IK67KUL+oqp+XCQCyV8KIBeoH D3MNfps1Y9VdsH/SJ8MN3JqhBwBNxohV0j220n12q+P1u1PH+wIsjyVea1JHF8fcHYa1d6QCAJIN jxsAv98fGHTpdyfthvUrB++ZOC8T6LssS4B45xL1Qq1uxMcLz75XcxAlXTU7Aq8JrT4ojyVSMDBj NImSSQA6Lgx9EP5i79Dl9q+Gb+IGhl8f/bmBm+YNXt778QcQb09T/zX085sD/rdOvHlnifnuZfpx RsuGjWUyJRtjd7R0O9Xd4bO91TL42zmAVjt8P82fLUdL39CXNKTLnwNpc9VVxIYuGzWY5KySyu+O 881ENoyChRkjYKKSDa9rLgPnTx3c3YIfGJYDCcCeffWdgOdkdUUL8tfepocE4A99nqHi6TO3GVD8 kvWsD7Kr/adbDoubvzFOo2TP5QXZixPHvgEbNr4JSjbG7kgCdr54uB84f/rorhZs/ubC4d8fGLqn LntDCcqffrvTBXje3ldoR4kha7x3G9p5i7Kz0sa6lg2jYIr0UU2KIuOcJ/Nb1xyFljZp6HPVw8xN vYqieLvq1H99YTdDNLsVReptvbouvqmyy6tcXeReURTFbRFROXRubORJuNF4PmySxjlPFmh32EyA Yej3CQxlDV5Fufr7A33DO8tZWyIO3dNQZ3cqw79aoCij/lb/qX7G51o8H0bBxcWoaITjx4//zd/8 TXNz8+233z7qKtnj6vN4tYkpqck6AJ726qRdCe6PHvedd2kGLwMA2eeTNRrdiNVdff3nnRIS09In ufJ9AJyHTYkkSZs2bbr++uuPHj2q9Ts4CGD07vC1GxP/50+8zbd5+z3QpSYPz7H8fn9giKf/vPMy UjLSp/I7BCNwHkZBx4zRaMeOHSsuLm5qarq2ZP487VVJOXAqz49zDj9Y2LBpGLdkfjynhaQ1rW7l 7vGOEQYHG0ahwHNjNNq2bdvMZnNubu7434xOXHhfXeN945zHChY2bHom+83oxCVNdY1LQ78j2TAK Ec7GKLBJzslCjQ2bocnOyUKMDaPQ4WyMApvknCyk2LCZC+0KwpPDhlFIcTZG44ngnIwNCyJ1TqbV ao8fPx7m31ZmwyjUOBuj8URqTsaGBdfwnGzbtm3h/G1lNozCgBmjCYS/ZGxYKGi12jfffHNgYCBs JWPDKDyYMZpYOEvGhoVOOEvGhlHYMGM0KeEpGRsWauEpGRtG4cSM0WSFumRsWHiEumRsGIUZM0ZT ELqSsWHhFLqSsWEUfswYTU0oSsaGhV8oSsaGUUQwYzRlwS0ZGxYpwS0ZG0aRwozRdASrZGxYZAWr ZGwYRRAzRtM085KxYdFg5iVjwyiyuBgVzcixY8eeeeaZlpaW2267bUp3ZMOiiiRJDz30UEJCwrFj x6a0WhUbRhHH2RjNiDonMxqNZ86cmfy92LBoM705GRtG0YAZo5navn37gQMHJl8yNiw6TbVkbBhF CWaMgmDyJWPDotnkS8aGUfRgxig4JlMyNiz6TaZkbBhFFWaMgmb8krFhsWL8krFhFG2YMQqmsUrG hsUW9ffJBgYGtm/f7l8yNoyiEDNGQXZtydiwWHT99defOHHC5/MNl4wNo+jE741RSBw9erSkpKS5 uflXv/oVGxa7rly5smnTJp1OZ7Vav/vd77JhFIWYMQqVN954Y/PmzVqt9vPPP8/IyIj0cGiaJEnK y8v75S9/uWHDhp///OeRHg7RaMwYhcq5c+e+853vdHV1RXogFASPPfaY2WzW6/WRHgjRaDw3RqEi y3Lofl+Ywuydd97x+XyRHgVRAMwYhcp///d/X3fddZEeBQWHIPDIDUUpZoxChRmLJ8wYRS1mjEKF GZs92muKSo90AoDc/YKxqN2D86cPGQVBELL3vt0JwNVRn5ctCIJQUN3MQ5MUXMwYhQozFk/Gn40t vG3BgZ3veQCf/Rf7WhYs9J3MWLO/xOH09u5vMa040v3l8fwt+pd6FKnr5uLcgx2ecI6c4h4zRqES KGOumoK8I50eAL7u+ryCQx7Ipw+VCoIgZBe83ekC5I76vdmCIAjZ1c1nIzJsCmj8jKV+K8+E4t95 cOYXrxksW9D5ISBe+vTUe//uzAa6v5Tmizi85cXqtz57rKvvByv5cUcKJmaMQiVQxpJv+3pD5dtn AJz5xasNC5f6msvX7Ep0uL29P11pWvFM5yVH8Zbyl3okb9dLxbm72nn4KWpMcG5Ms3J3IU68e7K+ HCUPLnP//hwMN1+55HQ6L2VbrWsXJm/+5762xtzPG/aIy9Je42yMgmoKP/NKNCUBDyreucVqX/Ge 6/mv/6q4xeL4ZWfd08jf+WnLe8BNIuz90tzlwJYXy+t2mrr6GpbqIjJwCmDCj3j8ZZF5fc56GMzO dE3iqlVoObu2+dF09Fdlpw3k/I+jGY886Pxo/7pHH7xZsP6Hs4gTMgoezsYoVAJmTJdlKEF9Y3Nj LUrWZeHCp3bDzbpLTqfTmVBq3fu1xKXmPkdj7ryGPWuWpRW081171JgwY3pxQwmQ/8SGZECXtaOh rC1DEAQhrdZYt2PlbQUWMTdFyBaE3AP5T+cuCtuwaTbgbIxCZYyPeCwqMGfm5O40mNsWQee9y9DS +fXmR9fBdcqYcvCOe7F4yUdO5aV1j+5aKKT9p1NepedTNEbIlz+H4YcPLgUA6Df+uNn7nMurSUzW 6wCsKnrdu/Vlpxcp6amcY1Nw8TWCQmWsTyqKpnwUNzyxIRtA1l+/WrZ6hbrSbEmd447M+ZZ8U4pQ DgD5lr5FfH5Gi/FnY56OmiRxt8ncdrffwUJdcrJ/sXTJqenJIRwhzVp8maBQkWVZownwBPO6LwKV 69UTX7qsH38kPdfv0uiT9ToNgKLXla0vn/dCn57K0ydRZPyM6Vf+tdu5Q5/MXUYRwIxRqAScjXXU FIi7D5vbnH7vyzXJqan+t+G79ig00bkxnT6ZBwspMvgRDwqVgBlb+firbrf0zGp2KsZwMSqKWpyN UagEPjem4W99EFEwcTZGocLFqOIJZ2MUtZgxChVmLJ4wYz8x/wAAABLnSURBVBS1mDEKFWYsnjBj FLWYMQoVZiyeMGMUtZgxChVmjIjCgBmjUGHG4glnYxS1mDEKFWYsnjBjFLWYMQoVZiyeMGMUtZgx ChVmLJ4wYxS1mDEKFWYsnjBjFLWYMQoVZoyIwoAZo1BhxuIJZ2MUtZgxCpWxfm+MYhEzRlGLGaNQ 4WwsnjBjFLWYMQoVZiyeMGMUtZgxChVmjIjCgBmjUGHG4glnYxS1mDEKFWYsnjBjFLWYMQoVZiye MGMUtZgxChVmLJ4wYxS1mDEKFWaMiMKAGaNQYcbiCWdjFLWYMQoVZiyeMGMUtZgxChVmLJ4wYxS1 mDEKFWYsnjBjFLW4cisFmcfjeeWVV6677rrf/va3Fy9elCRp3rx53/ve9yI9LpqOnp6eN998U1GU CxcuHD58+P3331+yZMmmTZsiPS6iq/gOi4LsxRdf/NGPfqTRaARBmDNnjiAIPp/v1KlTd911V6SH RlP2zW9+s729XavVDr9QSJLU19eXmpoa2YERDWPGKMjOnTu3fPlyn883fElqauqFCxcEQYjgqGh6 3n333a1bt7rd7uFL7rnnnvfffz+CQyIahefGKMgWLFhw++23D/9Tp9M9+eSTbFiMuv/++/1PcCYl JT399NMRHA/RtZgxCr6nnnrqxhtvVP9WFOX73/9+ZMdD0zZnzpwnnnji+uuvV/8py/LGjRsjOySi UZgxCr6HH35YkiT17zvvvHPBggWRHQ/NRGFhoTohu+6667Zu3ZqQkBDpERGNwIxR8CUlJd1///0A 9Hp9aWlppIdDM7Js2bLly5cDSExM3L17d6SHQzQaM0YhUVRUpB5XfPDBByM9Fpqp4uLiuXPnJiUl rV69OtJjIRqNGaOQWLdu3aVLlx555BGtVhvpsdBMbd269fLly48//nikB0IUAD9wT6HidDpvuOEG nkqJD19++WVSUtLwZz2IogczRkREMYyLUc0uc+bMics3LoIg/OlPf4r0KMKNe5MIzNhsoyhKvL7w RXoIEcC9SQR+xIOIiGIaM0ZERDGMGaPJ8BwyCnmHOgJf114lCFUuQHZ1n27vlv0uCWj4ZhQpHTV5 grHGE/A6X7tREKrbXZBd7afaXbLfJYFwb1LE8dwYTcoA8LlbCnhVYubGpiboAZx7Y00OvMrzVy8J aOhmfPJFjhsXx7hGl/mTxqa5mXrAnnNPjs2rJF+9JBDuTYo0zsZosuYDkLurCvJeqK4qyBYEQSg9 dFoGZOen7/z6U1dn/VpxD7DngdIjLuen7/z6Uy8A+fyRvQWCIAiCULC3vh/w+d3MA7g6TxYZBUEQ jEXVHS6+pw+3zvoXCvZWVxUZBUHILqju9gGy+4N33+np+3Tv2hwAOatLO1zuD959p8cpA+h8u9oo CIIgZOe9cPq8zL1JUUGh2WS6e9xtMcBgtilumwkAYGlsbbQUArA6vG5bJWDuc/c0mAuB/Ia2Lpet EjA7FcVuFgFTg83haKszAWVNvZLfzaS+JhEwVNTZHa1lBkCs7Av3dsW2aW+13WKAaHErit1iAmCq bGhrshowuIsNQKXtC3ujWYRobmhzutRLnFJXLYCS2taeLps5HzBZPdybFAV4JICmQgsAZY29RevS Iaeadh90X/ZCqwOg0y96YO3tQMLa1UulDh0ADXCrYX+jLWvdqjSPCzki6v/99z82rh6+maPmh3ZU 9L60OR1Ybq3bt3jLb84+u3ERn5NhNOBGfl398xs1wE8q9+/yDe5iHW5ceZ9hPt66a+3qZLQD0AFI WdXQ0GbYuDrR5/qLlQbUuiW/nc69SZHCg4o0NW7g1gw9AGgy1ovw+V3llQAMjDyBdunNXRmCoE1K WVFuR+ZN2pE30wPlGYIgCELi4i0Aei56w7MVpJIA8c4lamq0uvkjrpMlAJLf7tRotP/VUpYkCNrE lNw9LZifoOHepCjAjNHUSYOnPQYmuJ3nZ/mmtg0NvU6vonitBrhH3kEa6IVo7pMkt9vrdfY0NbY+ Io75uRAKlaF3IgE/wOO/sHPnGz/cfWB5a0+fpCi9jSW4OGJ3cm9SpDBjNFljfbTtKgnAH/o8w+f2 ZQCZX1+Qlqzpbj64qwXwSf43W/gNA+yv/avDpdfjw9d35a7/h4n/ExQ2EoCWzs/6r14wAGD+1zJS 5fOn/3b9AcyHD9ybFHk8ck2TlZmkBZABJGgHnzYJw2/lRQDQ3pQOFC9LuvULu3pJ8l2lJcW7crS7 ADG/osRQvqfw9JMfZQ/dzKk811hpWy+m7QQAWG19WXw+hkkS5gODJ8IGDf2tHdzFiTetEbFTvG9p 32H1kuX3PWaAabF2H4CSskLsK76v+q7TG7g3KcK4wv3sIgih3eOyzydrNDrN1Rcwn6vfI2uSU5M1 kD0eb6Jerxl5M5+r3ylDn5yqn8GrXqi3KzqFfqtlnw86nd+OkT39fT5dSqpeB9njkRP1Og33JkUY ny6zS7y+QMTrdo0vXrc6XreLQoTnxoiIKIYxY0REFMOYMSIiimHMGI0wvPa5p6NG8JddUN/RP/59 u9/em1daH3jddIoEX+chQchr9wC+9oIRu3NwPczAPN2H9hYZjca80ur2fi6NSNGOGaNRRqx9bm1z dDkcDkebxWjfIj7b4RvzbvLZ+mWm8oaPLvJlL3pI0gDgVv/2ACW1bV1dDofD0VRbcWDXmvKT5wPd 6fzepGW7WuY//7cvfvvz4py0586Gc8REU8eM0ThMOdlZS7OysrJWF72wFzjc3vyzvOzS04O/POWp L80rPdIJADhbvngLACRd+1VE18nqosEZQHWzB/B11gd6ELn9yN5sQRCE7NKaZg/U1fQLqmqq88b+ sSuaPDeQuTJ76dKsrKws444yqwG/+N2H1QXGqpODnTrfXGUsOvTZqdfKUdjT/ON1dxufr++yVGTJ I9+7nD11aHCR+4KqDpcM+ey1D+IKtNp9Z/0LRVWHqgqEvOr28G46xbtIrUlMETHhHh9e+9xttwBi U69X8nq9XmerpRAw2Fz2fKCwrktRFMXZKgIWu1tRlKYyoKSurTZfva+/NrMBEGvbuhytVqhrqHsD PEhXXSEAc0ObrckCwGSxD6+mX1JptfdJM9yuuDThVrvtFsBgcyuK12YCKlt7Fcnr9Xp7bbUiUNZ0 trEEMFjdiqIobqsBqGiymU2AqbKyRARMhWa7c+QDOqwACi1NPV1tFQYAFb2KdO2DKIFWu1dX00d+ RYNtgrXvZ+fepGnj02V2mWLGRii0tElqsUxWr6L0NBQCZb2K0ttUAeR3KUqX1QTR4vV/OK/dBFS0 Dr5sddXmQzS7AzyI0yzCYLapN7NZTBDNTq/NBJQ09ARlu+LSlDKWP2p3miq7vIrbZgbEVufg+4na Lq/dkg8A+ZUNjXUlIoBCh98ebasUYaodfE/hbBUBq8Md6EFMQEWvoiiK4u2pA9DQI9ktBhhGv8uZ 3nYR+eNyMTSeOnvPt5MgQdbOzUhP1QH49iMWiP/njO/hzv990GCxp/s6C3LLUVYndbe//5sG2DP/ b3vnX4pZg4s4DC6QPvg0y1h1F+ztffK1D3LuQztainOE4qH/sGE91ONgmSnh3uY45QHKGuyl30y6 LAGYm7EoVQNg1YYSFDf+tj/rygk7Ku5fqvvDrzxARe/rz6cDG1c3Nafkvn3mf2WtSlYf43cn7YZt Kwd3Z+K8TKDvsqwP8CDqavflw//1noveBQMQ193J1YIp6JgxGodhyfJF6boRF+lWrivD7tcPWj9q QMmrKwDHXBHiL7as2Kdef2B9zpc29+urhl6u3MBN8wafZr0ffwDxzjTNNQ+iOTsXKKxz/GPeYq8M X89Htv6b9LgMXF1Nn2bIDdyauTg1fVRHlm6vNKyxWud5DpisjlTg9wNuiGmDN9KnZgI3aYdfJbR/ thwtfX8c/Jd0+XMgb64m0IP0QjT32X6g88pa+cK/nf5ipaj//Qdh2lKadSI9HaSwmnCPjzyoaGgL dAzIpp7kMI0+QOS1mwHzyAudFgNgMvd4FclpKwHEitZADyI1FAJiZZdbUdyOMgCFjYrXZgDMtpEn Z6a7XXFpwq32P6g41v9MqasOACA29SmKongdVgCVjQ5J8bZa8gGT3e+gYk9DCSA2OJyK4m4oE4GS nkAP0tdaAYi19j5F8baaDYDJISk2s0GstAVlu4j8cTZGowyufa7+PVcb4BbiusdENGzYvW7UG3sJ g0vd+0l+/HDrBxn3LE4sBgBTZddzdwd6EM3Gn9jL7hKXJe0BALHCYV4HdGQA0PIpOn1abQKQpP6d 5PfTBP40S++tNGBPxp47UwFAl5Vvs36Us37FHgCAualnpd90fNHG8tqSZtMK9Uivoc5evijQg6Te HWC1+47QbCMRl+CcXSK06Kqv/7xTQmJaevK4UZJd/X2yRp+cPOXl0WfnYrKh22rZ43L5ZI0+NVkX 4FpP/3nnZaRkpI+/n6a92v3s3Js0bXy6zC7x+gIRr9s1vnjd6njdLgoRfv2ZiIhiGDNGREQxjOfP KQg8rn6fDJ0+VR/oVAoRUehwNkYT6zxSNGKx+7y9p88PLbTn6dibJySlpKWlpSUlCgVVJ0evcO/r KBCEmg6Pp71KEKpcgOzqPt3eza+DRSvf6frqgjyjMa/oyKnxlgW+unw+UUQxYzQxyXMBKBtcHd3W tBnlazIeaD4vA776H4jl7kp7r9PrdTsazYf3rC841DnyzlIvMCDJiZkbm5o26gGce2NNzhvMWHRq r9m+Zstrdz72YokRO+9ZfKhzzB810ACAWwrf0IgCY8ZoMtwQF92mro6+yvjSWz1laMn9aSsgXeyF mLd+ZXqyTqfPWvdMa2XhbTeOvOvQN89k56fv/PpTV2f9WnEPsOeB0iOeQOugUyT5Oip2N5jtp5/Z aNz4TE2b1XyrVvJ11xeU1tQfKlXnXmeba4yCIGQXPLd/P5AU6IuFRGHFjNE0LNpsNuAXH7ugnb8c 9mIxr3Rv/clT3edddz9f8+PNWQHvI33VeaC8Bxl3lpgLgfyS7asT+5u/s2L9Z4Y6u6N1zWfF4nde nuB3OSnE5Av/0QB89W/VBdlCtrGge8XmdUv10uWLhw/s3rLrc3PtM3p79eLc3RmVDW0/zW0+aI/0 eIkAfsSDpkeboK4Nodv8j32NqyyWV8u3HFCvyW/s+ed1t3g6P/uDBEA7f8Xi4fvoAOj0ix5YezuQ sHb1UkfND+2o6H1pczqw3Fq3b/GW35x9duMiPicjxuu+CKB890lrQ2Num2XnmoxzbX1PzgUgNjnf MiajvfrvYKq1Pr9RA3xgcyflvBXpIRNxNkbT0n+2AZk3J8LX79KsK3rprY8Ur9vpaK0tFA+v3/Uv /3XGukIURVEUVxy+9hMAXgnAgAQA6jrogiAIiYu3AOi56A3zhtC1ah2/fHTjukd//LpFRO37/wkA mD9PA8D3nx+2iMaswTca2oTIjZHoKmaMJuvqWRBPe/U+GNav1Hk+SktLOdItA9Dpk7Pu3vF8qQkX B3SrnnUPeiZ57AeU1HXQJcnt9nqdPU2NrY+I/B2PSNJqEwCkzFe/NqFNmA//3Q7gCmD/6v8N3TjM oyMKjBmjyUiC/eyHHZ0dHR2nT9UX3ZXTgPyf7FgJ/a1lwM7vl58+75FlX3/3qZ/uV2dpGv2gQN8j kwD8oc8jL/yGAfbX/tXh0uvx4eu7ctf/w8VwbxeNoMsylAF79tef9/n6O36+vwWbv7VQvUoCAN1f bilE+dP1nS74zv7Lj3YPrztMFEE8D0ET0ybcAuy7Rxz8STExv6L17edW6QEsKu9purgxd03G4FUw VditO0a2S3t1oXoRALQ3pQPFy5JudSoB1kGniFpU5mhoW2FS96epouHpu1PRgeHfOli08e9qC+/b siIFgJhvAvTgnIwijUtwzi6hWXRVdp3vdUvauUkpgVdEv/YOPp+s0eg0GsxgHXR/s3Mx2VBttezr 73Miccy96eo/L2v0qcmhOgI8O/cmTRufLrNLvL5AxOt2jS9etzpet4tChOfGiIgohjFjREQUw3hK fXZR1/aN9CiCLy43akLcm0TguTEiIoppPKhIREQxjBkjIqIYxowREVEMY8aIiCiGMWNERBTDmDEi IophzBgREcUwZoyIiGIYM0ZERDGMGSMiohjGjBERUQxjxoiIKIYxY0REFMOYMSIiimHMGBERxTBm jIiIYhgzRkREMYwZIyKiGMaMERFRDGPGiIgohjFjREQUw5gxIiKKYcwYERHFMGaMiIhiGDNGREQx jBkjIqIYxowREVEMY8aIiCiGMWNERBTDmDEiIophzBgREcUwZoyIiGIYM0ZERDGMGSMiohjGjBER UQxjxoiIKIYxY0REFMOYMSIiimHMGBERxTBmjIiIYhgzRkREMYwZIyKiGMaMERFRDGPGiIgohjFj REQUw5gxIiKKYcwYERHFMGaMiIhiGDNGREQxjBkjIqIY9v8BQdl+7yb0vNQAAAAASUVORK5CYII= --e89a8f22c70535b6dd04bf832e07-- From ichiroumakino@gmail.com Tue May 8 02:52:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1759D21F8582 for ; Tue, 8 May 2012 02:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwzUH0G+wtyv for ; Tue, 8 May 2012 02:52:19 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9B21F8581 for ; Tue, 8 May 2012 02:52:19 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so368245wib.13 for ; Tue, 08 May 2012 02:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UvfhNXnOopxjc2bbe40UKPOVDZITmsdqIka+stdMKYU=; b=uG4ARGqeQDau7WMCDcWO0giGZJE72xBNSWobD9XEyOd7XMC9yjNWI7+iuSu8wrGkDT V6b3Pb3i/j2TBFQ3EiihQlmTiJW2vTp5Fcmt0Y69HIE3c3ZYBszIGBhuPKZgiNXRhssP wb3rRQ6CvLXLbtUhtTbXeBEGdn/TmHTplzw9YstCXsdIzN1OIfOsjEoEra4rERVjdNNK 92hjRSmLfOJDCtTCovnIPeCnRy/KIpVbv5yI1Ed++TFxiQsztGEKTFDyajy8TIDue+OL QcqaBfKreP/bdURdrJBIFcWNMggCtHkRQUtsMZT/Gc4P08t8pJ1zR7YB6KzNp2nTndLo iknQ== Received: by 10.180.97.41 with SMTP id dx9mr43016253wib.9.1336470738419; Tue, 08 May 2012 02:52:18 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j3sm44278161wiw.1.2012.05.08.02.52.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 02:52:17 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 8 May 2012 11:52:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> To: Hans Liu X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 09:52:20 -0000 > How about run IPv4 and IPv6 provisioning in parallel. Cache 6rd option = and DS-Lite option if there is one. Try bring up the native connections, = either IPv4 or IPv6 or Dual stack, first. then take bring up the virtual = interfaces via the cached 6rd or DS-Lite option. And again run = IPv6/IPv4 provisioning when lease time out of a IPv4/IPv6.=20 >=20 > For example, a device gets native IPv4, and 6rd and no native IPv6. = Later on, ISP may start their deployment of native IPv6. When IPv4 lease = time out, the device re-process IPv6 and IPv4 provisioning, and it may = now get both 6rd option and native IPv6. =20 yes, how long do you wait until you terminate native IPv4 and IPv6 = provisioning? or do you continue to try native v6/v4 forever and are prepared to tear = down the virtual connections? and by the way, for this to work we all have to agree on which mechanism = is preferred. native IPv6 over 6rd seems fair. do we all agree that for IPv4, a CPE should prefer a DS-lite connection = over a native one? cheers, Ole >=20 > =20 >=20 > Best regards, > Hans >=20 > On Tue, May 8, 2012 at 4:53 PM, Ole Tr=F8an = wrote: > Forced single homing can be done. but at the expense of creating = dependencies between IPv4 and IPv6 provisioning. > see the attached flow charts. first one for multi-homing, second for = forced single homing. >=20 > how a forced single homed CPE is to deal with changes (link failure = for one protocol, lease times out for IPv4 address or IPv6 prefix...) is = left as an exercise for the reader. ;-) >=20 > cheers, > Ole >=20 > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > --=20 > Instead of following the fashion, we lead it through. From despres.remi@laposte.net Tue May 8 03:08:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B73E21F8570 for ; Tue, 8 May 2012 03:08:04 -0700 (PDT) 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.458, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JGUIFRI9Ken for ; Tue, 8 May 2012 03:08:03 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6614C21F857F for ; Tue, 8 May 2012 03:08:01 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 14B2D940060; Tue, 8 May 2012 12:07:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120508102426kawashimam@mail.jp.nec.com> Date: Tue, 8 May 2012 12:07:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81D370EB-9D3C-4116-8E49-DD6BF427D676@laposte.net> References: <20120508012117.23302.51227.idtracker@ietfa.amsl.com> <20120508102426kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 10:08:04 -0000 Le 2012-05-08 =E0 03:24, Masanobu Kawashima a =E9crit : >=20 > Folks, >=20 > We have published draft-ietf-v6ops-464xlat-03. > Can we move forward to WGLC? The new draft has none of the following, discussed on the mailing list, = and IMHO still worth dealing with before WGLC:=20 (1) NAT44 should be a MUST in all cases where the CE node acts as a = router. (2) A well-known 464XLAT interface ID should better be used in CLAT = addresses. With it, CLATs never need dedicated prefixes (=3D> only one = case in sections 7.2 and 7.5). (3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a = substance to "It is also possible to provide single IPv4/IPv6 = translation service, which will be needed in the future case of = IPv6-only servers and peers to be reached from legacy IPv4-only hosts.") Besides, some detail suggestions: In Figures: - Below PLAT, add NAT64 to clarify that PLAT is no more than a new name = for a NAT64 of RFC6146. In 4.1: - Replace "one IPv4 address can support millions of simultaneous = translations" by "one IPv4 address can support more simultaneous = translations than with stateless solutions". - Replace "stateless address sharing... are simply not IPv4-efficient = enough to solve...", by "stateless address sharing... are not = IPv4-efficient enough to solve in all cases...".=20 In 4.3: - Replace "especially cost-effective in wireless 3GPP...", by = "especially cost-effective in Pre-Release 9 wireless 3GPP...".=20 In 6.1:=20 - Replace "the ISP can provide IPv4 service" by "the ISP can provide = outgoing IPv4 service". Regards, RD >=20 > Changes are: >=20 > - Section 7.5. IPv6 Prefix Handling > - Clarified the language. >=20 > - Added new section "7.6. Relationship between CLAT and NAT44" >=20 > Regards, > Masanobu >=20 >=20 >>=20 >> 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. >>=20 >> Title : 464XLAT: Combination of Stateful and Stateless = Translation >> Author(s) : Masataka Mawatari >> Masanobu Kawashima >> Cameron Byrne >> Filename : draft-ietf-v6ops-464xlat-03.txt >> Pages : 15 >> Date : 2012-05-07 >>=20 >> 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 mobile and wireline IPv6-only edge networks = without >> encapsulation. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>=20 >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=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 > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From hansliu@gmail.com Tue May 8 03:21:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCDF21F84AF for ; Tue, 8 May 2012 03:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Estw1cWl6jm7 for ; Tue, 8 May 2012 03:21:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E319C21F8562 for ; Tue, 8 May 2012 03:21:10 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4670909lbb.31 for ; Tue, 08 May 2012 03:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rvczBi76R8D7ual/FgCx/1//eqlq2nPNdLpRY6sVkiU=; b=bBCXHCdLAr8mT7VH3Bd/VGLRvPsd56DkxGvBOas3UkBAvVn8qHuYRbUx6YWEDHfpxf qX0x9KL80pihVjF6xb2iVklVxSGczytQS4NnnGV/uq3NdiDaOg2Y1ICGqp3mLXoDu9ge CwxAp5AzJ0q+Ok7XP4ywJcw1PaW7WORg458qERpXoD2oja71BI30hJfV0cHUdr+vtakt p+CIwdHC/YsrpUld/mF3CYAFMkLOTkhhdd60uWg/B7QVxBl/qL3gymfJrrtrWciKHm9r F9rS+jSmsieuhxO0AgySqBzulrr9hZLjRqYA6BtK3reJRlcA4Iwikj2ziewXVKhjeqsD SKog== MIME-Version: 1.0 Received: by 10.152.148.34 with SMTP id tp2mr4256632lab.47.1336472469892; Tue, 08 May 2012 03:21:09 -0700 (PDT) Received: by 10.112.43.8 with HTTP; Tue, 8 May 2012 03:21:09 -0700 (PDT) In-Reply-To: References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> Date: Tue, 8 May 2012 18:21:09 +0800 Message-ID: From: Hans Liu To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 10:21:12 -0000 On Tue, May 8, 2012 at 5:52 PM, Ole Tr=C3=B8an wrote= : >> How about run IPv4 and IPv6 provisioning in parallel. Cache 6rd option a= nd DS-Lite option if there is one. Try bring up the native connections, eit= her IPv4 or IPv6 or Dual stack, first. then take bring up the virtual inter= faces via the cached 6rd or DS-Lite option. =C2=A0And again run IPv6/IPv4 p= rovisioning when lease time out of a IPv4/IPv6. >> >> For example, a device gets native IPv4, and 6rd and no native IPv6. =C2= =A0Later on, ISP may start their deployment of native IPv6. When IPv4 lease= time out, the device re-process IPv6 and IPv4 provisioning, and it may now= get both 6rd option and native IPv6. > > yes, how long do you wait until you terminate native IPv4 and IPv6 provis= ioning? > or do you continue to try native v6/v4 forever and are prepared to tear d= own the virtual connections? [Hans]: I don't know how long a delay it may occur, so far, thanks my ISP, my IPv6 provisioning or IPv4 provisioning experience are good. MOHO, one or two retry. If it fails, it fails. Wait for next run. How about that? > > and by the way, for this to work we all have to agree on which mechanism = is preferred. > native IPv6 over 6rd seems fair. > do we all agree that for IPv4, a CPE should prefer a DS-lite connection o= ver a native one? [Hans]: I thought we agreed to focus on 6rd and native IPv6 first. > > cheers, > Ole > > >> >> >> >> Best regards, >> Hans >> >> On Tue, May 8, 2012 at 4:53 PM, Ole Tr=C3=B8an wr= ote: >> Forced single homing can be done. but at the expense of creating depende= ncies between IPv4 and IPv6 provisioning. >> see the attached flow charts. first one for multi-homing, second for for= ced single homing. >> >> how a forced single homed CPE is to deal with changes (link failure for = one protocol, lease times out for IPv4 address or IPv6 prefix...) is left a= s an exercise for the reader. ;-) >> >> cheers, >> Ole >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> -- >> Instead of following the fashion, we lead it through. > --=20 Instead of following the fashion, we lead it through. From brian.e.carpenter@gmail.com Tue May 8 03:35:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8998821F857F for ; Tue, 8 May 2012 03:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTD+pMZk6TKe for ; Tue, 8 May 2012 03:35:32 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C868A21F855B for ; Tue, 8 May 2012 03:35:31 -0700 (PDT) Received: by eabd1 with SMTP id d1so1301165eab.31 for ; Tue, 08 May 2012 03:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Uy/6nvf3c901xM0+COjKa+rwcYslr9SG5GtM5WNgtto=; b=okccgymMRWnjvyYsVWGpQD5Mv5zNfxpOmKS59KimW8KaFVwRD+9yAxR+/UDV8AN+RD +39YGTeMTOMOa9/wAxerHJEkofP4EMVMiLRKo0RyJwSPSwNrKz+QL0eUi2q1CL09b8Pe jSRnwLS93kPFtbf8X7xSRzBFl5Vp4RF6pCQqvGvsqqxrdCJkIHzaP/OmYIfQNxgjZHYV bXK3W2mneL1/kNeHLXwEIB/eeumpgErB2wmt/8GjUmgxhL23GSDNdbUtEbVmqbd/wjYj DMxNndO4o91ekViY89rZYzUUW0wE+xQg0dEY3HHC37dxQbL4B10ez3o6NcozwPuoJ0be fUng== Received: by 10.14.98.75 with SMTP id u51mr763990eef.35.1336473331006; Tue, 08 May 2012 03:35:31 -0700 (PDT) Received: from [128.232.110.88] (c088.al.cl.cam.ac.uk. [128.232.110.88]) by mx.google.com with ESMTPS id u10sm84508278eem.1.2012.05.08.03.35.29 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 03:35:30 -0700 (PDT) Message-ID: <4FA8F6ED.2010008@gmail.com> Date: Tue, 08 May 2012 11:35:25 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] FYI [Fwd: I-D Action: draft-carpenter-flow-label-balancing-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, 08 May 2012 10:35:32 -0000 This is the first of two drafts that will replace draft-carpenter-v6ops-label-balance. We will be working on this topic but not in v6ops. Brian -------- Original Message -------- Subject: I-D Action: draft-carpenter-flow-label-balancing-00.txt Date: Tue, 08 May 2012 03:31:37 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the IPv6 Flow Label for Server Load Balancing Author(s) : Brian Carpenter Sheng Jiang Willy Tarreau Filename : draft-carpenter-flow-label-balancing-00.txt Pages : 12 Date : 2012-05-08 This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-flow-label-balancing-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-carpenter-flow-label-balancing-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-carpenter-flow-label-balancing/ _______________________________________________ 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 ichiroumakino@gmail.com Tue May 8 03:55:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDED21F8567 for ; Tue, 8 May 2012 03:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOky-Wory146 for ; Tue, 8 May 2012 03:55:15 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A785721F8565 for ; Tue, 8 May 2012 03:55:14 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4069839wgb.13 for ; Tue, 08 May 2012 03:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TMI/5N2qDUq3ecMWXr6BS8nUEl2MkEVtPDGNZNoR/XY=; b=DNrrsHYmL6oIc55JauuewdwP2oWKeCnJNQ6cjEQs38SxAUeKMoK1cXl5ji0HWR/f3z 9MWCqKQJMoa3EFaOjOTMQSfePWoIjhSf8/Oomhir9lFAnWUFmZ7VdIWtoF6/Q7xefUOS gGNoFbRgfH5nvwG5W+/mseFagWAyF/OoudIJ/yYzHP8nBPXivfsjJHdFjeaUXCqVLXSh ai5WaE/udmdTWZ9yWYKxRCQ89NPiV+8Bhfbea89Q//W+0fMuC4wQCxeQM+6SWhRi4CVD 4GTB5rvIFFcIhDv8JvAEZXQBBM3zcptknW1WbUBLNIBysyoBdtyqKVKFMNQazHZvLIfD NtgA== Received: by 10.180.84.4 with SMTP id u4mr31706815wiy.2.1336474513859; Tue, 08 May 2012 03:55:13 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l5sm28399885wia.11.2012.05.08.03.55.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 03:55:13 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 8 May 2012 12:55:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> To: Hans Liu X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 10:55:15 -0000 >>> How about run IPv4 and IPv6 provisioning in parallel. Cache 6rd = option and DS-Lite option if there is one. Try bring up the native = connections, either IPv4 or IPv6 or Dual stack, first. then take bring = up the virtual interfaces via the cached 6rd or DS-Lite option. And = again run IPv6/IPv4 provisioning when lease time out of a IPv4/IPv6. >>>=20 >>> For example, a device gets native IPv4, and 6rd and no native IPv6. = Later on, ISP may start their deployment of native IPv6. When IPv4 lease = time out, the device re-process IPv6 and IPv4 provisioning, and it may = now get both 6rd option and native IPv6. >>=20 >> yes, how long do you wait until you terminate native IPv4 and IPv6 = provisioning? >> or do you continue to try native v6/v4 forever and are prepared to = tear down the virtual connections? >=20 > [Hans]: I don't know how long a delay it may occur, so far, thanks my > ISP, my IPv6 provisioning or IPv4 provisioning experience are good. > MOHO, one or two retry. If it fails, it fails. Wait for next run. How > about that? MAX_SOL_RT perhaps (2 minutes) or MAX_RTR_SOLICITATIONS * = RTR_SOLICITATION_INTERVAL? do we require predictable and consistent behaviour from CPEs with = regards to this? if not, we may as well leave it undefined, but then why isn't "MUST = support RFC5969" good enough? I would much prefer that than to specify "forced single homing"; a = solution I would not recommend that we implement at least. >> and by the way, for this to work we all have to agree on which = mechanism is preferred. >> native IPv6 over 6rd seems fair. >> do we all agree that for IPv4, a CPE should prefer a DS-lite = connection over a native one? >=20 > [Hans]: I thought we agreed to focus on 6rd and native IPv6 first. they are loosely correlated. we don't need to use the same solution, but = the same problem exists. if we rather want to leave this as implementation specific then that's = fine. as a CPE vendor I'm certainly going to make sure that my CPE works = on all possible access networks with whatever combination of transition = mechanism and native protocol available. ISPs will of course have to = deal with varying support and behaviour from the CPEs connected to their = networks. *sarcasm mode on* two requirements then. 6RD-1: An IPv6 CE router MUST support 6rd [RFC5969]. DSW-1: An IPv4 CE router MUST support DS-lite [RFC6333] and the DS-lite = DHCP option specified in RFC6334. cheers, Ole= From brian.e.carpenter@gmail.com Tue May 8 04:42:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5826821F8546; Tue, 8 May 2012 04:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.262 X-Spam-Level: X-Spam-Status: No, score=-103.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MjFqmNyCJiM; Tue, 8 May 2012 04:42:42 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1247D21F8495; Tue, 8 May 2012 04:42:41 -0700 (PDT) Received: by eekd4 with SMTP id d4so630016eek.31 for ; Tue, 08 May 2012 04:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KTp5jySrIdGM6i0kDhuJ7EQNePYJAgC3WLNZgWVA0wY=; b=YXoLm7w4rM8BoHknwj85f8++ETcZfgB7u+/UfemsLWBpFJYTFaH/VSGWZb+LytrqqG rSXQFuE+SKr8dnjljNj1ClWtDkNO6/z0JuiQN9vSAdkyJd33gqUUYk8PSO4ok1jIe1TN 85W56SggxrgozawBC9CEo8ZtPTjr7AyJknoRfDOlqB7UN9GXcobtUbrh6/Fr8x5hz6GK Zn5c9txLjrAf9i/4fF4YcXY38ocuqBN/DeIM4bMeh6BDaaIj7z1ax8CXuofoHhL2Ht3o AWJzw2/WYuN5+ea/oH0xb1v6j6FJ9dNSP3teP2JCE6t1MWVAWAHF6gkhGZIbAT5+0Khj rFSg== Received: by 10.213.105.196 with SMTP id u4mr870859ebo.92.1336477361256; Tue, 08 May 2012 04:42:41 -0700 (PDT) Received: from [128.232.110.88] (c088.al.cl.cam.ac.uk. [128.232.110.88]) by mx.google.com with ESMTPS id u10sm85348391eem.1.2012.05.08.04.42.39 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 04:42:39 -0700 (PDT) Message-ID: <4FA906AB.40504@gmail.com> Date: Tue, 08 May 2012 12:42:35 +0100 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: <20120418143817.19669.70000.idtracker@ietfa.amsl.com> <829911B8-D986-4381-92FE-C85F2C260EB5@gmail.com> <4FA4AE23.2090408@bogus.com> In-Reply-To: <4FA4AE23.2090408@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Internet-Drafts@ietf.org Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-icp-guidance-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, 08 May 2012 11:42:43 -0000 ... >>> 6. Load Balancers >>> >>> It is to be expected that IPv6 traffic will initially be low, i.e. >>> a small percentage of IPv4 traffic. For this reason, updating >>> load balancers to fully support IPv6 can perhaps be delayed; >>> however, such >>> >> However, anyone deploying a load balancer is also probably relying on >> it providing fail-over protection and so needs to be aware that by >> deferring IPv6 support they lose that as well, not just the >> load-balancing. > > sorry for the late reply but what of the major commercial on open-source > load balancers does not support ipv6 in released code? Indeed, but that is not the same thing as an IT manager *deploying* the latest released code. What we are saying is don't worry too much until you see the IPv6 traffic building. IMHO that goes for the failover argument too. Brian > > imho, as a DC operator, stacking stateful tranforms is expensive and > more sensitive to the perturbations of the larger number of elements. If > it causes me to lose access to the source IP in the process then it's > still more effort to debug te activity of the v6 customers. > >> >> >> >> _______________________________________________ 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 Tue May 8 04:56:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D084921F854F; Tue, 8 May 2012 04:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlkTmYVLKHua; Tue, 8 May 2012 04:56:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5024F21F8549; Tue, 8 May 2012 04:56:14 -0700 (PDT) Received: from wifi-208-85.mtg.afnog.org (wifi-208-85.mtg.afnog.org [196.200.208.85]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q48Bu2jK049741 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 8 May 2012 11:56:05 GMT (envelope-from joelja@bogus.com) Message-ID: <4FA909D2.3080000@bogus.com> Date: Tue, 08 May 2012 11:56:02 +0000 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <20120418143817.19669.70000.idtracker@ietfa.amsl.com> <829911B8-D986-4381-92FE-C85F2C260EB5@gmail.com> <4FA4AE23.2090408@bogus.com> <4FA906AB.40504@gmail.com> In-Reply-To: <4FA906AB.40504@gmail.com> Content-Type: text/plain; charset=UTF-8 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, 08 May 2012 11:56:12 +0000 (UTC) Cc: IPv6 Ops WG , Internet-Drafts@ietf.org Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-icp-guidance-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, 08 May 2012 11:56:14 -0000 On 5/8/12 11:42 , Brian E Carpenter wrote: > > ... >>>> 6. Load Balancers >>>> >>>> It is to be expected that IPv6 traffic will initially be low, i.e. >>>> a small percentage of IPv4 traffic. For this reason, updating >>>> load balancers to fully support IPv6 can perhaps be delayed; >>>> however, such >>>> >>> However, anyone deploying a load balancer is also probably relying on >>> it providing fail-over protection and so needs to be aware that by >>> deferring IPv6 support they lose that as well, not just the >>> load-balancing. >> >> sorry for the late reply but what of the major commercial on open-source >> load balancers does not support ipv6 in released code? > > Indeed, but that is not the same thing as an IT manager *deploying* > the latest released code. What we are saying is don't worry too > much until you see the IPv6 traffic building. IMHO that goes for > the failover argument too. Given me a little bit of a break Brian. I've got f5's in production running ipv6 code from 2 years ago. netscalar users do too. so do A10 users ha-proxy etc. Eventually you've got to deploy ipv6 services to your customer by deploying ipv6 facing services not by stacking hackjob transition technologies in front of production load balancers. If someone wants to do the later, hey that's cool, but it doesn't seem like a solid recommendation for us to offer. > Brian >> >> imho, as a DC operator, stacking stateful tranforms is expensive and >> more sensitive to the perturbations of the larger number of elements. If >> it causes me to lose access to the source IP in the process then it's >> still more effort to debug te activity of the v6 customers. >> >>> >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From cb.list6@gmail.com Tue May 8 05:35:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B0721F84C5 for ; Tue, 8 May 2012 05:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwnDxkNnoucZ for ; Tue, 8 May 2012 05:35:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49C21F848F for ; Tue, 8 May 2012 05:35:15 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8080382pbc.31 for ; Tue, 08 May 2012 05:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bFmmRLmtJOL2hNPkFjN1JxeMpjWZP0KjD+j93nB2f3A=; b=QAhoByfC/tEbv1ogjzOxIh3ODXrv0dkrloL5hjUB31s3PzvBX/4EitnUYNAlAYdloT 5twHyNiF5gNKrZ6t/ZZrjhHiX40HLRAm/F0bJSYJx60DEJa5KnQyCegwoK78Kc5VzpDQ 2/DO7dKaNdRMFsPLZkQ2oHgePPRUqHP3nTtSqjzj86P1DEiFXxGMVYAb2IfyUgQ6/7u5 RzYwjITdi6ND8zlJ+Luaw+CYGayXgxqo4OjIiURfaNdHSR9idN6c4qxMhVwS+3kvQBQj 8Nz/p2wt07sOZ+nddnND1EWCUdzu3MaRcMBZrPEAP210e5fYEEeSO1aQVdSoHDRslDej u6qA== MIME-Version: 1.0 Received: by 10.68.244.40 with SMTP id xd8mr39911148pbc.132.1336480514979; Tue, 08 May 2012 05:35:14 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Tue, 8 May 2012 05:35:14 -0700 (PDT) In-Reply-To: <81D370EB-9D3C-4116-8E49-DD6BF427D676@laposte.net> References: <20120508012117.23302.51227.idtracker@ietfa.amsl.com> <20120508102426kawashimam@mail.jp.nec.com> <81D370EB-9D3C-4116-8E49-DD6BF427D676@laposte.net> Date: Tue, 8 May 2012 05:35:14 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 12:35:16 -0000 R=E9mi, Thanks for the review On Tue, May 8, 2012 at 3:07 AM, R=E9mi Despr=E9s = wrote: > > Le 2012-05-08 =E0 03:24, Masanobu Kawashima a =E9crit : > >> >> Folks, >> >> We have published draft-ietf-v6ops-464xlat-03. >> Can we move forward to WGLC? > > The new draft has none of the following, discussed on the mailing list, a= nd IMHO still worth dealing with before WGLC: > (1) NAT44 should be a MUST in all cases where the CE node acts as a route= r. > (2) A well-known 464XLAT interface ID should better be used in CLAT addre= sses. With it, CLATs never need dedicated prefixes (=3D> only one case in s= ections 7.2 and 7.5). > (3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a subst= ance to "It is also possible to provide single IPv4/IPv6 translation servic= e, which will be needed in the future case of IPv6-only servers and peers t= o be reached from legacy IPv4-only hosts.") > I believe the discussion lead to these outcomes: 1. NAT44 does not add any utility in case where there can be a dedicated transition prefix. We took Ole's suggestion for resolving this matter by including both methods and leave it to implementation based on the implementer's circumstances. If the implementer chooses to do NAT44 in all cases, so be it. But we see no harm in providing choice here. It does not force any additional complexity. 2. The OUI idea was clever, but as you pointed out earlier today on the original thread, it did not gain much steam beyond the initial conversation. Using a dedicated prefix is not a bad thing, IPv6 addresses are plentiful. While reserving the OUI seems simple enough, i am concerned about the added confusion this somewhat unconventional method will create. 3. A reference to BIH does not seem required. I am not opposed to it, but this document is not required to enumerate all possible solutions, it is to describe one solution summarized in the introduction. We also do not include references to DS-lite .... > Besides, some detail suggestions: > In Figures: > - Below PLAT, add NAT64 to clarify that PLAT is no more than a new name f= or a NAT64 of RFC6146. > In 4.1: PLAT is clearly defined in section 3. > - Replace "one IPv4 address can support millions of simultaneous translat= ions" by "one IPv4 address can support more simultaneous translations than = with stateless solutions". The focus of this sentence is not to compare with stateless solution, the focus of this sentence is on "port overloading". Most people think of stateful NAT44 allows for 64,000 translation sessions, but we explicitly state that port overloading allows for millions of sessions per 1 IPv4 address. I believe this is a meaningful point to make in an IPv4 constrained world. > - Replace "stateless address sharing... are simply not IPv4-efficient eno= ugh to solve...", by "stateless address sharing... are not IPv4-efficient e= nough to solve in all cases...". > In 4.3: OK > - Replace "especially cost-effective in wireless 3GPP...", by "especially= cost-effective in Pre-Release 9 wireless 3GPP...". > In 6.1: OK > - Replace "the ISP can provide IPv4 service" by "the ISP can provide outg= oing IPv4 service". > In section 1 we state: "The 464XLAT IPv4 service is limited to application that function in a client server model and is not fit for IPv4 peer- to-peer communication or inbound IPv4 connections." CB > > Regards, > RD > > >> >> Changes are: >> >> - Section 7.5. IPv6 Prefix Handling >> =A0- Clarified the language. >> >> - Added new section "7.6. Relationship between CLAT and NAT44" >> >> Regards, >> Masanobu >> >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>> >>> =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : 464XLAT: Combination of Stateful= and Stateless Translation >>> =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Masataka Mawatari >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Masanobu Kawashima >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cameron Byrne >>> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-464xlat-03.txt >>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 >>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-07 >>> >>> =A0This document describes an architecture (464XLAT) for providing >>> =A0limited IPv4 connectivity across an IPv6-only network by combining >>> =A0existing and well-known stateful protocol translation RFC 6146 in th= e >>> =A0core and stateless protocol translation RFC 6145 at the edge. 464XLA= T >>> =A0is a simple and scalable technique to quickly deploy limited IPv4 >>> =A0access service to mobile and wireline IPv6-only edge networks withou= t >>> =A0encapsulation. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>> >>> The IETF datatracker page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ >>> >>> _______________________________________________ >>> 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=3D=3D=3D=3D >> NEC AccessTechnica, Ltd. >> Product Development Department >> Masanobu Kawashima >> 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=3D=3D=3D=3D >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From bs7652@att.com Tue May 8 06:18:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A8D21F854F for ; Tue, 8 May 2012 06:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.624 X-Spam-Level: X-Spam-Status: No, score=-105.624 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J13Oq6g6H60c for ; Tue, 8 May 2012 06:18:18 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A50C121F8546 for ; Tue, 8 May 2012 06:18:18 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id a1d19af4.6837f940.456690.00-583.1247284.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 08 May 2012 13:18:18 +0000 (UTC) X-MXL-Hash: 4fa91d1a4f3afc1c-c55b289317309760ffe4c2165f8d0d7fa71f4831 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id d0d19af4.0.456620.00-354.1247094.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 08 May 2012 13:18:06 +0000 (UTC) X-MXL-Hash: 4fa91d0e2076648d-de00c76f7832a3d2820c8976677a2b9cb390fa68 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 q48DI4ka031671; Tue, 8 May 2012 09:18:05 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q48DHsek031423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 09:18:01 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint04.pst.cso.att.com (RSA Interceptor); Tue, 8 May 2012 09:17:01 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.81]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.01.0355.002; Tue, 8 May 2012 09:17:01 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Hans Liu Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNKPSFHaTi59li002JhDEAyFznTpa36hwAgAAeRwCAAAKugIAAVn0AgAAG8ACAAASigP//1LVggABKDwCAAGLYAIAA8kyAgAADSwCAAAOtAIAAIUOAgAQVQACAADz5AIAAGGYAgAByhwCAAOqQAIAAEFeAgAANGQCAAAM5AP//9Znw Date: Tue, 8 May 2012 13:16:59 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110C1604@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.68.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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=1.0 c=1 a=3_JjInvpirMA:10 a=KJxBHbnaG1YA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=Q-b_2QG9gCYD1xSDWz8A:9 a=wPNLvfGTeEIA:10 a] X-AnalysisOut: [=izyZk9b4Z1ZYP0MM:21 a=UfpB04CV4j_Mqvgi:21] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 13:18:19 -0000 > do we all agree that for IPv4, a CPE should prefer a DS-lite connection o= ver a > native one? Is the native one giving me a CGN NATted IPv4 address, or a public IPv4 add= ress? I think I would prefer public IPv4 over DS-Lite over CGN. Barbara From simon.perreault@viagenie.ca Tue May 8 06:21:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F067721F854F for ; Tue, 8 May 2012 06:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WU4oBD37wxF for ; Tue, 8 May 2012 06:21:45 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 5718421F8555 for ; Tue, 8 May 2012 06:21:43 -0700 (PDT) Received: from [IPv6:2607:fa48:94:201:8da1:52bd:24aa:2520] (unknown [IPv6:2607:fa48:94:201:8da1:52bd:24aa:2520]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B0F5341590 for ; Tue, 8 May 2012 09:21:42 -0400 (EDT) Message-ID: <4FA91DE6.5040806@viagenie.ca> Date: Tue, 08 May 2012 09:21:42 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <0CC0C817-32B5-412B-A61A-3D27853E2047@laposte.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 13:21:50 -0000 On 2012-05-08 05:52, Ole Trĝan wrote: > yes, how long do you wait until you terminate native IPv4 and IPv6 provisioning? > or do you continue to try native v6/v4 forever and are prepared to tear down the virtual connections? The second option looks good. Take for example the venerable ISC dhclient. By default, after trying for 60 seconds it goes to sleep for 5 minutes, then it tries again for 60 seconds. It does this indefinitely. Most DHCP clients and network managers do something similar, never actually giving up. Then you implement the following simple event handlers: native v4 goes up with 6rd config ==> bring up 6rd if native v6 is down native v4 goes down ==> bring down 6rd if 6rd is up native v6 goes up ==> bring down 6rd if 6rd is up native v6 goes down ==> bring up 6rd if native v4 is up with 6rd config This can be extended for DS-Lite with either of these: a) with preference for native IPv4 over DS-Lite: native v6 goes up with DS-Lite config ==> bring up DS-Lite if native v4 is down native v6 goes down ==> bring down DS-Lite if DS-Lite is up native v4 goes up ==> bring down DS-Lite if DS-Lite is up native v4 goes down ==> bring up DS-Lite if native v6 is up with DS-Lite config b) with preference for DS-Lite over native IPv4: native v6 goes up with DS-Lite config ==> bring up DS-Lite, bring down native v4 if native v4 is up, and stop DHCPv4 client native v6 goes down ==> bring down DS-Lite if DS-Lite is up, and start DHCPv4 client if it is stopped native v4 goes up ==> nothing special native v4 goes down ==> nothing special A simple state machine... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From despres.remi@laposte.net Tue May 8 06:42:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8169F21F847F for ; Tue, 8 May 2012 06:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO6unnEWbioM for ; Tue, 8 May 2012 06:42:20 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4122121F84DF for ; Tue, 8 May 2012 06:42:18 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8F4CF9400F3; Tue, 8 May 2012 15:42:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 May 2012 15:42:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <280066FF-BC8C-4AEE-84A2-2A0185BDF8F6@laposte.net> References: <20120508012117.23302.51227.idtracker@ietfa.amsl.com> <20120508102426kawashimam@mail.jp.nec.com> <81D370EB-9D3C-4116-8E49-DD6BF427D676@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 13:42:21 -0000 Cameron, Please understand that the goal of comments below is to improve your = proposal (which AKAIK not so many people have studied in details). =20 2012-05-08 14:35, Cameron Byrne: > R=E9mi, >=20 > Thanks for the review >=20 > On Tue, May 8, 2012 at 3:07 AM, R=E9mi Despr=E9s = wrote: >>=20 >> Le 2012-05-08 =E0 03:24, Masanobu Kawashima a =E9crit : >>=20 >>>=20 >>> Folks, >>>=20 >>> We have published draft-ietf-v6ops-464xlat-03. >>> Can we move forward to WGLC? >>=20 >> The new draft has none of the following, discussed on the mailing = list, and IMHO still worth dealing with before WGLC: >> (1) NAT44 should be a MUST in all cases where the CE node acts as a = router. >> (2) A well-known 464XLAT interface ID should better be used in CLAT = addresses. With it, CLATs never need dedicated prefixes (=3D> only one = case in sections 7.2 and 7.5). >> (3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a = substance to "It is also possible to provide single IPv4/IPv6 = translation service, which will be needed in the future case of = IPv6-only servers and peers to be reached from legacy IPv4-only hosts.") >>=20 >=20 > I believe the discussion lead to these outcomes: >=20 > 1. NAT44 does not add any utility in case where there can be a > dedicated transition prefix. We took Ole's suggestion for resolving > this matter by including both methods and leave it to implementation > based on the implementer's circumstances. If the implementer chooses > to do NAT44 in all cases, so be it. But we see no harm in providing > choice here. =20 > It does not force any additional complexity. It permits the CLAT to always have only one IPv6 address. This is in my understanding a non negligible simplification, not = compensated by any loss of useful function. > 2. The OUI idea was clever, but as you pointed out earlier today on > the original thread, it did not gain much steam beyond the initial > conversation. The reaction I saw was favorable, with an intent to validate it, but no = more comment after that.=20 Besides, a reference to RFC6052 for both the CLAT and the CLAT = addresses, CLAT translators need to work with TWO IPv6 prefixes instead = of just one (that of the CLAT and that of the PLAT). This is a = requirement that AFAIK exists in no existing RFC (=3D> the solution is = more than a BCP).=20 > Using a dedicated prefix is not a bad thing, IPv6 > addresses are plentiful. While reserving the OUI seems simple enough, > i am concerned about the added confusion this somewhat unconventional > method will create. Getting simplicity by using an available mechanism IMHO the right way to = go.=20 Reserving an interface IDs is not "unconventional" since RFC5342 section = 2.2.2 and http://www.iana.org/assignments/ethernet-numbers have = provisions for that. (Which value to choose remains open AFAIAC, but = provided one is reserved.)=20 > 3. A reference to BIH does not seem required. > I am not opposed to > it, Good. (*) Without it, can you clarify the meaning of "It is also possible to = provide single IPv4/IPv6 translation service, which will be needed in = the future case of IPv6-only servers and peers to be reached from legacy = IPv4-only hosts."? =20 > but this document is not required to enumerate all possible > solutions, it is to describe one solution summarized in the > introduction. We also do not include references to DS-lite .... Sure, but see (*) above. >> Besides, some detail suggestions: >> In Figures: >> - Below PLAT, add NAT64 to clarify that PLAT is no more than a new = name for a NAT64 of RFC6146. >> In 4.1: >=20 > PLAT is clearly defined in section 3. Yes, ... as a ordinary NAT64 (very minor point anyway). >=20 >> - Replace "one IPv4 address can support millions of simultaneous = translations" by "one IPv4 address can support more simultaneous = translations than with stateless solutions". >=20 > The focus of this sentence is not to compare with stateless solution, > the focus of this sentence is on "port overloading". Most people > think of stateful NAT44 allows for 64,000 translation sessions, but we > explicitly state that port overloading allows for millions of sessions > per 1 IPv4 address. I believe this is a meaningful point to make in > an IPv4 constrained world. >=20 >> - Replace "stateless address sharing... are simply not IPv4-efficient = enough to solve...", by "stateless address sharing... are not = IPv4-efficient enough to solve in all cases...". >> In 4.3: >=20 > OK >=20 >> - Replace "especially cost-effective in wireless 3GPP...", by = "especially cost-effective in Pre-Release 9 wireless 3GPP...". >> In 6.1: >=20 > OK >=20 >> - Replace "the ISP can provide IPv4 service" by "the ISP can provide = outgoing IPv4 service". >>=20 >=20 > In section 1 we state: >=20 > "The 464XLAT IPv4 service is limited to application > that function in a client server model and is not fit for IPv4 peer- > to-peer communication or inbound IPv4 connections." Right, but repeating one word where it is clarifying shouldn't be a = problem (IMHO). RD =20 >=20 >=20 > CB >=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>>=20 >>> Changes are: >>>=20 >>> - Section 7.5. IPv6 Prefix Handling >>> - Clarified the language. >>>=20 >>> - Added new section "7.6. Relationship between CLAT and NAT44" >>>=20 >>> Regards, >>> Masanobu >>>=20 >>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Title : 464XLAT: Combination of Stateful and = Stateless Translation >>>> Author(s) : Masataka Mawatari >>>> Masanobu Kawashima >>>> Cameron Byrne >>>> Filename : draft-ietf-v6ops-464xlat-03.txt >>>> Pages : 15 >>>> Date : 2012-05-07 >>>>=20 >>>> 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 mobile and wireline IPv6-only edge networks = without >>>> encapsulation. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>>>=20 >>>> The IETF datatracker page for this Internet-Draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=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 >>> NEC AccessTechnica, Ltd. >>> Product Development Department >>> Masanobu Kawashima >>> 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=3D=3D=3D=3D >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From despres.remi@laposte.net Tue May 8 06:46:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A51C21F84DD for ; Tue, 8 May 2012 06:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLatziQnKlbB for ; Tue, 8 May 2012 06:46:56 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3B221F847F for ; Tue, 8 May 2012 06:46:54 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id CB1DF940196; Tue, 8 May 2012 15:46:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <280066FF-BC8C-4AEE-84A2-2A0185BDF8F6@laposte.net> Date: Tue, 8 May 2012 15:46:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120508012117.23302.51227.idtracker@ietfa.amsl.com> <20120508102426kawashimam@mail.jp.nec.com> <81D370EB-9D3C-4116-8E49-DD6BF427D676@laposte.net> <280066FF-BC8C-4AEE-84A2-2A0185BDF8F6@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 13:46:56 -0000 Le 2012-05-08 =E0 15:42, R=E9mi Despr=E9s a =E9crit : > ... > Besides, a reference to RFC6052 for both the CLAT and the CLAT = addresses, CLAT translators need to work with TWO IPv6 prefixes instead = of just one (that of the CLAT and that of the PLAT). This is a = requirement that AFAIK exists in no existing RFC (=3D> the solution is = more than a BCP).=20 Typo: a reference to RFC6052 for CLAT and PLAT addresses ... ^^^^ RD= From bs7652@att.com Tue May 8 06:53:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB86721F85A3 for ; Tue, 8 May 2012 06:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.848 X-Spam-Level: X-Spam-Status: No, score=-105.848 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9cSE-b2HmtE for ; Tue, 8 May 2012 06:53:25 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 7E82821F85B4 for ; Tue, 8 May 2012 06:53:25 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 55529af4.660cc940.468779.00-594.1280396.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 08 May 2012 13:53:25 +0000 (UTC) X-MXL-Hash: 4fa925556a3653ad-5d003f75cf03c548de60bb501937ab726015c604 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 15529af4.0.468763.00-479.1280345.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 08 May 2012 13:53:22 +0000 (UTC) X-MXL-Hash: 4fa92552069f6343-a54a0295547a4cdf1c80f494101014c6da4ace93 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 q48DrKnD019092; Tue, 8 May 2012 09:53:21 -0400 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 q48Dr7Dr018831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 09:53:10 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by sflint03.pst.cso.att.com (RSA Interceptor); Tue, 8 May 2012 09:52:50 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.81]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.01.0355.002; Tue, 8 May 2012 09:52:49 -0400 From: "STARK, BARBARA H" To: "Brzozowski, John" , Mark Townsley Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNKPSFHaTi59li002JhDEAyFznTpa+8uyAgAAAw4CAAADlgP//vZFQgABo/wCAAMR0QA== Date: Tue, 8 May 2012 13:52:48 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110C1664@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6110C1047@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.68.45] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6110C1664GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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=1.0 c=1 a=3_JjInvpirMA:10 a=KJxBHbnaG1YA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=6M] X-AnalysisOut: [yZ0KW2AAAA:8 a=wrju9itlAAAA:8 a=zQP7CpKOAAAA:8 a=2okMGNwhA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=hIvxMbWLBf0ykQEx0YgA:9 a=K2BwTxiJ] X-AnalysisOut: [Oo-3RGKYYGsA:7 a=CjuIK1q_8ugA:10 a=42WgJn5DhlwA:10 a=Q09VH] X-AnalysisOut: [gBEdo0A:10 a=Hz7IrDYlS0cA:10 a=GPDuAuAC4SAA:10 a=lZB815dzV] X-AnalysisOut: [vQA:10 a=kKD6nqZk_s5K-Pmb:21 a=DnUQ1o5Mei1LqlYO:21 a=yMhMj] X-AnalysisOut: [lubAAAA:8 a=SSmOFEACAAAA:8 a=5tncthOix1SOdw6qIuIA:7 a=gKO2] X-AnalysisOut: [Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=lOJ28hcd] X-AnalysisOut: [UxnSzKz0:21 a=vIvSs6pojNEpBIG2:21] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 13:53:30 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6110C1664GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, Yes. This is what I was responding to. This is a "sunsetting" requirement. = There is a proposal that when introducing native IPv6 for purpose of sunset= ting, that the provider provision the DHCPv6 server to hand out the same pr= efixes as what is being provided via 6rd. The idea, I believe, is that this= would make for a "seamless" migration from the customer's perspective. No = change in numbering. Or native IPv6 could be deployed with a distinct prefix from what is being = used for 6rd. I believe Gert did a very good job in an email sent today of weighing in on= the operational complexity of trying to do prefix matching. But you asked which of these options was being deployed. My response was th= at since they are options for sunsetting (that is, for native IPv6 deployme= nt in the presence of 6rd), and not for actual 6rd deployment, there are no= deployments of either. Nobody has sunset any 6rd deployments, yet. Personally, I agree with Gert that trying to do prefix matching seems very = complex to me. But I have no input into what the access network does. I dea= l with CE routers. I also agree that the CE router requirement adds complex= ity, though I don't know how much complexity. I usually try to design my ro= uters so that I'm ready for whatever those access network guys finally deci= de to throw at me. In this case, though, if it's considered too complex in = the CE router to support both, then maybe we should help the access network= guys make their decision, by only supporting one of the options in the CE = router. Of course, there's also the option of not supporting multi-homing a= t all in the CE router, and requiring the user to enable/disable 6rd. [BTW,= in my "poor man's migration", I would disable DHCPv6/RS if 6rd is enabled;= I think it would be ok to try DHCPv6 if 6rd was enabled but not manually c= onfigured or mgmt.-interface configured and DHCPv4 came back with no option= 212; basically this makes 6rd "preferred" if enabled. What I've been told,= is that 6rd implementations seen to date all require explicit enabling of = the function before the CE router will try to do 6rd. In my experience, use= rs tend to have not so much trouble when told to turn a function on or off.= What they tend to have trouble with is fill-in-the-blank configuration, li= ke logins, passwords, POP/SMTP servers, etc., or option overload like we se= e with privacy settings.] Barbara From: Brzozowski, John [mailto:John_Brzozowski@cable.comcast.com] Sent: Monday, May 07, 2012 5:05 PM To: STARK, BARBARA H; Mark Townsley Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) Barbara, My original email pertained to the following: 6RD-6: The CE router MUST allow different as well as identical delegated pr= efixes to be configured via each (6rd or native) WAN interface. >From someone who has not adopted 6rd, has no plans to, but has used the sam= e for trial this seems like it could add complexity. 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) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://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 From: Barbara Stark > Date: Mon, 7 May 2012 19:00:03 +0000 To: John Jason Brzozowski >, Mark Townsley > Cc: IPv6 Operations > Subject: RE: [v6ops] 6rd sunsetting requirements (version 3) I'm not clear as to which of the two options you're asking about. But it's = moot; the options are not for 6rd deployment models. They're for "6rd to na= tive IPv6" transition models. To the best of my knowledge, nobody has deplo= yed either such transition. I would guess that transition is far enough out= that both options are being assessed to determine which has the lesser ope= rational complexity. Operational complexity includes the amount of network = coordination needed, complexity of network element software, as well as the= potential call volume if customers find the transition to be noticeable. I= don't think operational complexity of either option has been fully determi= ned yet. But we might be able to influence an answer to the operational complexity q= uestion, by not including support for one or the other option in the CE rou= ter. Based, hopefully, on what is easier for the CE router. Barbara From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Brzozowski, John Sent: Monday, May 07, 2012 2:47 PM To: Mark Townsley Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) Does anyone know if this a popular deployment model for 6rd adopters? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://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 From: Mark Townsley > Date: Mon, 7 May 2012 20:43:19 +0200 To: John Jason Brzozowski > Cc: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) It is a requirement that allows a choice. - Mark On May 7, 2012, at 8:40 PM, Brzozowski, John wrote: Is the below really a requirement or a deployment choice that an operator m= ust individually manage? John From: Mark Townsley > Date: Thu, 3 May 2012 08:17:51 +0200 To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) 6RD-6: The CE router MUST allow different as well as identical delegated pr= efixes to be configured via each (6rd or native) WAN interface. --_000_2D09D61DDFA73D4C884805CC7865E6110C1664GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

Yes. This is what I was responding to. = This is a “sunsetting” requirement. There is a proposal that wh= en introducing native IPv6 for purpose of sunsetting, that the provider provision the DHCPv6 server to hand out the same prefixes as what is being= provided via 6rd. The idea, I believe, is that this would make for a ̶= 0;seamless” migration from the customer’s perspective. No chang= e in numbering.

 

Or native IPv6 could be deployed with a= distinct prefix from what is being used for 6rd.

 

I believe Gert did a very good job in a= n email sent today of weighing in on the operational complexity of trying t= o do prefix matching.

But you asked which of these options wa= s being deployed. My response was that since they are options for sunsettin= g (that is, for native IPv6 deployment in the presence of 6rd), and not for actual 6rd deployment, there are no deployments of eithe= r. Nobody has sunset any 6rd deployments, yet.

 

Personally, I agree with Gert that tryi= ng to do prefix matching seems very complex to me. But I have no input into= what the access network does. I deal with CE routers. I also agree that the CE router requirement adds complexity, though I don= 217;t know how much complexity. I usually try to design my routers so that = I’m ready for whatever those access network guys finally decide to th= row at me. In this case, though, if it’s considered too complex in the CE router to support both, then maybe we should help th= e access network guys make their decision, by only supporting one of the op= tions in the CE router. Of course, there’s also the option of not sup= porting multi-homing at all in the CE router, and requiring the user to enable/disable 6rd. [BTW, in my “p= oor man’s migration”, I would disable DHCPv6/RS if 6rd is enabl= ed; I think it would be ok to try DHCPv6 if 6rd was enabled but not manuall= y configured or mgmt.-interface configured and DHCPv4 came back with no option 212; basically this makes 6rd “preferred= 221; if enabled. What I’ve been told, is that 6rd implementations see= n to date all require explicit enabling of the function before the CE route= r will try to do 6rd. In my experience, users tend to have not so much trouble when told to turn a function on or off. What t= hey tend to have trouble with is fill-in-the-blank configuration, like logi= ns, passwords, POP/SMTP servers, etc., or option overload like we see with = privacy settings.]

Barbara

 <= /p>

From: Brzozows= ki, John [mailto:John_Brzozowski@cable.comcast.com]
Sent: Monday, May 07, 2012 5:05 PM
To: STARK, BARBARA H; Mark Townsley
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

 

Barbara,<= /p>

 

My original email pertained= to the following:

6RD-6: The CE= router MUST allow different as well as identical delegated prefixes to be = configured via each (6rd or native) WAN interface.  

From someone who has not adopted 6rd, has no plans to, but has used t= he same for trial this seems like it could add complexity.

 =

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<= /o:p>

Comcast Cable

m) +1-609-377-6594=

o) +1-484-962-0060=

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

From: Barbara Stark <bs7652@att.com>
Date: Mon, 7 May 2012 19:00:03 +0000
To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>, Mark Townsley <= ;mark@townsley.net>
Cc: IPv6 Operations <v6ops@ietf= .org>
Subject: RE: [v6ops] 6rd sunsetting requirements (version 3)

 

I’m not clear as to w= hich of the two options you’re asking about. But it’s moot; the= options are not for 6rd deployment models. They’re for “6rd to= native IPv6” transition models. To the best of my knowledge, nobody has deployed either= such transition. I would guess that transition is far enough out that both= options are being assessed to determine which has the lesser operational c= omplexity. Operational complexity includes the amount of network coordination needed, complexity of network = element software, as well as the potential call volume if customers find th= e transition to be noticeable. I don’t think operational complexity o= f either option has been fully determined yet.

 

But we might be able to inf= luence an answer to the operational complexity question, by not including s= upport for one or the other option in the CE router. Based, hopefully, on what is easier for the CE router.

Barbara

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brzozowski, John
Sent: Monday, May 07, 2012 2:47 PM
To: Mark Townsley
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)<= span style=3D"color:black">

 =

Does anyone know if this a popular deploymen= t model for 6rd adopters?

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=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) +1-609-377-6594

o) +1-484-962-0060

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D<= /p>

 

From: Mark Townsley <mark@townsley.net>
Date: Mon, 7 May 2012 20:43:19 +0200
To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
Cc: IPv6 Operations <v6ops@ietf= .org>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)<= span style=3D"color:black">

 

 

It is a requirement that al= lows a choice.

 

- Mark

 

On May 7, 2012, at 8:40 PM,= Brzozowski, John wrote:




Is the below really a requi= rement or a deployment choice that an operator must individually manage?

 

John

From: Mark Townsley <mark@townsley.net>
Date: Thu, 3 May 2012 08:17:51 +0200
To: IPv6 Operations <v6ops@ietf= .org>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)<= span style=3D"color:black">

 

6RD-6: The CE= router MUST allow different as well as identical delegated prefixes to be = configured via each (6rd or native) WAN interface.  

 

--_000_2D09D61DDFA73D4C884805CC7865E6110C1664GAALPA1MSGUSR9NIT_-- From cb.list6@gmail.com Tue May 8 06:56:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4114821F8562 for ; Tue, 8 May 2012 06:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuSZFXLJ-v2X for ; Tue, 8 May 2012 06:56:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1480F21F8555 for ; Tue, 8 May 2012 06:56:01 -0700 (PDT) Received: by dacx6 with SMTP id x6so8023098dac.31 for ; Tue, 08 May 2012 06:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fOgim/lXrZzB4fPhfRVOXDXMVK4TCIhtk/OMj30F6Do=; b=qCYZbj5I6w+bjrp5FIYl3R+jIGT8Erww6t0tbpjfHuxtb1wV4qjKxipWFZ7MYqNtp5 Ds0tU33dCi3CdFTJK6ow/srkKILt+EM7S4/MOH1TkF9PyTrrTTaQtTm2Pyv3IaQE+Mh5 O1DmWRkupfS67766VF1lnKdHdFy0YbALs11LV3BYPdGROo3K/lOrpvj5BFHMaWbiPwKm oLKsIz5D7oZD0hotqgNdc1gEqaKcYStdeyFYJ/2tpUdMybw9LIBscKH5OK4Acbc7fQUM p4WgPOd7X2IVpnKYXek8o3Fj1z56hmN5nlxi6grceO2tMFigr6CH5ZFezbW5JoCPjai3 0hLw== MIME-Version: 1.0 Received: by 10.68.135.226 with SMTP id pv2mr8500317pbb.127.1336485355905; Tue, 08 May 2012 06:55:55 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Tue, 8 May 2012 06:55:55 -0700 (PDT) Date: Tue, 8 May 2012 06:55:55 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 13:56:02 -0000 R=E9mi, If i may summarize your main points below, you want to eliminate the possibility of using 2 IPv6 prefix. It is unclear to me, and i don't want to debate generalities. Please provide specific advantages for the WG to consider. IPv6 was created with the notion that intefaces will have many IPv6 prefixs. And, the ONLY scenario that will use more than 1 IPv6 prefixes is when DHCP-PD is used in the access network, and therefore the CLAT will receive 1 prefix from the network, such as a /56 or /60 ... (1 for WAN, 1 for CLAT, n for LAN) ...I see no harm -- and possible simplification and utility in having a dedicated /64 from the delegated supernet for translation. As a network operator, if i can uniformly deploy so that a certain set of prefixes are known to be 464XLAT IPv4 reachable it makes my life easier when troubleshooting. Also, some folks believe that avoiding NAT44 in the CPE will reduce the complexity. Why do you want to remove this option? The NAT4464 option is open in the spec for anyone who wants to use it. I need to know why you want that to be only path. CB On Tue, May 8, 2012 at 6:42 AM, R=E9mi Despr=E9s = wrote: > Cameron, > > Please understand that the goal of comments below is to improve your prop= osal (which AKAIK not so many people have studied in details). > > 2012-05-08 14:35, Cameron Byrne: > >> R=E9mi, >> >> Thanks for the review >> >> On Tue, May 8, 2012 at 3:07 AM, R=E9mi Despr=E9s wrote: >>> >>> Le 2012-05-08 =E0 03:24, Masanobu Kawashima a =E9crit : >>> >>>> >>>> Folks, >>>> >>>> We have published draft-ietf-v6ops-464xlat-03. >>>> Can we move forward to WGLC? >>> >>> The new draft has none of the following, discussed on the mailing list,= and IMHO still worth dealing with before WGLC: >>> (1) NAT44 should be a MUST in all cases where the CE node acts as a rou= ter. >>> (2) A well-known 464XLAT interface ID should better be used in CLAT add= resses. With it, CLATs never need dedicated prefixes (=3D> only one case in= sections 7.2 and 7.5). >>> (3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a sub= stance to "It is also possible to provide single IPv4/IPv6 translation serv= ice, which will be needed in the future case of IPv6-only servers and peers= to be reached from legacy IPv4-only hosts.") >>> >> >> I believe the discussion lead to these outcomes: >> >> 1. =A0NAT44 does not add any utility in case where there can be a >> dedicated transition prefix. =A0We took Ole's suggestion for resolving >> this matter by including both methods and leave it to implementation >> based on the implementer's circumstances. If the implementer chooses >> to do NAT44 in all cases, so be it. =A0 But we see no harm in providing >> choice here. > >> It does not force any additional complexity. > > It permits the CLAT to always have only one IPv6 address. > This is in my understanding a non negligible simplification, not compensa= ted by any loss of useful function. > > >> 2. =A0The OUI idea was clever, but as you pointed out earlier today on >> the original thread, it did not gain much steam beyond the initial >> conversation. > > The reaction I saw was favorable, with an intent to validate it, but no m= ore comment after that. > > Besides, a reference to RFC6052 for both the CLAT and the CLAT addresses,= CLAT translators need to work with TWO IPv6 prefixes instead of just one (= that of the CLAT and that of the PLAT). This is a requirement that AFAIK ex= ists in no existing RFC (=3D> the solution is more than a BCP). > > >> Using a dedicated prefix is not a bad thing, IPv6 >> addresses are plentiful. =A0While reserving the OUI seems simple enough, >> i am concerned about the added confusion this somewhat unconventional >> method will create. > > Getting simplicity by using an available mechanism IMHO the right way to = go. > Reserving an interface IDs is not "unconventional" since RFC5342 section = 2.2.2 and http://www.iana.org/assignments/ethernet-numbers have provisions = for that. (Which value to choose remains open AFAIAC, but provided one is r= eserved.) > > >> 3. =A0A reference to BIH does not seem required. > >> =A0I am not opposed to >> it, > > Good. > (*) Without it, can you clarify the meaning of "It is also possible to pr= ovide single IPv4/IPv6 translation service, which will be needed in the fut= ure case of IPv6-only servers and peers to be reached from legacy IPv4-only= hosts."? > >> but this document is not required to enumerate all possible >> solutions, it is to describe one solution summarized in the >> introduction. =A0We also do not include references to DS-lite .... > > Sure, but see (*) above. > > >>> Besides, some detail suggestions: >>> In Figures: >>> - Below PLAT, add NAT64 to clarify that PLAT is no more than a new name= for a NAT64 of RFC6146. >>> In 4.1: >> >> PLAT is clearly defined in section 3. > > Yes, ... as a ordinary NAT64 (very minor point anyway). > >> >>> - Replace "one IPv4 address can support millions of simultaneous transl= ations" by "one IPv4 address can support more simultaneous translations tha= n with stateless solutions". >> >> The focus of this sentence is not to compare with stateless solution, >> the focus of this sentence is on "port overloading". =A0Most people >> think of stateful NAT44 allows for 64,000 translation sessions, but we >> explicitly state that port overloading allows for millions of sessions >> per 1 IPv4 address. =A0I believe this is a meaningful point to make in >> an IPv4 constrained world. >> >>> - Replace "stateless address sharing... are simply not IPv4-efficient e= nough to solve...", by "stateless address sharing... are not IPv4-efficient= enough to solve in all cases...". >>> In 4.3: >> >> OK >> >>> - Replace "especially cost-effective in wireless 3GPP...", by "especial= ly cost-effective in Pre-Release 9 wireless 3GPP...". >>> In 6.1: >> >> OK >> >>> - Replace "the ISP can provide IPv4 service" by "the ISP can provide ou= tgoing IPv4 service". >>> >> >> In section 1 we state: >> >> "The 464XLAT IPv4 service is limited to application >> =A0 that function in a client server model and is not fit for IPv4 peer- >> =A0 to-peer communication or inbound IPv4 connections." > > Right, but repeating one word where it is clarifying shouldn't be a probl= em (IMHO). > > > RD > > > >> >> >> CB >> >>> >>> Regards, >>> RD >>> >>> >>>> >>>> Changes are: >>>> >>>> - Section 7.5. IPv6 Prefix Handling >>>> =A0- Clarified the language. >>>> >>>> - Added new section "7.6. Relationship between CLAT and NAT44" >>>> >>>> Regards, >>>> Masanobu >>>> >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. This draft is a work item of the IPv6 Operations Working Group o= f the IETF. >>>>> >>>>> =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : 464XLAT: Combination of Statef= ul and Stateless Translation >>>>> =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Masataka Mawatari >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Masanobu Kawashima >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cameron Byrne >>>>> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-464xlat-03.txt >>>>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 >>>>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-07 >>>>> >>>>> =A0This document describes an architecture (464XLAT) for providing >>>>> =A0limited IPv4 connectivity across an IPv6-only network by combining >>>>> =A0existing and well-known stateful protocol translation RFC 6146 in = the >>>>> =A0core and stateless protocol translation RFC 6145 at the edge. 464X= LAT >>>>> =A0is a simple and scalable technique to quickly deploy limited IPv4 >>>>> =A0access service to mobile and wireline IPv6-only edge networks with= out >>>>> =A0encapsulation. >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> This Internet-Draft can be retrieved at: >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>>>> >>>>> The IETF datatracker page for this Internet-Draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ >>>>> >>>>> _______________________________________________ >>>>> 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=3D=3D=3D=3D >>>> NEC AccessTechnica, Ltd. >>>> Product Development Department >>>> Masanobu Kawashima >>>> 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=3D=3D=3D=3D >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> > From despres.remi@laposte.net Tue May 8 07:09:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D990321F84C3 for ; Tue, 8 May 2012 07:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-7bHKsH1JOu for ; Tue, 8 May 2012 07:09:31 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C321F852A for ; Tue, 8 May 2012 07:09:29 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6E17C94013F; Tue, 8 May 2012 16:09:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 May 2012 16:09:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E3CE2F2-4565-48D6-A3EA-837538A710DC@laposte.net> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 14:09:33 -0000 Le 2012-05-08 =E0 15:55, Cameron Byrne a =E9crit : > R=E9mi, >=20 > If i may summarize your main points below, you want to eliminate the > possibility of using 2 IPv6 prefix. It is unclear to me, and i don't > want to debate generalities. Please provide specific advantages for > the WG to consider. Only one case is simpler than two cases, with a choice to be made = without being led in the choice to be made. > IPv6 was created with the notion that intefaces will have many IPv6 > prefixs. And, the ONLY scenario that will use more than 1 IPv6 > prefixes is when DHCP-PD is used in the access network, and therefore > the CLAT will receive 1 prefix from the network, such as a /56 or /60 > ... (1 for WAN, 1 for CLAT, n for LAN) ...I see no harm -- and > possible simplification and utility in having a dedicated /64 from the > delegated supernet for translation. >=20 > As a network operator, if i can uniformly deploy so that a certain set > of prefixes are known to be 464XLAT IPv4 reachable it makes my life > easier when troubleshooting. A reserved Interface ID is AFAIK even simpler. > Also, some folks believe that avoiding > NAT44 in the CPE will reduce the complexity. I doubt that any home-gateway vendor will have products that cannot = support NAT44s. > Why do you want to > remove this option? =20 Simplicity. > The NAT4464 option is open in the spec for anyone > who wants to use it. I need to know why you want that to be only > path. Simplicity. RD >=20 > CB >=20 > On Tue, May 8, 2012 at 6:42 AM, R=E9mi Despr=E9s = wrote: >> Cameron, >>=20 >> Please understand that the goal of comments below is to improve your = proposal (which AKAIK not so many people have studied in details). >>=20 >> 2012-05-08 14:35, Cameron Byrne: >>=20 >>> R=E9mi, >>>=20 >>> Thanks for the review >>>=20 >>> On Tue, May 8, 2012 at 3:07 AM, R=E9mi Despr=E9s = wrote: >>>>=20 >>>> Le 2012-05-08 =E0 03:24, Masanobu Kawashima a =E9crit : >>>>=20 >>>>>=20 >>>>> Folks, >>>>>=20 >>>>> We have published draft-ietf-v6ops-464xlat-03. >>>>> Can we move forward to WGLC? >>>>=20 >>>> The new draft has none of the following, discussed on the mailing = list, and IMHO still worth dealing with before WGLC: >>>> (1) NAT44 should be a MUST in all cases where the CE node acts as a = router. >>>> (2) A well-known 464XLAT interface ID should better be used in CLAT = addresses. With it, CLATs never need dedicated prefixes (=3D> only one = case in sections 7.2 and 7.5). >>>> (3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a = substance to "It is also possible to provide single IPv4/IPv6 = translation service, which will be needed in the future case of = IPv6-only servers and peers to be reached from legacy IPv4-only hosts.") >>>>=20 >>>=20 >>> I believe the discussion lead to these outcomes: >>>=20 >>> 1. NAT44 does not add any utility in case where there can be a >>> dedicated transition prefix. We took Ole's suggestion for resolving >>> this matter by including both methods and leave it to implementation >>> based on the implementer's circumstances. If the implementer chooses >>> to do NAT44 in all cases, so be it. But we see no harm in = providing >>> choice here. >>=20 >>> It does not force any additional complexity. >>=20 >> It permits the CLAT to always have only one IPv6 address. >> This is in my understanding a non negligible simplification, not = compensated by any loss of useful function. >>=20 >>=20 >>> 2. The OUI idea was clever, but as you pointed out earlier today on >>> the original thread, it did not gain much steam beyond the initial >>> conversation. >>=20 >> The reaction I saw was favorable, with an intent to validate it, but = no more comment after that. >>=20 >> Besides, a reference to RFC6052 for both the CLAT and the CLAT = addresses, CLAT translators need to work with TWO IPv6 prefixes instead = of just one (that of the CLAT and that of the PLAT). This is a = requirement that AFAIK exists in no existing RFC (=3D> the solution is = more than a BCP). >>=20 >>=20 >>> Using a dedicated prefix is not a bad thing, IPv6 >>> addresses are plentiful. While reserving the OUI seems simple = enough, >>> i am concerned about the added confusion this somewhat = unconventional >>> method will create. >>=20 >> Getting simplicity by using an available mechanism IMHO the right way = to go. >> Reserving an interface IDs is not "unconventional" since RFC5342 = section 2.2.2 and http://www.iana.org/assignments/ethernet-numbers have = provisions for that. (Which value to choose remains open AFAIAC, but = provided one is reserved.) >>=20 >>=20 >>> 3. A reference to BIH does not seem required. >>=20 >>> I am not opposed to >>> it, >>=20 >> Good. >> (*) Without it, can you clarify the meaning of "It is also possible = to provide single IPv4/IPv6 translation service, which will be needed in = the future case of IPv6-only servers and peers to be reached from legacy = IPv4-only hosts."? >>=20 >>> but this document is not required to enumerate all possible >>> solutions, it is to describe one solution summarized in the >>> introduction. We also do not include references to DS-lite .... >>=20 >> Sure, but see (*) above. >>=20 >>=20 >>>> Besides, some detail suggestions: >>>> In Figures: >>>> - Below PLAT, add NAT64 to clarify that PLAT is no more than a new = name for a NAT64 of RFC6146. >>>> In 4.1: >>>=20 >>> PLAT is clearly defined in section 3. >>=20 >> Yes, ... as a ordinary NAT64 (very minor point anyway). >>=20 >>>=20 >>>> - Replace "one IPv4 address can support millions of simultaneous = translations" by "one IPv4 address can support more simultaneous = translations than with stateless solutions". >>>=20 >>> The focus of this sentence is not to compare with stateless = solution, >>> the focus of this sentence is on "port overloading". Most people >>> think of stateful NAT44 allows for 64,000 translation sessions, but = we >>> explicitly state that port overloading allows for millions of = sessions >>> per 1 IPv4 address. I believe this is a meaningful point to make in >>> an IPv4 constrained world. >>>=20 >>>> - Replace "stateless address sharing... are simply not = IPv4-efficient enough to solve...", by "stateless address sharing... are = not IPv4-efficient enough to solve in all cases...". >>>> In 4.3: >>>=20 >>> OK >>>=20 >>>> - Replace "especially cost-effective in wireless 3GPP...", by = "especially cost-effective in Pre-Release 9 wireless 3GPP...". >>>> In 6.1: >>>=20 >>> OK >>>=20 >>>> - Replace "the ISP can provide IPv4 service" by "the ISP can = provide outgoing IPv4 service". >>>>=20 >>>=20 >>> In section 1 we state: >>>=20 >>> "The 464XLAT IPv4 service is limited to application >>> that function in a client server model and is not fit for IPv4 = peer- >>> to-peer communication or inbound IPv4 connections." >>=20 >> Right, but repeating one word where it is clarifying shouldn't be a = problem (IMHO). >>=20 >>=20 >> RD >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> CB >>>=20 >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>>=20 >>>>> Changes are: >>>>>=20 >>>>> - Section 7.5. IPv6 Prefix Handling >>>>> - Clarified the language. >>>>>=20 >>>>> - Added new section "7.6. Relationship between CLAT and NAT44" >>>>>=20 >>>>> Regards, >>>>> Masanobu >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Title : 464XLAT: Combination of Stateful and = Stateless Translation >>>>>> Author(s) : Masataka Mawatari >>>>>> Masanobu Kawashima >>>>>> Cameron Byrne >>>>>> Filename : draft-ietf-v6ops-464xlat-03.txt >>>>>> Pages : 15 >>>>>> Date : 2012-05-07 >>>>>>=20 >>>>>> 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 mobile and wireline IPv6-only edge networks = without >>>>>> encapsulation. >>>>>>=20 >>>>>>=20 >>>>>> A URL for this Internet-Draft is: >>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> This Internet-Draft can be retrieved at: >>>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>>>>>=20 >>>>>> The IETF datatracker page for this Internet-Draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>=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 >>>>> NEC AccessTechnica, Ltd. >>>>> Product Development Department >>>>> Masanobu Kawashima >>>>> 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=3D=3D=3D=3D >>>>>=20 >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>=20 From randy@psg.com Tue May 8 07:11:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C3A21F85E3 for ; Tue, 8 May 2012 07:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vhnge-0xcMM for ; Tue, 8 May 2012 07:11:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5242521F852A for ; Tue, 8 May 2012 07:11:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SRl8A-000EYB-5j; Tue, 08 May 2012 14:11:10 +0000 Date: Tue, 08 May 2012 07:11:09 -0700 Message-ID: From: Randy Bush To: Jean-Francois.TremblayING@videotron.com 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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 14:11:11 -0000 > We seem to disagree on : > - the committment of D-Link they are a vendor. operators judge their committment when there is shipping product. :) > - the consensus on the list. Many participants on this list > asked for the consensus to be verified for the new "version 3" > text, the version in which multi-homing suddenly became a MUST. as the sun sets on my 6rd deployment and the beautiful moon of native ipv6 rises, it seems prudent to allow a time when both are in the sky. especially if i have a mix of cpe capabilities. do we have a simpler way of viewing this than multi-homing? randy From cb.list6@gmail.com Tue May 8 07:13:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE3121F863D for ; Tue, 8 May 2012 07:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq5NNbR+liAt for ; Tue, 8 May 2012 07:13:36 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76A8D21F8616 for ; Tue, 8 May 2012 07:13:36 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8191107pbc.31 for ; Tue, 08 May 2012 07:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8TorgAuZR2paChrmccjw4b+m7sAMoQv9rfHz95j1o10=; b=b3G3YME8rGWkxXqLymhS2Ua/TzxXxsNe59EBoqGIV30oOzrnDAWilpzus/EB3oade5 +tS5UiykeEvhCGFT3WHljbKjXmRHnF2VC9P2Ybn2SoLxV+KYdZYocyQyO6wJEiIDTYpx fRbbqRVH13G2H4gFFORHn8Gr0NA/wgUAfXvSKMSqZxIWxvrF3Qepm/jW7cwc94JU+Xqr QJHnHkj4XS4KFNgH0WYRHK3XdeYGIMzw4zlGEIdDQs4OFN35wIseSUVJrdZvPLk7pBrY IB/pxQbr5I7zwMC0NYvbNP/7k2AydRYLqFPXbqs1z1ENvmoiD2lBGtKFvC1r2JrhPE2d pa3w== MIME-Version: 1.0 Received: by 10.68.223.234 with SMTP id qx10mr57638305pbc.154.1336486416253; Tue, 08 May 2012 07:13:36 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Tue, 8 May 2012 07:13:36 -0700 (PDT) In-Reply-To: <6E3CE2F2-4565-48D6-A3EA-837538A710DC@laposte.net> References: <6E3CE2F2-4565-48D6-A3EA-837538A710DC@laposte.net> Date: Tue, 8 May 2012 07:13:36 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 14:13:37 -0000 On Tue, May 8, 2012 at 7:09 AM, R=E9mi Despr=E9s = wrote: > > Le 2012-05-08 =E0 15:55, Cameron Byrne a =E9crit : > >> R=E9mi, >> >> If i may summarize your main points below, you want to eliminate the >> possibility of using 2 IPv6 prefix. =A0It is unclear to me, and i don't >> want to debate generalities. =A0Please provide specific advantages for >> the WG to consider. > > Only one case is simpler than two cases, with a choice to be made without= being led in the choice to be made. > >> IPv6 was created with the notion that intefaces will have many IPv6 >> prefixs. =A0And, the ONLY scenario that will use more than 1 IPv6 >> prefixes is when DHCP-PD is used in the access network, and therefore >> the CLAT will receive 1 prefix from the network, such as a /56 or /60 >> ... (1 for WAN, 1 for CLAT, n for LAN) ...I see no harm -- and >> possible simplification and utility in having a dedicated /64 from the >> delegated supernet for translation. >> >> As a network operator, if i can uniformly deploy so that a certain set >> of prefixes are known to be 464XLAT IPv4 reachable it makes my life >> easier when troubleshooting. > > A reserved Interface ID is AFAIK even simpler. > >> =A0Also, some folks believe that avoiding >> NAT44 in the CPE will reduce the complexity. > > I doubt that any home-gateway vendor will have products that cannot suppo= rt NAT44s. > > >> =A0Why do you want to >> remove this option? > > Simplicity. > >> The NAT4464 option is open in the spec for anyone >> who wants to use it. I need to know why you want that to =A0be only >> path. > > Simplicity. > > RD > ACK. Does anyone else care to comment on this topic? The authors are eager to settle outstanding issues. This appears to be important to our respected colleague R=E9mi. Is this matter (support or oppose) important to anyone else? CB > >> >> CB >> >> On Tue, May 8, 2012 at 6:42 AM, R=E9mi Despr=E9s wrote: >>> Cameron, >>> >>> Please understand that the goal of comments below is to improve your pr= oposal (which AKAIK not so many people have studied in details). >>> >>> 2012-05-08 14:35, Cameron Byrne: >>> >>>> R=E9mi, >>>> >>>> Thanks for the review >>>> >>>> On Tue, May 8, 2012 at 3:07 AM, R=E9mi Despr=E9s wrote: >>>>> >>>>> Le 2012-05-08 =E0 03:24, Masanobu Kawashima a =E9crit : >>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> We have published draft-ietf-v6ops-464xlat-03. >>>>>> Can we move forward to WGLC? >>>>> >>>>> The new draft has none of the following, discussed on the mailing lis= t, and IMHO still worth dealing with before WGLC: >>>>> (1) NAT44 should be a MUST in all cases where the CE node acts as a r= outer. >>>>> (2) A well-known 464XLAT interface ID should better be used in CLAT a= ddresses. With it, CLATs never need dedicated prefixes (=3D> only one case = in sections 7.2 and 7.5). >>>>> (3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a s= ubstance to "It is also possible to provide single IPv4/IPv6 translation se= rvice, which will be needed in the future case of IPv6-only servers and pee= rs to be reached from legacy IPv4-only hosts.") >>>>> >>>> >>>> I believe the discussion lead to these outcomes: >>>> >>>> 1. =A0NAT44 does not add any utility in case where there can be a >>>> dedicated transition prefix. =A0We took Ole's suggestion for resolving >>>> this matter by including both methods and leave it to implementation >>>> based on the implementer's circumstances. If the implementer chooses >>>> to do NAT44 in all cases, so be it. =A0 But we see no harm in providin= g >>>> choice here. >>> >>>> It does not force any additional complexity. >>> >>> It permits the CLAT to always have only one IPv6 address. >>> This is in my understanding a non negligible simplification, not compen= sated by any loss of useful function. >>> >>> >>>> 2. =A0The OUI idea was clever, but as you pointed out earlier today on >>>> the original thread, it did not gain much steam beyond the initial >>>> conversation. >>> >>> The reaction I saw was favorable, with an intent to validate it, but no= more comment after that. >>> >>> Besides, a reference to RFC6052 for both the CLAT and the CLAT addresse= s, CLAT translators need to work with TWO IPv6 prefixes instead of just one= (that of the CLAT and that of the PLAT). This is a requirement that AFAIK = exists in no existing RFC (=3D> the solution is more than a BCP). >>> >>> >>>> Using a dedicated prefix is not a bad thing, IPv6 >>>> addresses are plentiful. =A0While reserving the OUI seems simple enoug= h, >>>> i am concerned about the added confusion this somewhat unconventional >>>> method will create. >>> >>> Getting simplicity by using an available mechanism IMHO the right way t= o go. >>> Reserving an interface IDs is not "unconventional" since RFC5342 sectio= n 2.2.2 and http://www.iana.org/assignments/ethernet-numbers have provision= s for that. (Which value to choose remains open AFAIAC, but provided one is= reserved.) >>> >>> >>>> 3. =A0A reference to BIH does not seem required. >>> >>>> =A0I am not opposed to >>>> it, >>> >>> Good. >>> (*) Without it, can you clarify the meaning of "It is also possible to = provide single IPv4/IPv6 translation service, which will be needed in the f= uture case of IPv6-only servers and peers to be reached from legacy IPv4-on= ly hosts."? >>> >>>> but this document is not required to enumerate all possible >>>> solutions, it is to describe one solution summarized in the >>>> introduction. =A0We also do not include references to DS-lite .... >>> >>> Sure, but see (*) above. >>> >>> >>>>> Besides, some detail suggestions: >>>>> In Figures: >>>>> - Below PLAT, add NAT64 to clarify that PLAT is no more than a new na= me for a NAT64 of RFC6146. >>>>> In 4.1: >>>> >>>> PLAT is clearly defined in section 3. >>> >>> Yes, ... as a ordinary NAT64 (very minor point anyway). >>> >>>> >>>>> - Replace "one IPv4 address can support millions of simultaneous tran= slations" by "one IPv4 address can support more simultaneous translations t= han with stateless solutions". >>>> >>>> The focus of this sentence is not to compare with stateless solution, >>>> the focus of this sentence is on "port overloading". =A0Most people >>>> think of stateful NAT44 allows for 64,000 translation sessions, but we >>>> explicitly state that port overloading allows for millions of sessions >>>> per 1 IPv4 address. =A0I believe this is a meaningful point to make in >>>> an IPv4 constrained world. >>>> >>>>> - Replace "stateless address sharing... are simply not IPv4-efficient= enough to solve...", by "stateless address sharing... are not IPv4-efficie= nt enough to solve in all cases...". >>>>> In 4.3: >>>> >>>> OK >>>> >>>>> - Replace "especially cost-effective in wireless 3GPP...", by "especi= ally cost-effective in Pre-Release 9 wireless 3GPP...". >>>>> In 6.1: >>>> >>>> OK >>>> >>>>> - Replace "the ISP can provide IPv4 service" by "the ISP can provide = outgoing IPv4 service". >>>>> >>>> >>>> In section 1 we state: >>>> >>>> "The 464XLAT IPv4 service is limited to application >>>> =A0 that function in a client server model and is not fit for IPv4 pee= r- >>>> =A0 to-peer communication or inbound IPv4 connections." >>> >>> Right, but repeating one word where it is clarifying shouldn't be a pro= blem (IMHO). >>> >>> >>> RD >>> >>> >>> >>>> >>>> >>>> CB >>>> >>>>> >>>>> Regards, >>>>> RD >>>>> >>>>> >>>>>> >>>>>> Changes are: >>>>>> >>>>>> - Section 7.5. IPv6 Prefix Handling >>>>>> =A0- Clarified the language. >>>>>> >>>>>> - Added new section "7.6. Relationship between CLAT and NAT44" >>>>>> >>>>>> Regards, >>>>>> Masanobu >>>>>> >>>>>> >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : 464XLAT: Combination of Stat= eful and Stateless Translation >>>>>>> =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Masataka Mawatari >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Masanobu Kawashima >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cameron Byrne >>>>>>> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-464xlat-03.tx= t >>>>>>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 >>>>>>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-07 >>>>>>> >>>>>>> =A0This document describes an architecture (464XLAT) for providing >>>>>>> =A0limited IPv4 connectivity across an IPv6-only network by combini= ng >>>>>>> =A0existing and well-known stateful protocol translation RFC 6146 i= n the >>>>>>> =A0core and stateless protocol translation RFC 6145 at the edge. 46= 4XLAT >>>>>>> =A0is a simple and scalable technique to quickly deploy limited IPv= 4 >>>>>>> =A0access service to mobile and wireline IPv6-only edge networks wi= thout >>>>>>> =A0encapsulation. >>>>>>> >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> This Internet-Draft can be retrieved at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt >>>>>>> >>>>>>> The IETF datatracker page for this Internet-Draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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=3D=3D=3D=3D >>>>>> NEC AccessTechnica, Ltd. >>>>>> Product Development Department >>>>>> Masanobu Kawashima >>>>>> 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=3D=3D=3D=3D >>>>>> >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>> > From despres.remi@laposte.net Tue May 8 07:18:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ECD21F8473 for ; Tue, 8 May 2012 07:18:10 -0700 (PDT) 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=-0.218, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4061oNI0eif for ; Tue, 8 May 2012 07:18:10 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9221F8472 for ; Tue, 8 May 2012 07:18:07 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 95FDD94007F; Tue, 8 May 2012 16:17:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 May 2012 16:17:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: IETF v6ops list Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 14:18:10 -0000 Le 2012-05-08 =E0 16:11, Randy Bush a =E9crit : >> We seem to disagree on :=20 >> - the committment of D-Link=20 >=20 > they are a vendor. operators judge their committment when there > is shipping product. :) >=20 >> - the consensus on the list. Many participants on this list=20 >> asked for the consensus to be verified for the new "version 3" >> text, the version in which multi-homing suddenly became a MUST.=20 >=20 > as the sun sets on my 6rd deployment and the beautiful moon of native > ipv6 rises, it seems prudent to allow a time when both are in the sky. > especially if i have a mix of cpe capabilities. do we have a simpler > way of viewing this than multi-homing? If native IPv6 prefixes that are delegated are the same as those of 6rd, = yes. If new IPv6 prefixes are preferred, it can be done in a second phase, = when 6rd has been disabled, using the lifetime of IPv6 prefixes. RD =20 >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dan-v6ops@drown.org Tue May 8 07:38:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AA321F85B5 for ; Tue, 8 May 2012 07:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXHDSlnUlZFm for ; Tue, 8 May 2012 07:38:53 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 57F2821F8542 for ; Tue, 8 May 2012 07:38:53 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 9D555C0B8; Tue, 8 May 2012 10:38:52 -0400 (EDT) Received: from 2001:470:b88f:c8f6:224:1dff:fe16:eb3b ([2001:470:b88f:c8f6:224:1dff:fe16:eb3b]) by mail.drown.org (Horde Framework) with HTTP; Tue, 08 May 2012 09:38:52 -0500 Message-ID: <20120508093852.10204cs443od690k@mail.drown.org> Date: Tue, 08 May 2012 09:38:52 -0500 From: Dan Drown To: =?utf-8?b?UsOpbWkg?= =?utf-8?b?RGVzcHLDqXM=?= References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <20120421192046.99723kgkv9zjcq9w@mail.drown.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 08 May 2012 14:38:53 -0000 Quoting R=C3=A9mi Despr=C3=A9s : >> This sounds good to me. Using IANA's EUI-64 ID would avoid =20 >> conflicts with possible interface IDs on v6 tethering (as long as a =20 >> unique EUI-64 address is assigned to clat). Since this is just a =20 >> config file change, I'll go ahead and use it. > > Any feedback? I changed my implementation to use a host id in IANA's EUI-64 range by =20 default. From cb.list6@gmail.com Tue May 8 07:47:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F2321F864B for ; Tue, 8 May 2012 07:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.033 X-Spam-Level: X-Spam-Status: No, score=-3.033 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq6Kpy0SIffE for ; Tue, 8 May 2012 07:47:04 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D98C21F8648 for ; Tue, 8 May 2012 07:47:04 -0700 (PDT) Received: by dacx6 with SMTP id x6so8080406dac.31 for ; Tue, 08 May 2012 07:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MwsVbNDrGgFOGeDtDF2shQ0bmEenqWqIy1S09XQM9uw=; b=h9iPhb6+0qL/tnuaknqry1S5xJHGCZ2k7hp5nimO7Bu1XKzjTZ6BXWLOaw5m+byviY DxeA/WDK52KXqfZQa90BVN4rl3vV6OHZJniRt0FPgNK59PS2gLNcZCBrDfhaakDYIu8Q 2La4U4E7J16WXhLjqO5i0+gM2IQIxwOGy4ILehhJguNY4aK6079T3CeeGZHWmf0Qs8J3 wTIouvyNe4cTVaorTqIgV7KwfaAFjXmZ+IajTDw6EZbVwmlZUOuL0ak5PU2ZRVPdgXhK IyiMYx8oiRiusLEZRSi46Jrz2tK5mlE2b4eoSfZqKsgg5/eqcjGByCoXRaqo6m4uH3LA Yecw== MIME-Version: 1.0 Received: by 10.68.240.5 with SMTP id vw5mr356069pbc.82.1336488424061; Tue, 08 May 2012 07:47:04 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Tue, 8 May 2012 07:47:03 -0700 (PDT) In-Reply-To: <20120508093852.10204cs443od690k@mail.drown.org> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <20120421192046.99723kgkv9zjcq9w@mail.drown.org> <20120508093852.10204cs443od690k@mail.drown.org> Date: Tue, 8 May 2012 07:47:03 -0700 Message-ID: From: Cameron Byrne To: Dan Drown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 08 May 2012 14:47:05 -0000 On Tue, May 8, 2012 at 7:38 AM, Dan Drown wrote: > Quoting R=E9mi Despr=E9s : >>> >>> This sounds good to me. =A0Using IANA's EUI-64 ID would avoid conflicts >>> with possible interface IDs on v6 tethering (as long as a unique EUI-64 >>> address is assigned to clat). =A0Since this is just a config file chang= e, I'll >>> go ahead and use it. >> >> >> Any feedback? > > > I changed my implementation to use a host id in IANA's EUI-64 range by > default. > Can your or R=E9mi provide required draft text that would need to be updated to incorporate this change? CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Tue May 8 08:00:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017E211E8073 for ; Tue, 8 May 2012 08:00:53 -0700 (PDT) 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=-0.209, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIKn-8usgvOq for ; Tue, 8 May 2012 08:00:52 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A40021F85CF for ; Tue, 8 May 2012 08:00:50 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id D9C1194017B; Tue, 8 May 2012 17:00:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 May 2012 17:00:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EF828FF-0151-4D03-92FF-DBB90BAF8470@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <20120421192046.99723kgkv9zjcq9w@mail.drown.org> <20120508093852.10204cs443od690k@mail.drown.org> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 08 May 2012 15:00:53 -0000 Le 2012-05-08 =E0 16:47, Cameron Byrne a =E9crit : > On Tue, May 8, 2012 at 7:38 AM, Dan Drown wrote: >> Quoting R=E9mi Despr=E9s : >>>>=20 >>>> This sounds good to me. Using IANA's EUI-64 ID would avoid = conflicts >>>> with possible interface IDs on v6 tethering (as long as a unique = EUI-64 >>>> address is assigned to clat). Since this is just a config file = change, I'll >>>> go ahead and use it. >>>=20 >>>=20 >>> Any feedback? >>=20 >>=20 >> I changed my implementation to use a host id in IANA's EUI-64 range = by >> default. >>=20 >=20 > Can your or R=E9mi provide required draft text that would need to be > updated to incorporate this change? I can propose a number of amendments, in line with my comments, but it = should take a few days (now under some pressure for the Softwire version = of the 4rd draft). RD =20 >=20 > CB >=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Tue May 8 09:21:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087E521F8562 for ; Tue, 8 May 2012 09:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqmjnCVnmnGW for ; Tue, 8 May 2012 09:21:06 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5721F855F for ; Tue, 8 May 2012 09:21:05 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4360864wgb.13 for ; Tue, 08 May 2012 09:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZCFqL5Nbl4R/ItXA0kE0iaxjKdiC4m+CkujiYpKQF4Y=; b=VVuEdKiZrOeRCKbgjqrc5mxjaFyfSgE2OBg+M+cxA8vgE2/XnLrRT9CDR7hSFaYnSt afX1xOnzR8uTlKDRMHz1IWpdKhh7Zce8JRdMlwRQL2p956KEDLNbSxOAk3SxmXcP7/1N MXqLxqpSCa9hj2jkBhJxKWKUK1ehPx5ADPD8FjLoE1WILAPWiarakCHod3psgcd3U32j K/WYn7z9AXAQmW4uMxrIvPmt5KZQvQ3F4EHw/UY0SbL4PJV/0x9w2fGxUT8hEGkcnZVV rcrXDddNOqfbrCKQD274ttQxXMfXrfCJbnY8xt8Kbfuo9J5ChRkgxcCfmTpaAlp7yo+A GN6Q== Received: by 10.180.104.137 with SMTP id ge9mr18025711wib.20.1336494064900; Tue, 08 May 2012 09:21:04 -0700 (PDT) Received: from dhcp-10-61-100-46.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id k6sm29917680wiy.7.2012.05.08.09.21.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 09:21:04 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 8 May 2012 18:21:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09163042-6F3F-40BB-9C96-7CEDD0A5FF9E@employees.org> References: <6E3CE2F2-4565-48D6-A3EA-837538A710DC@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: v6ops WG Subject: Re: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 16:21:07 -0000 > Does anyone else care to comment on this topic? The authors are eager > to settle outstanding issues. This appears to be important to our > respected colleague R=E9mi. >=20 > Is this matter (support or oppose) important to anyone else? I support the current text. (I don't see why removing the NAT44 would be simpler, nor do I see why = you should create more restrictions on implementation/deployment than = you have to. cheers, Ole= From despres.remi@laposte.net Tue May 8 09:29:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF13A21F847B for ; Tue, 8 May 2012 09:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsSWfMy47Unn for ; Tue, 8 May 2012 09:29:53 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF85D21F8476 for ; Tue, 8 May 2012 09:29:51 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 63A1E94015B; Tue, 8 May 2012 18:29:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <09163042-6F3F-40BB-9C96-7CEDD0A5FF9E@employees.org> Date: Tue, 8 May 2012 18:29:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E3CE2F2-4565-48D6-A3EA-837538A710DC@laposte.net> <09163042-6F3F-40BB-9C96-7CEDD0A5FF9E@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 16:29:54 -0000 Le 2012-05-08 =E0 18:21, Ole Tr=F8an a =E9crit : >> Does anyone else care to comment on this topic? The authors are = eager >> to settle outstanding issues. This appears to be important to our >> respected colleague R=E9mi. >>=20 >> Is this matter (support or oppose) important to anyone else? >=20 > I support the current text. >=20 > (I don't see why removing the NAT44 would be simpler, The proposal is not for "removing the NAT44". It is to make the NAT44 a = MUST when the CNAT node acts as an IPv4 a router. Reading what is proposed before rejecting it would be appreciated. RD > nor do I see why you should create more restrictions on = implementation/deployment than you have to. >=20 > cheers, > Ole From ichiroumakino@gmail.com Tue May 8 10:00:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C8221F85E7 for ; Tue, 8 May 2012 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOHzFJJBly9m for ; Tue, 8 May 2012 10:00:39 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id DB9A321F85C5 for ; Tue, 8 May 2012 10:00:38 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so840775wgb.1 for ; Tue, 08 May 2012 10:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vNccBc48TpsfCGpQ7B36QNQ38hTeXD7rXRdJ2VxjEa8=; b=YTpV9WHwJ99wJzpk5KiKRGPAV5xv3Ghby1f4AVSkrYfHgfokOMv+2CylghjLlsl1G3 q1b8F9I75bABMfrBqpbp4A2/K2uQikxJTTZABAEY1pmZftME7NxpBoGWyE1V5LySu6WP 5+qdAqiqGfnisHty8nexiVWGPMmlmO5vWIy8GVbuTUK/fDUEDt6z+/elkyHTu+0S6RP6 4o/oLNdpR7hkMVHqysAYh2YpdBSQcV8If6Bge0/Pz4OzIDvoG3wI4ReSqo3Chaj++6Av bMhUpyRFi8m+78ZaM+Be0+DEpE3EgtbvYw0m1K2Sj3gKJcS54OxxmTrAEYRXKfG3grL9 TXsQ== Received: by 10.216.50.13 with SMTP id y13mr12338186web.116.1336496438001; Tue, 08 May 2012 10:00:38 -0700 (PDT) Received: from dhcp-10-61-100-46.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fm1sm29681265wib.10.2012.05.08.10.00.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 10:00:37 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 8 May 2012 19:00:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <335C5D38-19A0-4F9D-80D5-7DF4FBFC9E7C@employees.org> References: <6E3CE2F2-4565-48D6-A3EA-837538A710DC@laposte.net> <09163042-6F3F-40BB-9C96-7CEDD0A5FF9E@employees.org> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: v6ops WG Subject: Re: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-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, 08 May 2012 17:00:40 -0000 >>> Does anyone else care to comment on this topic? The authors are = eager >>> to settle outstanding issues. This appears to be important to our >>> respected colleague R=E9mi. >>>=20 >>> Is this matter (support or oppose) important to anyone else? >>=20 >> I support the current text. >>=20 >> (I don't see why removing the NAT44 would be simpler, >=20 > The proposal is not for "removing the NAT44". It is to make the NAT44 = a MUST when the CNAT node acts as an IPv4 a router. this would still be an implementation choice. why prohibit an = implementation to do better, if it has been deployed with enough address = space? cheers, Ole From C.Donley@cablelabs.com Tue May 8 14:18:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2A611E8072 for ; Tue, 8 May 2012 14:18:00 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPwq-3JSGs7N for ; Tue, 8 May 2012 14:17:59 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9519E800B for ; Tue, 8 May 2012 14:17:59 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q48LHtIQ019675; Tue, 8 May 2012 15:17:55 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 08 May 2012 15:17:55 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 8 May 2012 15:17:55 -0600 From: Chris Donley To: "STARK, BARBARA H" , =?iso-8859-1?Q?Ole_Tr=F8an?= , Hans Liu Date: Tue, 8 May 2012 15:17:54 -0600 Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: Ac0tYAhy58A+Gd1nRu6kg6mUx09v9Q== Message-ID: In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110C1604@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 21:18:00 -0000 Our testing shows that NAT444 offers a better user experience than DS-Lite (due in part to MTU issues). Customer hat on - I would strongly prefer native IPv4 to DS-Lite, even if that native v4 address were behind a CGN. Chris On 5/8/12 7:16 AM, "STARK, BARBARA H" wrote: >> do we all agree that for IPv4, a CPE should prefer a DS-lite connection >>over a >> native one? > >Is the native one giving me a CGN NATted IPv4 address, or a public IPv4 >address? I think I would prefer public IPv4 over DS-Lite over CGN. >Barbara >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From bs7652@att.com Tue May 8 14:44:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87C411E8074 for ; Tue, 8 May 2012 14:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.774 X-Spam-Level: X-Spam-Status: No, score=-103.774 tagged_above=-999 required=5 tests=[AWL=-1.475, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01r51rUERiSU for ; Tue, 8 May 2012 14:44:17 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 32C2811E8072 for ; Tue, 8 May 2012 14:44:17 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 1b399af4.2aaae382b940.2796451.00-533.7693249.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 08 May 2012 21:44:17 +0000 (UTC) X-MXL-Hash: 4fa993b147c75467-787458d73124ab0e1298608616880174a1abfcf5 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 4a399af4.0.2796339.00-475.7692919.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 08 May 2012 21:44:04 +0000 (UTC) X-MXL-Hash: 4fa993a44ca05707-355a271237497b2c0b4f69f450fed3759889ad4d 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 q48Li0m7027028; Tue, 8 May 2012 17:44:03 -0400 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 q48LhsKO026885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 17:43:58 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint03.pst.cso.att.com (RSA Interceptor); Tue, 8 May 2012 17:21:31 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.81]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.01.0355.002; Tue, 8 May 2012 17:21:30 -0400 From: "STARK, BARBARA H" To: Chris Donley , =?iso-8859-1?Q?Ole_Tr=F8an?= , Hans Liu Thread-Topic: [v6ops] 6rd sunsetting requirements (version 3) Thread-Index: AQHNKPSFHaTi59li002JhDEAyFznTpa36hwAgAAeRwCAAAKugIAAVn0AgAAG8ACAAASigP//1LVggABKDwCAAGLYAIAA8kyAgAADSwCAAAOtAIAAIUOAgAQVQACAADz5AIAAGGYAgAByhwCAAOqQAIAAEFeAgAANGQCAAAM5AP//9ZnwgADJ+gD//72asA== Date: Tue, 8 May 2012 21:21:30 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110C1AA1@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6110C1604@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.68.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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=1.0 c=1 a=3_JjInvpirMA:10 a=KJxBHbnaG1YA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=a_s8knYsrEO9WaOJFUkA:9 a=wPNLvfGTeEIA:10 a] X-AnalysisOut: [=ER4CAoNlv8JWzAbl:21 a=Xp7uvkQMwrEDQb8u:21] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 May 2012 21:44:17 -0000 Interesting. I stand corrected. Thx. Barbara > Our testing shows that NAT444 offers a better user experience than DS-Lit= e > (due in part to MTU issues). Customer hat on - I would strongly prefer n= ative > IPv4 to DS-Lite, even if that native v4 address were behind a CGN. From fibrib@gmail.com Tue May 8 18:42:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6721F844A for ; Tue, 8 May 2012 18:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.083 X-Spam-Level: X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP9kbcftsIBt for ; Tue, 8 May 2012 18:42:31 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20AAE21F8441 for ; Tue, 8 May 2012 18:42:28 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2430617qcs.31 for ; Tue, 08 May 2012 18:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l1uiGHGgO/dsyXEAOrqkUT8JLRanB98ui3KmVOBtCvs=; b=e+Xli0i8OmMPYFr+/Bugsonoff3PyagpKecW03FDk9/2CHcImiYUtprj7YxOsvkYYd UY+AjgAlZdn0qacFTTyrfyFBkec9915N6tHz/SE9gbQMqJEOOR4UA+UvfhcURExYSbjF 2AllIM5eAW+DMry09vXckkadqOYjVaw108JM4tT513QOvWZ7KgZY6FPzk8s1nk2ZUuA+ ODVkFnanpHf3JbwRpkxAjSD2rb2z0sfvK7U4DQrcLVcJJ8uji5xg76PtI0iiDg4U3an0 jMpsfcrQ0OLbPPhJcwzK3spXs5cjM32jeEL5II3p1rmFOmCB4drbl/ZmQEbxnz4wBUsi 8I7Q== MIME-Version: 1.0 Received: by 10.224.213.72 with SMTP id gv8mr2129112qab.27.1336527747613; Tue, 08 May 2012 18:42:27 -0700 (PDT) Received: by 10.229.238.201 with HTTP; Tue, 8 May 2012 18:42:27 -0700 (PDT) In-Reply-To: <280066FF-BC8C-4AEE-84A2-2A0185BDF8F6@laposte.net> References: <20120508012117.23302.51227.idtracker@ietfa.amsl.com> <20120508102426kawashimam@mail.jp.nec.com> <81D370EB-9D3C-4116-8E49-DD6BF427D676@laposte.net> <280066FF-BC8C-4AEE-84A2-2A0185BDF8F6@laposte.net> Date: Wed, 9 May 2012 10:42:27 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300fb12da1027804bf909d75 Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 09 May 2012 01:42:31 -0000 --20cf300fb12da1027804bf909d75 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, one point of an observer. 2012/5/8 R=E9mi Despr=E9s > > > >> Besides, some detail suggestions: > >> In Figures: > >> - Below PLAT, add NAT64 to clarify that PLAT is no more than a new nam= e > for a NAT64 of RFC6146. > >> In 4.1: > > > > PLAT is clearly defined in section 3. > > Yes, ... as a ordinary NAT64 (very minor point anyway). > > please note rfc6146 is about "stateful NAT64". without the *stateful*, the meaning of *NAT64* is a little fuzzy. so personally i like PLAT rather than NAT64. otherwise, i suggest to say it "stateful NAT64" or "NAT64 of RFC6146", or call it NAT64 but with a statement, saying "throughout this document, the term *NAT64* refers to the stateful NAT64 defined in RFC6146"... but anyway, as you mentioned, it is a very minor point. i suggest we (the community) respect the choice of the authors. - maoke --20cf300fb12da1027804bf909d75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,=A0

one point of an observer.=A0
2012/5/8 R=E9mi Despr=E9s <despres= .remi@laposte.net>


>> Besides, some detail suggestions:
>> In Figures:
>> - Below PLAT, add NAT64 to clarify that PLAT is no more than a new= name for a NAT64 of RFC6146.
>> In 4.1:
>
> PLAT is clearly defined in section 3.

Yes, ... as a ordinary NAT64 (very minor point anyway).


please note rf= c6146 is about "stateful NAT64". without the *stateful*, the mean= ing of *NAT64* is a little fuzzy.=A0

so personally= i like PLAT rather than NAT64. otherwise, i suggest to say it "statef= ul NAT64" or "NAT64 of RFC6146", or call it NAT64 but with a= statement, saying "throughout this document, the term *NAT64* refers = to the stateful NAT64 defined in RFC6146"... but anyway, as you mentio= ned, it is a very minor point. i suggest we (the community) respect the cho= ice of the authors.=A0

- maoke
--20cf300fb12da1027804bf909d75-- From internet-drafts@ietf.org Tue May 8 22:13:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3133721F85B1; Tue, 8 May 2012 22:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqqc2UEs4PeH; Tue, 8 May 2012 22:13:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A963521F84DE; Tue, 8 May 2012 22:13:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120509051342.19242.76997.idtracker@ietfa.amsl.com> Date: Tue, 08 May 2012 22:13:42 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-wireline-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: Wed, 09 May 2012 05:13:43 -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 : Wireline Incremental IPv6 Author(s) : Victor Kuarsingh Lee Howard Filename : draft-ietf-v6ops-wireline-incremental-ipv6-02.txt Pages : 27 Date : 2012-05-08 Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for Wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-i= pv6-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-ip= v6-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ From despres.remi@laposte.net Wed May 9 00:19:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987E221F846F for ; Wed, 9 May 2012 00:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRPc4nd7f+XO for ; Wed, 9 May 2012 00:19:05 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDF221F8472 for ; Wed, 9 May 2012 00:19:03 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id B3F009401B4; Wed, 9 May 2012 09:18:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <335C5D38-19A0-4F9D-80D5-7DF4FBFC9E7C@employees.org> Date: Wed, 9 May 2012 09:18:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A7E0DB5-0F52-471B-8519-82A385B71326@laposte.net> References: <6E3CE2F2-4565-48D6-A3EA-837538A710DC@laposte.net> <09163042-6F3F-40BB-9C96-7CEDD0A5FF9E@employees.org> <335C5D38-19A0-4F9D-80D5-7DF4FBFC9E7C@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-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, 09 May 2012 07:19:05 -0000 Le 2012-05-08 =E0 19:00, Ole Tr=F8an a =E9crit : >>>> Does anyone else care to comment on this topic? The authors are = eager >>>> to settle outstanding issues. This appears to be important to our >>>> respected colleague R=E9mi. >>>>=20 >>>> Is this matter (support or oppose) important to anyone else? >>>=20 >>> I support the current text. >>>=20 >>> (I don't see why removing the NAT44 would be simpler, >>=20 >> The proposal is not for "removing the NAT44". It is to make the NAT44 = a MUST when the CNAT node acts as an IPv4 a router. >=20 > this would still be an implementation choice. > why prohibit an implementation to do better, To avoid additional complexity without operational utility (doesn't do = "better" AFAIK)).=20 > if it has been deployed with enough address space? Which address space? (464XLAT works with NAT64 PLATs, i.e. with no IPv4 address space = assigned to CLAT nodes.) RD >=20 > cheers, > Ole >=20 >=20 From washam.fan@gmail.com Wed May 9 22:51:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FE121F85AF for ; Wed, 9 May 2012 22:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDymctmXUC11 for ; Wed, 9 May 2012 22:51:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA86221F852A for ; Wed, 9 May 2012 22:51:47 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1558768obb.31 for ; Wed, 09 May 2012 22:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VzLrySCkPDzLhU0JpF4KADzXiPePC3IevfbKZLMG5UI=; b=AuXPErVzLIg0cx5YChncNTmyVO84JGEGCjYd3xGQ8jVLBhG57TyLInJqvTmZPDnnKV PlaJjC0AzRZE7g7+CsxqdOE73BgodApnX6ea3J03HAGGbvZQvgYkJjE/yRgK9jStFX3X FNeKmytuqvKZP2etV9jCE39E+TLOLrpnpT2AF5dYkbwZrpRBxjEIYQwNMDex7uRZIKx8 IVdL2110vdnOH3t3Vhx49XaOtB2jQl49QFlrj3t/nk42Ndn+rbEmhFo9ej14fk5pRLsT 9xihxWL0Dues3k9ghTAm0QbLi7nQ+OXix0+r2KTTQLCq1Uy5wQEZsfRm8PMnkel7dVwP dDxA== MIME-Version: 1.0 Received: by 10.60.13.196 with SMTP id j4mr4117387oec.14.1336629107419; Wed, 09 May 2012 22:51:47 -0700 (PDT) Received: by 10.182.110.74 with HTTP; Wed, 9 May 2012 22:51:47 -0700 (PDT) In-Reply-To: <20120417160010kawashimam@mail.jp.nec.com> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> Date: Thu, 10 May 2012 13:51:47 +0800 Message-ID: From: Washam Fan To: Masanobu Kawashima 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-464xlat-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, 10 May 2012 05:51:49 -0000 Hi, In sec 7.4. one sentence says: The CLAT SHOULD set itself as the DNS server via DHCP or other means and proxy DNS queries for IPv4 and IPv6 clients. I just don't get it why proxy IPv6 DNS traffic since there would no translation applied to IPv6 traffic. Would it be correct to remove the words 'and IPv6' of the sentence? in sec 7.7, the below sentence seems redundency to me, since it has been expressed in sec 7.4: The router SHOULD set itself as the DNS server advertised via DHCP or other means to the clients so that it may implement the DNS proxy function to avoid double translation of DNS request. Would it be better get the sentence removed. Thanks, washam 2012/4/17 Masanobu Kawashima : > > Folks, > > We have published draft-ietf-v6ops-464xlat-02. > > Changes are: > > - Changed document category from Informational to BCP > =A0- A normative language(RFC2119) has reinserted. > =A0- We did not see any strong opposition on this list except Remi. > =A0 =A0As Cameron and Lorenzo said, we should not treat as a use case > =A0 =A0for BIH. Remi's some concerns were fixed by this version as below. > =A0 =A0If you have any strong opposition, please indicate it. > > - Section 7.1. IPv6 Address Format > =A0- Replaced all text with this one sentence "IPv6 address format > =A0 =A0in 464XLAT is defined in Section 2.2 of [RFC6052]" > > - Section 7.2. IPv4/IPv6 address translation chart > =A0- Removed all references to /96 > =A0- Added case of "CLAT with NAT44" > > - Section 7.4. DNS Proxy Implementation > =A0- Added a reference to RFC5625 > > - Section 7.5. IPv6 Prefix Handling > =A0- Removed all references to /96 > =A0- Added a reference to RFC3633 > > All comments are welcome. > > Regards, > Masanobu > > >> >>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 th= e IETF. >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : 464XLAT: Combination of Stateful= and Stateless Translation >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Masataka Mawatari >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Masanobu Kawashima >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cameron Byrne >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-464xlat-02.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 15 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-16 >> >> =A0 This document describes an architecture (464XLAT) for providing >> =A0 limited IPv4 connectivity across an IPv6-only network by combining >> =A0 existing and well-known stateful protocol translation RFC 6146 in th= e >> =A0 core and stateless protocol translation RFC 6145 at the edge. 464XLA= T >> =A0 is a simple and scalable technique to quickly deploy limited IPv4 >> =A0 access service to mobile and wireline IPv6-only edge networks withou= t >> =A0 encapsulation. >> >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.txt >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>This Internet-Draft can be retrieved at: >>ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.txt >> >>_______________________________________________ >>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=3D=3D=3D=3D > =A0NEC AccessTechnica, Ltd. > =A0Product Development Department > =A0Masanobu Kawashima > =A0kawashimam@vx.jp.nec.com > =A0http://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=3D=3D=3D=3D > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Thu May 10 09:15:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739C721F86DF for ; Thu, 10 May 2012 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDUmyXn8HnoO for ; Thu, 10 May 2012 09:15:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4662B21F8638 for ; Thu, 10 May 2012 09:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=253784; q=dns/txt; s=iport; t=1336666521; x=1337876121; h=mime-version:subject:date:message-id:from:to; bh=jDCYYKVQ0sgUMuCgn4grhRXMjYbWSP9nuoTTLcsI2Zw=; b=E0NHWRr0LtDkQSMto/nMT6y5//gnqmfDViveky1bBfMFW3McloFBA2tW fgdDTsMhCK6Ps9ISq0dio2Kcg84rwIa+B7Q+Ng2GCTnLoXib4KsDZafdY 4Qq+kkghdhhc8TmgNtHFa4Ky2LGfkhOoBl5lFgc/Zyue9MBCgqF3mkfez Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGAOPoq0+tJV2a/2dsb2JhbABEgkaGF6E6AYl6gQeCFwEEEgEHAQERA0IZASoGEAEHB1cBBBsah2wLmXqBKKAjixKFRmMEiGSOKo1GgWmBN4FQ X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208,217";a="81886385" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 10 May 2012 16:15:20 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4AGFJVD014891 for ; Thu, 10 May 2012 16:15:19 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 11:15:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2EC8.181AB7FB" Date: Thu, 10 May 2012 11:15:18 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A0137F@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: diffs for rfc6204bis next version Thread-Index: Ac0uyBeQSiUkobXWRHaCjyvZalx89w== From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 10 May 2012 16:15:19.0891 (UTC) FILETIME=[1841BA30:01CD2EC8] Subject: [v6ops] diffs for rfc6204bis next version X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 May 2012 16:15:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2EC8.181AB7FB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Before I publish the -09, please see the diffs between the impending -09 and the -08 versions below. Any comments? =20 Thanks, =20 Hemant =20 < draft-ietf-v6ops-6204bis-08.txt =20 draft-ietf-v6ops-6204bis-09.txt > =20 =09 =09 =20 Network Working Group H. Singh Network Working Group H. Singh =20 Internet-Draft W. Beebee Internet-Draft W. Beebee =20 Obsoletes: 6204 (if approved) Cisco Systems, Inc. Obsoletes: 6204 (if approved) Cisco Systems, Inc. =20 Intended status: Informational C. Donley Intended status: Informational C. Donley =20 =20 =09 Expires: October 8, 2012 CableLabs Expires: November 11, 2012 CableLabs =20 =09 B. Stark B. Stark =20 =09 AT&T AT&T =20 O. Troan, Ed. O. Troan, Ed. =20 Cisco Systems, Inc. Cisco Systems, Inc. =20 =20 =09 April 6, 2012 May 10, 2012 =20 =20 Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers =20 =20 =09 draft-ietf-v6ops-6204bis-08 draft-ietf-v6ops-6204bis-09 =20 =20 Abstract Abstract =20 =20 This document specifies requirements for an IPv6 Customer Edge (CE) This document specifies requirements for an IPv6 Customer Edge (CE) =20 router. Specifically, the current version of this document focuses router. Specifically, the current version of this document focuses =20 on the basic provisioning of an IPv6 CE router and the provisioning on the basic provisioning of an IPv6 CE router and the provisioning =20 of IPv6 hosts attached to it. The document also covers IP transition of IPv6 hosts attached to it. The document also covers IP transition =20 technologies. Two transition technologies in RFC 5969's 6rd and RFC technologies. Two transition technologies in RFC 5969's 6rd and RFC =20 6333's DS-Lite are covered in the document. The document obsoletes 6333's DS-Lite are covered in the document. The document obsoletes =20 RFC 6204, if approved. RFC 6204, if approved. =20 =20 =20 skipping to change at page 1, line=20 42 =20 skipping to change at page 1, line=20 42 =20 Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering =20 Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute =20 working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet- =20 Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/. =20 =20 Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months =20 and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any =20 time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference =20 material or to cite them other than as "work in progress." material or to cite them other than as "work in progress." =20 =20 =20 =09 This Internet-Draft will expire on October 8, 2012. This Internet-Draft will expire on November 11, 2012. =20 =20 Copyright Notice Copyright Notice =20 =20 Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the =20 document authors. All rights reserved. document authors. All rights reserved. =20 =20 This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal =20 Provisions Relating to IETF Documents Provisions Relating to IETF Documents =20 (http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of =20 publication of this document. Please review these documents publication of this document. Please review these documents =20 =20 =20 skipping to change at page 2, line=20 33 =20 skipping to change at page 2, line=20 33 =20 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 =20 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7 =20 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11 =20 4.4. Transition Technologies Support . . . . . . . . . . . . . 13 4.4. Transition Technologies Support . . . . . . . . . . . . . 13 =20 4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13 =20 4.4.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 14 4.4.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 14 =20 4.5. Security Considerations . . . . . . . . . . . . . . . . . 15 4.5. Security Considerations . . . . . . . . . . . . . . . . . 15 =20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 =20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 =20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 =20 =20 =09 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 =20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 =20 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 =20 =20 =09 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 19 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 20 =20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 =20 =20 1. Introduction 1. Introduction =20 =20 This document defines basic IPv6 features for a residential or small- This document defines basic IPv6 features for a residential or small- =20 office router, referred to as an IPv6 CE router. Typically, these office router, referred to as an IPv6 CE router. Typically, these =20 routers also support IPv4. routers also support IPv4. =20 =20 Mixed environments of dual-stack hosts and IPv6-only hosts (behind Mixed environments of dual-stack hosts and IPv6-only hosts (behind =20 the CE router) can be more complex if the IPv6-only devices are using the CE router) can be more complex if the IPv6-only devices are using =20 a translator to access IPv4 servers [RFC6144]. Support for such a translator to access IPv4 servers [RFC6144]. Support for such =20 =20 =20 skipping to change at page 9, line=20 33 =20 skipping to change at page 9, line=20 33 =20 =20 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client =20 behavior. behavior. =20 =20 WAA-4: The IPv6 CE router MUST be able to support the following WAA-4: The IPv6 CE router MUST be able to support the following =20 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and =20 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to =20 support the DNS Search List DNSSL option as specified in support the DNS Search List DNSSL option as specified in =20 [RFC3646]. [RFC3646]. =20 =20 =20 =09 WAA-5: The IPv6 CE router SHOULD implement the Simple Network Time WAA-5: The IPv6 CE router SHOULD implement the Network Time =20 Protocol (SNTP) as specified in [RFC2030]. If the CE router Protocol (NTP) as specified in [RFC5905]. If the CE router =20 implements SNTP, it requests the SNTP option [RFC4075] and implements NTP, it requests the NTP Server DHCPv6 option =20 uses the received list of servers as primary time reference, [RFC5908] and uses the received list of servers as primary =20 unless explicitly configured otherwise. time reference, unless explicitly configured otherwise. =20 =20 WAA-6: If the IPv6 CE router receives a Router Advertisement WAA-6: If the IPv6 CE router receives a Router Advertisement =20 message (described in [RFC4861]) with the M flag set to 1, message (described in [RFC4861]) with the M flag set to 1, =20 the IPv6 CE router MUST do DHCPv6 address assignment the IPv6 CE router MUST do DHCPv6 address assignment =20 (request an IA_NA option). (request an IA_NA option). =20 =20 WAA-7: If the IPv6 CE router does not acquire global IPv6 WAA-7: If the IPv6 CE router does not acquire global IPv6 =20 address(es) from either SLAAC or DHCPv6, then it MUST create address(es) from either SLAAC or DHCPv6, then it MUST create =20 global IPv6 address(es) from its delegated prefix(es) and global IPv6 address(es) from its delegated prefix(es) and =20 configure those on one of its internal virtual network configure those on one of its internal virtual network =20 interfaces, unless configured to require a global IPv6 interfaces, unless configured to require a global IPv6 =20 address on the WAN interface. address on the WAN interface. =20 =20 =20 =09 WAA-8: The CE Router MUST support the DHCPv6 SOL_MAX_RT option WAA-8: The CE Router MUST set its DHCPv6 SOL_MAX_RT parameter to =20 [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 3600 by default. When the CE Router receives the DHCPv6 =20 Advertise or Reply message and set its internal SOL_MAX_RT SOL_MAX_RT option [I-D.droms-dhc-dhcpv6-maxsolrt-update] in =20 parameter to the value contained in the SOL_MAX_RT option. a received DHCPv6 Advertise or Reply message it sets its =20 internal SOL_MAX_RT parameter to the value contained in the =20 SOL_MAX_RT option. =20 =20 WAA-9: As a router, the IPv6 CE router MUST follow the weak host WAA-9: As a router, the IPv6 CE router MUST follow the weak host =20 (Weak ES) model [RFC1122]. When originating packets from an (Weak ES) model [RFC1122]. When originating packets from an =20 interface, it will use a source address from another one of interface, it will use a source address from another one of =20 its interfaces if the outgoing interface does not have an its interfaces if the outgoing interface does not have an =20 address of suitable scope. address of suitable scope. =20 =20 WAA-10: The IPv6 CE router SHOULD implement the Information Refresh WAA-10: The IPv6 CE router SHOULD implement the Information Refresh =20 Time option and associated client behavior as specified in Time option and associated client behavior as specified in =20 [RFC4242]. [RFC4242]. =20 =20 =20 skipping to change at page 14, line=20 28 =20 skipping to change at page 14, line=20 28 =20 of IPv4 through IPCP (i.e., over a PPP connection), it MUST of IPv4 through IPCP (i.e., over a PPP connection), it MUST =20 support user-entered configuration of 6rd. support user-entered configuration of 6rd. =20 =20 6RD-3: If the CE router supports configuration mechanisms other than 6RD-3: If the CE router supports configuration mechanisms other than =20 the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE =20 router MUST support 6rd in "hub and spoke" mode. 6rd in "hub router MUST support 6rd in "hub and spoke" mode. 6rd in "hub =20 and spoke" requires all IPv6 traffic to go to the 6rd Border and spoke" requires all IPv6 traffic to go to the 6rd Border =20 Relay. In effect, this requirement removes the "direct Relay. In effect, this requirement removes the "direct =20 connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. =20 =20 =20 =09 6RD-4: Per [RFC3704], Section 4.3, the CE router MUST send traffic 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to =20 using a prefix learned via 6rd over the 6rd tunnel. be active alone as well as simultaneously in order to support =20 coexistence of the two technologies during an incremental =20 migration period such as a migration from 6rd to native IPv6. =20 =20 =20 =09 6RD-5: The IPv6 CE router MUST support two operational modes: 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be =20 different prefixes on 6rd and native interfaces or identical directed such that its source IP address is derived from the =20 prefixes on 6rd and native interfaces. delegated prefix associated with the upstream network the WAN =20 interface is connected to [Section 4.3 [RFC3704]]. =20 =20 =20 =09 6RD-6: By default, the IPv6 CE router MUST prefer a native IPv6 6RD-6: The CE router MUST allow different as well as identical =20 interface over a 6rd virtual interface. delegated prefixes to be configured via each (6rd or native) =20 WAN interface. =20 =20 =20 =09 6RD-7: The IPv6 CE router SHOULD support independent WAN interface 6RD-7: In the event that forwarding rules produce a tie between 6rd =20 configuration for 6rd and native IPv6. and native IPv6, by default, the IPv6 CE Router MUST prefer =20 native IPv6. =20 =20 4.4.2. Dual-Stack Lite (DS-Lite) 4.4.2. Dual-Stack Lite (DS-Lite) =20 =20 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 =20 services and incentives for the deployment of IPv6. It also de- services and incentives for the deployment of IPv6. It also de- =20 couples IPv6 deployment in the Service Provider network from the rest couples IPv6 deployment in the Service Provider network from the rest =20 of the Internet, making incremental deployment easier. Dual-Stack of the Internet, making incremental deployment easier. Dual-Stack =20 Lite enables a broadband service provider to share IPv4 addresses Lite enables a broadband service provider to share IPv4 addresses =20 among customers by combining two well-known technologies: IP in IP among customers by combining two well-known technologies: IP in IP =20 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected =20 =20 =20 skipping to change at page 18, line=20 5 =20 skipping to change at page 18, line=20 13 =20 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host =20 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, =20 December 2003. December 2003. =20 =20 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed =20 Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004. =20 =20 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol =20 (DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004. =20 =20 =20 =09 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) =20 Configuration Option for DHCPv6", RFC 4075, May 2005. =20 =09 =20 =20 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and =20 More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005. =20 =20 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast =20 Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005. =20 =20 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh =20 Time Option for Dynamic Host Configuration Protocol for Time Option for Dynamic Host Configuration Protocol for =20 IPv6 (DHCPv6)", RFC 4242, November 2005. IPv6 (DHCPv6)", RFC 4242, November 2005. =20 =20 =20 =20 skipping to change at page 18, line=20 49 =20 skipping to change at page 19, line=20 6 =20 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless =20 Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007. =20 =20 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and =20 E. Klein, "Local Network Protection for IPv6", RFC 4864, E. Klein, "Local Network Protection for IPv6", RFC 4864, =20 May 2007. May 2007. =20 =20 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over =20 PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007. =20 =20 =20 =09 =09 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network =20 Time Protocol Version 4: Protocol and Algorithms =20 Specification", RFC 5905, June 2010. =20 =20 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) =20 Server Option for DHCPv6", RFC 5908, June 2010. =20 =09 =20 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet =20 Model: The Relationship between Links and Subnet Model: The Relationship between Links and Subnet =20 Prefixes", RFC 5942, July 2010. Prefixes", RFC 5942, July 2010. =20 =20 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 =20 Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification", =20 RFC 5969, August 2010. RFC 5969, August 2010. =20 =20 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in =20 Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing =20 =20 =20 End of changes. 14 change=20 blocks.=20 =20 29 lines changed or deleted =20 40 lines changed or added =20 This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ =20 =20 ------_=_NextPart_001_01CD2EC8.181AB7FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Before I = publish the -09, please see the diffs between the impending -09 and the = -08 versions below.  Any comments?

 

Thanks,

 

Hemant

 

 

< draft-ietf-v6ops-6204bis-08.txt <= o:p>

 draft-ietf-v6ops-6204bis-09.txt <= a = href=3D"http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-v6ops-6204bis-09.= txt">>

 

Network Working = Group           &n= bsp;           &nb= sp;           &nbs= p;       H. = Singh

=

Network Working = Group           &n= bsp;           &nb= sp;           &nbs= p;       H. = Singh

 

Internet-Draft         = ;            =             &= nbsp;           &n= bsp;   W. Beebee

=

Internet-Draft         = ;            =             &= nbsp;           &n= bsp;   W. Beebee

 

Obsoletes: 6204 (if approved)     =             &= nbsp;      Cisco Systems, = Inc.

=

Obsoletes: 6204 (if = approved)          &nbs= p;            = ; Cisco Systems, Inc.

 

Intended status: = Informational          =             &= nbsp;          C. = Donley

=

Intended status: = Informational          =              =           C. = Donley

 

 

Expires: October 8, 2012  =            =             &= nbsp;           &n= bsp; CableLabs

=

Expires: November 11, = 2012          &n= bsp;           &nb= sp;           &nbs= p;  CableLabs

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;          =       B. = Stark

=

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;    B. Stark

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;        = AT&T

=

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;        AT&T

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           O. Troan, = Ed.

=

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           O. = Troan, Ed.

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     Cisco Systems, = Inc.

=

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     Cisco Systems, = Inc.

 

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           April 6, 2012

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            May 10, 2012

 

 

           Basic = Requirements for IPv6 Customer Edge = Routers

=

           B= asic Requirements for IPv6 Customer Edge = Routers

 

 

           &= nbsp;          = draft-ietf-v6ops-6204bis-08

=

           &= nbsp;          draft-ie= tf-v6ops-6204bis-09

 

 

Abstract

=

Abstract

 

 

   This document specifies requirements for an IPv6 = Customer Edge (CE)

=

   This document specifies requirements for an IPv6 = Customer Edge (CE)

 

   router.  Specifically, the current version of = this document focuses

=

   router.  Specifically, the current version = of this document focuses

 

   on the basic provisioning of an IPv6 CE router and = the provisioning

=

   on the basic provisioning of an IPv6 CE router = and the provisioning

 

   of IPv6 hosts attached to it.  The document also = covers IP transition

=

   of IPv6 hosts attached to it.  The document = also covers IP transition

 

   technologies.  Two transition technologies in = RFC 5969's 6rd and RFC

=

   technologies.  Two transition technologies = in RFC 5969's 6rd and RFC

 

   6333's DS-Lite are covered in the document.  The = document obsoletes

=

   6333's DS-Lite are covered in the = document.  The document obsoletes

 

   RFC 6204, if approved.

   RFC 6204, if = approved.

 

 

 

skipping to change = at page 1, line =

42

 

skipping to change = at page 1, line =

42

 

   Internet-Drafts are working documents of the Internet = Engineering

=

   Internet-Drafts are working documents of the = Internet Engineering

 

   Task Force (IETF).  Note that other groups may = also distribute

=

   Task Force (IETF).  Note that other groups = may also distribute

 

   working documents as Internet-Drafts.  The list = of current Internet-

=

   working documents as Internet-Drafts.  The = list of current Internet-

 

   Drafts is at = http://datatracker.ietf.org/drafts/current/.

   Drafts is at = http://datatracker.ietf.org/drafts/current/.

 

   Internet-Drafts are draft documents valid for a = maximum of six months

=

   Internet-Drafts are draft documents valid for a = maximum of six months

 

   and may be updated, replaced, or obsoleted by other = documents at any

=

   and may be updated, replaced, or obsoleted by = other documents at any

 

   time.  It is inappropriate to use = Internet-Drafts as reference

=

   time.  It is inappropriate to use = Internet-Drafts as reference

 

   material or to cite them other than as "work in = progress."

=

   material or to cite them other than as = "work in progress."

 

 

 

   This Internet-Draft will expire on October 8, 2012.

   This Internet-Draft will expire on November 11, 2012.

 

 

Copyright Notice

=

Copyright Notice

 

 

   Copyright (c) 2012 IETF Trust and the persons = identified as the

=

   Copyright (c) 2012 IETF Trust and the persons = identified as the

 

   document authors.  All rights = reserved.

=

   document authors.  All rights = reserved.

 

 

   This document is subject to BCP 78 and the IETF = Trust's Legal

=

   This document is subject to BCP 78 and the IETF = Trust's Legal

 

   Provisions Relating to IETF = Documents

=

   Provisions Relating to IETF = Documents

 

   (http://trustee.ietf.org/license-info) in effect on = the date of

=

   (http://trustee.ietf.org/license-info) in effect = on the date of

 

   publication of this document.  Please review = these documents

=

   publication of this document.  Please = review these documents

 

 

 

skipping to change = at page 2, line =

33

 

skipping to change = at page 2, line =

33

 

     4.1.  General Requirements . . . . . = . . . . . . . . . . . . . .  7

     4.1.  General Requirements . . = . . . . . . . . . . . . . . . . .  7

 

     4.2.  WAN-Side Configuration . . . . = . . . . . . . . . . . . . .  7

     4.2.  WAN-Side Configuration . = . . . . . . . . . . . . . . . . .  7

 

     4.3.  LAN-Side Configuration . . . . = . . . . . . . . . . . . . . 11

     4.3.  LAN-Side Configuration . = . . . . . . . . . . . . . . . . . 11

 

     4.4.  Transition Technologies = Support  . . . . . . . . . . . . . 13

     4.4.  Transition Technologies = Support  . . . . . . . . . . . . . 13

 

       4.4.1.  6rd  . . . = . . . . . . . . . . . . . . . . . . . . . . = 13

=

       4.4.1.  6rd  . = . . . . . . . . . . . . . . . . . . . . . . . . = 13

 

       4.4.2.  Dual-Stack Lite = (DS-Lite)  . . . . . . . . . . . . . . = 14

=

       4.4.2.  Dual-Stack = Lite (DS-Lite)  . . . . . . . . . . . . . . = 14

 

     4.5.  Security Considerations  = . . . . . . . . . . . . . . . . . 15

     4.5.  Security = Considerations  . . . . . . . . . . . . . . . . . = 15

 

   5.  IANA Considerations  . . . . . . . . . = . . . . . . . . . . . . 16

=

   5.  IANA Considerations  . . . . . . . = . . . . . . . . . . . . . . 16

 

   6.  Acknowledgements . . . . . . . . . . . . . . = . . . . . . . . . 16

=

   6.  Acknowledgements . . . . . . . . . . . = . . . . . . . . . . . . 16

 

   7.  Contributors . . . . . . . . . . . . . . . . = . . . . . . . . . 16

=

   7.  Contributors . . . . . . . . . . . . . = . . . . . . . . . . . . 16

 

 

   8.  References . . . . . . . . . . . . . . . . . = . . . . . . . . . 16

=

   8.  References . . . . . . . . . . . . . . = . . . . . . . . . . . . 17

 

     8.1.  Normative References . . . . . = . . . . . . . . . . . . . . 16

=

     8.1.  Normative References . . = . . . . . . . . . . . . . . . . . 17

 

     8.2.  Informative References . . . . = . . . . . . . . . . . . . . 19

     8.2.  Informative References . = . . . . . . . . . . . . . . . . . 19

 

 

   Appendix A.  Changes from RFC 6204 . . . . . . . = . . . . . . . . . 19

=

   Appendix A.  Changes from RFC 6204 . . . . = . . . . . . . . . . . . 20

 

   Authors' Addresses . . . . . . . . . . . . . . . . . = . . . . . . . 20

=

   Authors' Addresses . . . . . . . . . . . . . . . = . . . . . . . . . 21

 

 

1.  Introduction

=

1.  Introduction

 

 

   This document defines basic IPv6 features for a = residential or small-

=

   This document defines basic IPv6 features for a = residential or small-

 

   office router, referred to as an IPv6 CE = router.  Typically, these

   office router, referred to as an IPv6 CE = router.  Typically, these

 

   routers also support = IPv4.

=

   routers also support = IPv4.

 

 

   Mixed environments of dual-stack hosts and IPv6-only = hosts (behind

=

   Mixed environments of dual-stack hosts and = IPv6-only hosts (behind

 

   the CE router) can be more complex if the IPv6-only = devices are using

=

   the CE router) can be more complex if the = IPv6-only devices are using

 

   a translator to access IPv4 servers [RFC6144].  = Support for such

=

   a translator to access IPv4 servers = [RFC6144].  Support for such

 

 

 

skipping to change = at page 9, line =

33

 

skipping to change = at page 9, line =

33

 

 

   WAA-3:   The IPv6 CE router MUST support = DHCPv6 [RFC3315] client

=

   WAA-3:   The IPv6 CE router MUST = support DHCPv6 [RFC3315] client

 

            = behavior.

=

           &= nbsp;behavior.

 

 

   WAA-4:   The IPv6 CE router MUST be able to = support the following

=

   WAA-4:   The IPv6 CE router MUST be = able to support the following

 

            = DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], = and

=

           &= nbsp;DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], = and

 

            = DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able = to

=

           &= nbsp;DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able = to

 

            = support the DNS Search List DNSSL option as specified = in

=

           &= nbsp;support the DNS Search List DNSSL option as specified = in

 

            = [RFC3646].

=

           &= nbsp;[RFC3646].

 

 

 

   WAA-5:   The IPv6 CE router SHOULD = implement the Simple Network = Time

=

   WAA-5:   The IPv6 CE router SHOULD = implement the Network Time

 

            = Protocol (SNTP) as specified in [RFC2030].  If the CE = router

=

           &= nbsp;Protocol (NTP) as specified in [RFC5905].  If the CE = router

 

            = implements SNTP, it requests the SNTP option [RFC4075] and

           &= nbsp;implements NTP, it requests the NTP Server DHCPv6 = option

 

            = uses the received list of servers as primary time = reference,

=

           &= nbsp;[RFC5908] and uses the received list = of servers as primary

 

            = unless explicitly configured otherwise.

           &= nbsp;time reference, unless explicitly configured = otherwise.

 

 

   WAA-6:   If the IPv6 CE router receives a = Router Advertisement

=

   WAA-6:   If the IPv6 CE router = receives a Router Advertisement

 

            = message (described in [RFC4861]) with the M flag set to = 1,

=

           &= nbsp;message (described in [RFC4861]) with the M flag set to = 1,

 

            = the IPv6 CE router MUST do DHCPv6 address = assignment

=

           &= nbsp;the IPv6 CE router MUST do DHCPv6 address = assignment

 

            = (request an IA_NA option).

=

           &= nbsp;(request an IA_NA option).

 

 

   WAA-7:   If the IPv6 CE router does not = acquire global IPv6

=

   WAA-7:   If the IPv6 CE router does = not acquire global IPv6

 

            = address(es) from either SLAAC or DHCPv6, then it MUST = create

=

           &= nbsp;address(es) from either SLAAC or DHCPv6, then it MUST = create

 

            = global IPv6 address(es) from its delegated prefix(es) = and

=

           &= nbsp;global IPv6 address(es) from its delegated prefix(es) = and

 

            = configure those on one of its internal virtual = network

=

           &= nbsp;configure those on one of its internal virtual = network

 

            = interfaces, unless configured to require a global = IPv6

=

           &= nbsp;interfaces, unless configured to require a global = IPv6

 

            = address on the WAN interface.

=

           &= nbsp;address on the WAN interface.

 

 

 

   WAA-8:   The CE Router MUST support the DHCPv6 SOL_MAX_RT = option

=

   WAA-8:   The CE Router MUST set its DHCPv6 SOL_MAX_RT parameter = to

 

            = [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received = DHCPv6

=

           &= nbsp;3600 by default.  When the CE Router = receives the = DHCPv6

 

            = Advertise or Reply message and set its = internal SOL_MAX_RT

=

           &= nbsp;SOL_MAX_RT option [I-D.droms-dhc-dhcpv6-maxsolrt-update] = in

 

            = parameter to the value contained in the SOL_MAX_RT = option.

=

           &= nbsp;a received DHCPv6 Advertise or Reply message it sets its

 

           &= nbsp;internal SOL_MAX_RT parameter to the value contained in = the

 

           &= nbsp;SOL_MAX_RT option.

 

 

   WAA-9:   As a router, the IPv6 CE router = MUST follow the weak host

=

   WAA-9:   As a router, the IPv6 CE = router MUST follow the weak host

 

            = (Weak ES) model [RFC1122].  When originating packets from = an

=

           &= nbsp;(Weak ES) model [RFC1122].  When originating packets from = an

 

            = interface, it will use a source address from another one = of

=

           &= nbsp;interface, it will use a source address from another one = of

 

            = its interfaces if the outgoing interface does not have = an

=

           &= nbsp;its interfaces if the outgoing interface does not have = an

 

            = address of suitable scope.

=

           &= nbsp;address of suitable scope.

 

 

   WAA-10:  The IPv6 CE router SHOULD implement the = Information Refresh

=

   WAA-10:  The IPv6 CE router SHOULD = implement the Information Refresh

 

            = Time option and associated client behavior as specified = in

=

           &= nbsp;Time option and associated client behavior as specified = in

 

            = [RFC4242].

=

           &= nbsp;[RFC4242].

 

 

 

skipping to change = at page 14, line =

28

 

skipping to change = at page 14, line =

28

 

           of = IPv4 through IPCP (i.e., over a PPP connection), it = MUST

=

           o= f IPv4 through IPCP (i.e., over a PPP connection), it = MUST

 

           = support user-entered configuration of 6rd.

           s= upport user-entered configuration of 6rd.

 

 

   6RD-3:  If the CE router supports configuration = mechanisms other than

=

   6RD-3:  If the CE router supports = configuration mechanisms other than

 

           the = 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the = CE

=

           t= he 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the = CE

 

           = router MUST support 6rd in "hub and spoke" mode. 6rd in = "hub

=

           r= outer MUST support 6rd in "hub and spoke" mode. 6rd in = "hub

 

           and = spoke" requires all IPv6 traffic to go to the 6rd = Border

=

           a= nd spoke" requires all IPv6 traffic to go to the 6rd = Border

 

           = Relay.  In effect, this requirement removes the = "direct

=

           R= elay.  In effect, this requirement removes the = "direct

 

           = connect to 6rd" route defined in Section 7.1.1 of = [RFC5969].

=

           c= onnect to 6rd" route defined in Section 7.1.1 of = [RFC5969].

 

 

 

   6RD-4:  Per [RFC3704], = Section 4.3, the CE router MUST send = traffic

=

   6RD-4:  A CE = router MUST allow 6rd and native IPv6 WAN interfaces = to

 

           using = a prefix learned via 6rd over the 6rd tunnel.

           b= e active alone as well as simultaneously in order to = support

 

           c= oexistence of the two technologies during an = incremental

 

           m= igration period such as a migration from 6rd to native IPv6.

 

 

 

   6RD-5:  The IPv6 CE router = MUST support two operational modes:

   6RD-5:  Each packet = sent on a 6rd or native WAN interface MUST = be

 

           = different prefixes on 6rd and native interfaces or identical

           d= irected such that its source IP address is derived from = the

 

           = prefixes on 6rd and native interfaces.

           d= elegated prefix associated with the upstream network the = WAN

 

           i= nterface is connected to [Section 4.3 [RFC3704]].

 

 

 

   6RD-6:  By default, the = IPv6 CE router MUST prefer a native = IPv6

=

   6RD-6:  The CE = router MUST allow different as well as = identical

 

           = interface over a 6rd virtual = interface.

=

           d= elegated prefixes to be configured via each (6rd or = native)

 

           W= AN interface.

 

 

 

   6RD-7:  The IPv6 CE router = SHOULD support independent WAN = interface

=

   6RD-7:  In the event = that forwarding rules produce a tie between = 6rd

 

           = configuration for 6rd and native = IPv6.

=

           a= nd native IPv6, by default, the IPv6 CE Router = MUST prefer

 

           n= ative IPv6.

 

 

4.4.2.  Dual-Stack Lite = (DS-Lite)

=

4.4.2.  Dual-Stack Lite = (DS-Lite)

 

 

   Dual-Stack Lite [RFC6333] enables both continued = support for IPv4

=

   Dual-Stack Lite [RFC6333] enables both continued = support for IPv4

 

   services and incentives for the deployment of = IPv6.  It also de-

=

   services and incentives for the deployment of = IPv6.  It also de-

 

   couples IPv6 deployment in the Service Provider = network from the rest

=

   couples IPv6 deployment in the Service Provider = network from the rest

 

   of the Internet, making incremental deployment = easier.  Dual-Stack

=

   of the Internet, making incremental deployment = easier.  Dual-Stack

 

   Lite enables a broadband service provider to share = IPv4 addresses

=

   Lite enables a broadband service provider to = share IPv4 addresses

 

   among customers by combining two well-known = technologies: IP in IP

=

   among customers by combining two well-known = technologies: IP in IP

 

   (IPv4-in-IPv6) and Network Address Translation = (NAT).  It is expected

=

   (IPv4-in-IPv6) and Network Address Translation = (NAT).  It is expected

 

 

 

skipping to change = at page 18, line =

5

 

skipping to change = at page 18, line =

13

 

   [RFC3646]  Droms, R., "DNS Configuration = options for Dynamic Host

=

   [RFC3646]  Droms, R., "DNS = Configuration options for Dynamic Host

 

           &= nbsp;  Configuration Protocol for IPv6 (DHCPv6)", RFC = 3646,

=

           &= nbsp;  Configuration Protocol for IPv6 (DHCPv6)", RFC = 3646,

 

           &= nbsp;  December 2003.

=

           &= nbsp;  December 2003.

 

 

   [RFC3704]  Baker, F. and P. Savola, = "Ingress Filtering for Multihomed

   [RFC3704]  Baker, F. and P. Savola, = "Ingress Filtering for Multihomed

 

           &= nbsp;  Networks", BCP 84, RFC 3704, March = 2004.

=

           &= nbsp;  Networks", BCP 84, RFC 3704, March = 2004.

 

 

   [RFC3736]  Droms, R., "Stateless Dynamic = Host Configuration Protocol

=

   [RFC3736]  Droms, R., "Stateless = Dynamic Host Configuration Protocol

 

           &= nbsp;  (DHCP) Service for IPv6", RFC 3736, April = 2004.

=

           &= nbsp;  (DHCP) Service for IPv6", RFC 3736, April = 2004.

 

 

 

   [RFC4075]  Kalusivalingam, = V., "Simple Network Time Protocol = (SNTP)

=

 

           &= nbsp;  Configuration Option for DHCPv6", RFC 4075, May = 2005.

=

 

         =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;   

 

 

   [RFC4191]  Draves, R. and D. Thaler, = "Default Router Preferences and

   [RFC4191]  Draves, R. and D. Thaler, = "Default Router Preferences and

 

           &= nbsp;  More-Specific Routes", RFC 4191, November = 2005.

=

           &= nbsp;  More-Specific Routes", RFC 4191, November = 2005.

 

 

   [RFC4193]  Hinden, R. and B. Haberman, = "Unique Local IPv6 Unicast

   [RFC4193]  Hinden, R. and B. Haberman, = "Unique Local IPv6 Unicast

 

           &= nbsp;  Addresses", RFC 4193, October = 2005.

=

          Address= es", RFC 4193, October 2005.

 

 

   [RFC4242]  Venaas, S., Chown, T., and B. Volz, = "Information Refresh

=

   [RFC4242]  Venaas, S., Chown, T., and B. = Volz, "Information Refresh

 

           &= nbsp;  Time Option for Dynamic Host Configuration Protocol = for

=

           &= nbsp;  Time Option for Dynamic Host Configuration Protocol = for

 

           &= nbsp;  IPv6 (DHCPv6)", RFC 4242, November = 2005.

=

           &= nbsp;  IPv6 (DHCPv6)", RFC 4242, November = 2005.

 

 

 

 

skipping to change = at page 18, line =

49

 

skipping to change = at page 19, line =

6

 

   [RFC4862]  Thomson, S., Narten, T., and T. = Jinmei, "IPv6 Stateless

=

   [RFC4862]  Thomson, S., Narten, T., and T. = Jinmei, "IPv6 Stateless

 

           &= nbsp;  Address Autoconfiguration", RFC 4862, September = 2007.

=

           &= nbsp;  Address Autoconfiguration", RFC 4862, September = 2007.

 

 

   [RFC4864]  Van de Velde, G., Hain, T., Droms, = R., Carpenter, B., and

=

   [RFC4864]  Van de Velde, G., Hain, T., = Droms, R., Carpenter, B., and

 

           &= nbsp;  E. Klein, "Local Network Protection for IPv6", RFC = 4864,

=

           &= nbsp;  E. Klein, "Local Network Protection for = IPv6", RFC 4864,

 

           &= nbsp;  May 2007.

=

           &= nbsp;  May 2007.

 

 

   [RFC5072]  S.Varada, Haskins, D., and E. Allen, = "IP Version 6 over

=

   [RFC5072]  S.Varada, Haskins, D., and E. = Allen, "IP Version 6 over

 

           &= nbsp;  PPP", RFC 5072, September = 2007.

=

           &= nbsp;  PPP", RFC 5072, September = 2007.

 

 

 

   [RFC5905]  Mills, D., = Martin, J., Burbank, J., and W. Kasch, = "Network

 

           &= nbsp;  Time Protocol Version 4: Protocol and = Algorithms

 

           &= nbsp;  Specification", RFC 5905, June = 2010.

 

 

   [RFC5908]  Gayraud, R. and B. Lourdelet, = "Network Time Protocol (NTP)

 

           &= nbsp;  Server Option for DHCPv6", RFC 5908, June = 2010.

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  

 

   [RFC5942]  Singh, H., Beebee, W., and E. = Nordmark, "IPv6 Subnet

=

   [RFC5942]  Singh, H., Beebee, W., and E. = Nordmark, "IPv6 Subnet

 

           &= nbsp;  Model: The Relationship between Links and = Subnet

=

           &= nbsp;  Model: The Relationship between Links and = Subnet

 

           &= nbsp;  Prefixes", RFC 5942, July = 2010.

=

           &= nbsp;  Prefixes", RFC 5942, July = 2010.

 

 

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 = Rapid Deployment on IPv4

=

   [RFC5969]  Townsley, W. and O. Troan, = "IPv6 Rapid Deployment on IPv4

 

           &= nbsp;  Infrastructures (6rd) -- Protocol = Specification",

=

           &= nbsp;  Infrastructures (6rd) -- Protocol = Specification",

 

           &= nbsp;  RFC 5969, August 2010.

           &= nbsp;  RFC 5969, August 2010.

 

 

   [RFC6092]  Woodyatt, J., "Recommended = Simple Security Capabilities in

   [RFC6092]  Woodyatt, J., "Recommended = Simple Security Capabilities in

 

           &= nbsp;  Customer Premises Equipment (CPE) for = Providing

=

           &= nbsp;  Customer Premises Equipment (CPE) for = Providing

 

 

 

 End of = changes. 14 change

blocks. 

 

29 lines changed or = deleted

 

40 lines changed or = added

 


This html diff = was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/t= ools/rfcdiff/

 

------_=_NextPart_001_01CD2EC8.181AB7FB-- From dwing@cisco.com Thu May 10 10:24:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0496421F8713 for ; Thu, 10 May 2012 10:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdNxYCeoEZRL for ; Thu, 10 May 2012 10:24:19 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4990C21F871E for ; Thu, 10 May 2012 10:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2290; q=dns/txt; s=iport; t=1336670657; x=1337880257; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=4yB/UJogxwIJXjHB5lmKEgSFPh1nYvJ/Tb5U+cYwKZ8=; b=geHNSYyR1r85ckcLSb1qBYYKAqUm6MUNsVIi80UyAdXqVBA5pKCRbwmO eeXTSG4cc2unzzI7ziX6ZHGz9FH7WQ0INWD5W4JsPswc3smFtJBTIcj6V GVWnRnlimNp27nxyYtVw58osa9IRqOQjklCQx+FUwiPx2Ym8ieFi5Zq3N c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFANz4q0+rRDoG/2dsb2JhbABEoyCQc4EHghUBAQEDAQEBAQUKARdECwUHAQMCFwECBAEBAScHGQ4VCgkIAQEEARILF4dnBAybLaAjixKGKQSIMDSFFokUjUaBaYMJ X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="44290865" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 May 2012 17:24:16 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4AHOFnA004102; Thu, 10 May 2012 17:24:15 GMT From: "Dan Wing" To: "'Chris Donley'" , "'STARK, BARBARA H'" , "=?iso-8859-1?Q?'Ole_Tr=F8an'?=" , "'Hans Liu'" References: <2D09D61DDFA73D4C884805CC7865E6110C1604@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: Date: Thu, 10 May 2012 10:24:16 -0700 Message-ID: <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0tYAhy58A+Gd1nRu6kg6mUx09v9QBb9Oag Content-Language: en-us Cc: 'IPv6 Operations' Subject: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 May 2012 17:24:20 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Chris Donley > Sent: Tuesday, May 08, 2012 2:18 PM > To: STARK, BARBARA H; Ole Tr=F8an; Hans Liu > Cc: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) >=20 > Our testing shows that NAT444 offers a better user experience than DS- > Lite (due in part to MTU issues). =20 On the MTU issue, Dual-Stack Lite suggests that ISPs deploy larger MTU between the subscriber's B4 and the AFTR element. The same paragraph admits this may not always be feasible. http://tools.ietf.org/html/rfc6333#section-5.3 =20 I assume, without knowing for sure, that your testing did not=20 follow RFC6333's recommendation to use a larger MTU over that=20 path. The industry has long experience with PPPoE, which also has a=20 shorter MTU, and causes various problems. The problems are=20 generally resolved by CPE routers that rewrite the MSS=20 option of outgoing TCP SYNs. However, such MSS option rewriting=20 is frowned upon by many technologists as a layering violation=20 and thus is not mentioned in RFC6333. However, it is effective=20 at reducing round trips for servers to discover the smaller MTU (where ICMP packet too big succeeds) and avoids the delays=20 of PMTUD blackhole discovery (when ICMP packet too big fails). I assume, without knowing for sure, that your testing did not include TCP MSS rewriting. -d > Customer hat on - I would strongly prefer > native IPv4 to DS-Lite, even if that native v4 address were behind a > CGN. >=20 >=20 > Chris >=20 >=20 >=20 >=20 > On 5/8/12 7:16 AM, "STARK, BARBARA H" wrote: >=20 > >> do we all agree that for IPv4, a CPE should prefer a DS-lite > connection > >>over a > >> native one? > > > >Is the native one giving me a CGN NATted IPv4 address, or a public > IPv4 > >address? I think I would prefer public IPv4 over DS-Lite over CGN. > >Barbara > >_______________________________________________ > >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 shemant@cisco.com Thu May 10 10:24:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C1621F8720 for ; Thu, 10 May 2012 10:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.012 X-Spam-Level: X-Spam-Status: No, score=-10.012 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQuftGOCEMnH for ; Thu, 10 May 2012 10:24:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6984521F871C for ; Thu, 10 May 2012 10:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=233420; q=dns/txt; s=iport; t=1336670654; x=1337880254; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=gduQveVOelLRtJV9mpff0HMZzSa0lMWFNwLy5+gfyd8=; b=gfVeBGD71317SoWY7eG9cnqrlU72jimrtc1bKSblI5Fwp5dLDQCu6wr0 wTKG+CG70n+5Ocy3jEUXuQsx/Rc1eSF/tOR/XqdXITje3Co28AIorxr7b r5DmC69K93Xofy6MI35BG7U5vJC75Hjos8Y/7OEChxD5kjua9l+AT0u4u M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgGANz4q0+tJV2Z/2dsb2JhbABEgkaGF6E7AYl6gQeCFQEBAQQSAQcBAREDQhcCAQgRBAEBCwYQAQYBBgFFCQgBAQQBEggah2wLmy2gI4sShUZjBIhkjiqNRoFpgTeBUA X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208,217";a="82131142" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 10 May 2012 17:24:12 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4AHOCsS025908 for ; Thu, 10 May 2012 17:24:12 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 12:24:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2ED1.B6DC3097" Date: Thu, 10 May 2012 12:24:10 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A013EC@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A0137F@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] diffs for rfc6204bis next version Thread-Index: Ac0uyBeQSiUkobXWRHaCjyvZalx89wACYdYw References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A0137F@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , X-OriginalArrivalTime: 10 May 2012 17:24:11.0764 (UTC) FILETIME=[B70B8340:01CD2ED1] Subject: Re: [v6ops] diffs for rfc6204bis next version X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 May 2012 17:24:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2ED1.B6DC3097 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chris pointed out the reference to Ralph's solmaxrt was incorrectly named. I fixed the issue. =20 Thanks, =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Thursday, May 10, 2012 12:15 PM To: v6ops@ietf.org Subject: [v6ops] diffs for rfc6204bis next version =20 Before I publish the -09, please see the diffs between the impending -09 and the -08 versions below. Any comments? =20 Thanks, =20 Hemant =20 < draft-ietf-v6ops-6204bis-08.txt =20 draft-ietf-v6ops-6204bis-09.txt > =20 =09 =20 Network Working Group H. Singh Network Working Group H. Singh =20 Internet-Draft W. Beebee Internet-Draft W. Beebee =20 Obsoletes: 6204 (if approved) Cisco Systems, Inc. Obsoletes: 6204 (if approved) Cisco Systems, Inc. =20 Intended status: Informational C. Donley Intended status: Informational C. Donley =20 =20 =09 Expires: October 8, 2012 CableLabs Expires: November 11, 2012 CableLabs =20 =09 B. Stark =09 B. Stark =20 =09 AT&T =09 AT&T =20 O. Troan, Ed. O. Troan, Ed. =20 Cisco Systems, Inc. Cisco Systems, Inc. =20 =20 =09 April 6, 2012 May 10, 2012 =20 =20 Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers =20 =20 =09 draft-ietf-v6ops-6204bis-08 draft-ietf-v6ops-6204bis-09 =20 =20 Abstract Abstract =20 =20 This document specifies requirements for an IPv6 Customer Edge (CE) This document specifies requirements for an IPv6 Customer Edge (CE) =20 router. Specifically, the current version of this document focuses router. Specifically, the current version of this document focuses =20 on the basic provisioning of an IPv6 CE router and the provisioning on the basic provisioning of an IPv6 CE router and the provisioning =20 of IPv6 hosts attached to it. The document also covers IP transition of IPv6 hosts attached to it. The document also covers IP transition =20 technologies. Two transition technologies in RFC 5969's 6rd and RFC technologies. Two transition technologies in RFC 5969's 6rd and RFC =20 6333's DS-Lite are covered in the document. The document obsoletes 6333's DS-Lite are covered in the document. The document obsoletes =20 RFC 6204, if approved. RFC 6204, if approved. =20 =20 =20 skipping to change at page 1, line=20 42 =20 skipping to change at page 1, line=20 42 =20 Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering =20 Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute =20 working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet- =20 Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/. =20 =20 Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months =20 and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any =20 time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference =20 material or to cite them other than as "work in progress." material or to cite them other than as "work in progress." =20 =20 =20 =09 This Internet-Draft will expire on October 8, 2012. This Internet-Draft will expire on November 11, 2012. =20 =20 Copyright Notice Copyright Notice =20 =20 Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the =20 document authors. All rights reserved. document authors. All rights reserved. =20 =20 This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal =20 Provisions Relating to IETF Documents Provisions Relating to IETF Documents =20 (http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of =20 publication of this document. Please review these documents publication of this document. Please review these documents =20 =20 =20 skipping to change at page 2, line=20 33 =20 skipping to change at page 2, line=20 33 =20 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 =20 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7 =20 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11 =20 4.4. Transition Technologies Support . . . . . . . . . . . . . 13 4.4. Transition Technologies Support . . . . . . . . . . . . . 13 =20 4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13 =20 4.4.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 14 4.4.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 14 =20 4.5. Security Considerations . . . . . . . . . . . . . . . . . 15 4.5. Security Considerations . . . . . . . . . . . . . . . . . 15 =20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 =20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 =20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 =20 =20 =09 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 =20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 =20 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 =20 =20 =09 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 19 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 20 =20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 =20 =20 1. Introduction 1. Introduction =20 =20 This document defines basic IPv6 features for a residential or small- This document defines basic IPv6 features for a residential or small- =20 office router, referred to as an IPv6 CE router. Typically, these office router, referred to as an IPv6 CE router. Typically, these =20 routers also support IPv4. routers also support IPv4. =20 =20 Mixed environments of dual-stack hosts and IPv6-only hosts (behind Mixed environments of dual-stack hosts and IPv6-only hosts (behind =20 the CE router) can be more complex if the IPv6-only devices are using the CE router) can be more complex if the IPv6-only devices are using =20 a translator to access IPv4 servers [RFC6144]. Support for such a translator to access IPv4 servers [RFC6144]. Support for such =20 =20 =20 skipping to change at page 9, line=20 33 =20 skipping to change at page 9, line=20 33 =20 =20 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client =20 behavior. behavior. =20 =20 WAA-4: The IPv6 CE router MUST be able to support the following WAA-4: The IPv6 CE router MUST be able to support the following =20 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and =20 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to =20 support the DNS Search List DNSSL option as specified in support the DNS Search List DNSSL option as specified in =20 [RFC3646]. [RFC3646]. =20 =20 =20 =09 WAA-5: The IPv6 CE router SHOULD implement the Simple Network Time WAA-5: The IPv6 CE router SHOULD implement the Network Time =20 Protocol (SNTP) as specified in [RFC2030]. If the CE router Protocol (NTP) as specified in [RFC5905]. If the CE router =20 implements SNTP, it requests the SNTP option [RFC4075] and implements NTP, it requests the NTP Server DHCPv6 option =20 uses the received list of servers as primary time reference, [RFC5908] and uses the received list of servers as primary =20 unless explicitly configured otherwise. time reference, unless explicitly configured otherwise. =20 =20 WAA-6: If the IPv6 CE router receives a Router Advertisement WAA-6: If the IPv6 CE router receives a Router Advertisement =20 message (described in [RFC4861]) with the M flag set to 1, message (described in [RFC4861]) with the M flag set to 1, =20 the IPv6 CE router MUST do DHCPv6 address assignment the IPv6 CE router MUST do DHCPv6 address assignment =20 (request an IA_NA option). (request an IA_NA option). =20 =20 WAA-7: If the IPv6 CE router does not acquire global IPv6 WAA-7: If the IPv6 CE router does not acquire global IPv6 =20 address(es) from either SLAAC or DHCPv6, then it MUST create address(es) from either SLAAC or DHCPv6, then it MUST create =20 global IPv6 address(es) from its delegated prefix(es) and global IPv6 address(es) from its delegated prefix(es) and =20 configure those on one of its internal virtual network configure those on one of its internal virtual network =20 interfaces, unless configured to require a global IPv6 interfaces, unless configured to require a global IPv6 =20 address on the WAN interface. address on the WAN interface. =20 =20 =20 =09 WAA-8: The CE Router MUST support the DHCPv6 SOL_MAX_RT option WAA-8: The CE Router MUST set its DHCPv6 SOL_MAX_RT parameter to =20 [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 3600 by default. When the CE Router receives the DHCPv6 =20 Advertise or Reply message and set its internal SOL_MAX_RT SOL_MAX_RT option [I-D.droms-dhc-dhcpv6-maxsolrt-update] in =20 parameter to the value contained in the SOL_MAX_RT option. a received DHCPv6 Advertise or Reply message it sets its =20 internal SOL_MAX_RT parameter to the value contained in the =20 SOL_MAX_RT option. =20 =20 WAA-9: As a router, the IPv6 CE router MUST follow the weak host WAA-9: As a router, the IPv6 CE router MUST follow the weak host =20 (Weak ES) model [RFC1122]. When originating packets from an (Weak ES) model [RFC1122]. When originating packets from an =20 interface, it will use a source address from another one of interface, it will use a source address from another one of =20 its interfaces if the outgoing interface does not have an its interfaces if the outgoing interface does not have an =20 address of suitable scope. address of suitable scope. =20 =20 WAA-10: The IPv6 CE router SHOULD implement the Information Refresh WAA-10: The IPv6 CE router SHOULD implement the Information Refresh =20 Time option and associated client behavior as specified in Time option and associated client behavior as specified in =20 [RFC4242]. [RFC4242]. =20 =20 =20 skipping to change at page 14, line=20 28 =20 skipping to change at page 14, line=20 28 =20 of IPv4 through IPCP (i.e., over a PPP connection), it MUST of IPv4 through IPCP (i.e., over a PPP connection), it MUST =20 support user-entered configuration of 6rd. support user-entered configuration of 6rd. =20 =20 6RD-3: If the CE router supports configuration mechanisms other than 6RD-3: If the CE router supports configuration mechanisms other than =20 the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE =20 router MUST support 6rd in "hub and spoke" mode. 6rd in "hub router MUST support 6rd in "hub and spoke" mode. 6rd in "hub =20 and spoke" requires all IPv6 traffic to go to the 6rd Border and spoke" requires all IPv6 traffic to go to the 6rd Border =20 Relay. In effect, this requirement removes the "direct Relay. In effect, this requirement removes the "direct =20 connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. =20 =20 =20 =09 6RD-4: Per [RFC3704], Section 4.3, the CE router MUST send traffic 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to =20 using a prefix learned via 6rd over the 6rd tunnel. be active alone as well as simultaneously in order to support =20 coexistence of the two technologies during an incremental =20 migration period such as a migration from 6rd to native IPv6. =20 =20 =20 =09 6RD-5: The IPv6 CE router MUST support two operational modes: 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be =20 different prefixes on 6rd and native interfaces or identical directed such that its source IP address is derived from the =20 prefixes on 6rd and native interfaces. delegated prefix associated with the upstream network the WAN =20 interface is connected to [Section 4.3 [RFC3704]]. =20 =20 =20 =09 6RD-6: By default, the IPv6 CE router MUST prefer a native IPv6 6RD-6: The CE router MUST allow different as well as identical =20 interface over a 6rd virtual interface. delegated prefixes to be configured via each (6rd or native) =20 WAN interface. =20 =20 =20 =09 6RD-7: The IPv6 CE router SHOULD support independent WAN interface 6RD-7: In the event that forwarding rules produce a tie between 6rd =20 configuration for 6rd and native IPv6. and native IPv6, by default, the IPv6 CE Router MUST prefer =20 native IPv6. =20 =20 4.4.2. Dual-Stack Lite (DS-Lite) 4.4.2. Dual-Stack Lite (DS-Lite) =20 =20 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 Dual-Stack Lite [RFC6333] enables both continued support for IPv4 =20 services and incentives for the deployment of IPv6. It also de- services and incentives for the deployment of IPv6. It also de- =20 couples IPv6 deployment in the Service Provider network from the rest couples IPv6 deployment in the Service Provider network from the rest =20 of the Internet, making incremental deployment easier. Dual-Stack of the Internet, making incremental deployment easier. Dual-Stack =20 Lite enables a broadband service provider to share IPv4 addresses Lite enables a broadband service provider to share IPv4 addresses =20 among customers by combining two well-known technologies: IP in IP among customers by combining two well-known technologies: IP in IP =20 (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected =20 =20 =20 skipping to change at page 18, line=20 5 =20 skipping to change at page 18, line=20 13 =20 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host =20 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, =20 December 2003. December 2003. =20 =20 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed =20 Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004. =20 =20 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol =20 (DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004. =20 =20 =20 =09 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) =20 Configuration Option for DHCPv6", RFC 4075, May 2005. =20 =09 =20 =20 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and =20 More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005. =20 =20 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast =20 Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005. =20 =20 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh =20 Time Option for Dynamic Host Configuration Protocol for Time Option for Dynamic Host Configuration Protocol for =20 IPv6 (DHCPv6)", RFC 4242, November 2005. IPv6 (DHCPv6)", RFC 4242, November 2005. =20 =20 =20 =20 skipping to change at page 18, line=20 49 =20 skipping to change at page 19, line=20 6 =20 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless =20 Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007. =20 =20 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and =20 E. Klein, "Local Network Protection for IPv6", RFC 4864, E. Klein, "Local Network Protection for IPv6", RFC 4864, =20 May 2007. May 2007. =20 =20 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over =20 PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007. =20 =20 =20 =09 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network =20 Time Protocol Version 4: Protocol and Algorithms =20 Specification", RFC 5905, June 2010. =20 =20 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) =20 Server Option for DHCPv6", RFC 5908, June 2010. =20 =09 =20 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet =20 Model: The Relationship between Links and Subnet Model: The Relationship between Links and Subnet =20 Prefixes", RFC 5942, July 2010. Prefixes", RFC 5942, July 2010. =20 =20 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 =20 Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification", =20 RFC 5969, August 2010. RFC 5969, August 2010. =20 =20 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in =20 Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing =20 =20 =20 End of changes. 14 change=20 blocks.=20 =20 29 lines changed or deleted =20 40 lines changed or added =20 This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ =20 =20 ------_=_NextPart_001_01CD2ED1.B6DC3097 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chris pointed out the reference to Ralph’s = solmaxrt was incorrectly named.  I fixed the = issue.

 

Thanks,

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Hemant Singh (shemant)
Sent: Thursday, May 10, 2012 12:15 = PM
To: v6ops@ietf.org
Subject: [v6ops] diffs for = rfc6204bis next version

 

Before I = publish the -09, please see the diffs between the impending -09 and the = -08 versions below.  Any comments?

 

Thanks,

 

Hemant

 

 

< draft-ietf-v6ops-6204bis-08.txt <= o:p>

 draft-ietf-v6ops-6204bis-09.txt <= a = href=3D"http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-v6ops-6204bis-09.= txt">>

 

Network Working = Group           &n= bsp;           &nb= sp;           &nbs= p;       H. = Singh

Network Working = Group           &n= bsp;           &nb= sp;           &nbs= p;       H. = Singh

 

Internet-Draft         = ;            =             &= nbsp;           &n= bsp;   W. Beebee

Internet-Draft         = ;            =             &= nbsp;           &n= bsp;   W. Beebee

 

Obsoletes: 6204 (if approved)     =             &= nbsp;      Cisco Systems, = Inc.

Obsoletes: 6204 (if = approved)          &nbs= p;            = ; Cisco Systems, Inc.

 

Intended status: = Informational          =             &= nbsp;          C. = Donley

Intended status: = Informational          =              =           C. = Donley

 

 

Expires: October 8, 2012  =            =             &= nbsp;           &n= bsp; CableLabs

Expires: November 11, = 2012          &n= bsp;           &nb= sp;           &nbs= p;  CableLabs

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;          =       B. = Stark

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;    B. Stark

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;        = AT&T

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;        AT&T

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           O. Troan, = Ed.

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           O. = Troan, Ed.

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     Cisco Systems, = Inc.

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     Cisco Systems, = Inc.

 

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           April 6, 2012

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            May 10, 2012

 

 

           Basic = Requirements for IPv6 Customer Edge = Routers

           B= asic Requirements for IPv6 Customer Edge = Routers

 

 

           &= nbsp;          = draft-ietf-v6ops-6204bis-08

           &= nbsp;          draft-ie= tf-v6ops-6204bis-09

 

 

Abstract

Abstract

 

 

   This document specifies requirements for an IPv6 = Customer Edge (CE)

   This document specifies requirements for an IPv6 = Customer Edge (CE)

 

   router.  Specifically, the current version of = this document focuses

   router.  Specifically, the current version = of this document focuses

 

   on the basic provisioning of an IPv6 CE router and = the provisioning

   on the basic provisioning of an IPv6 CE router = and the provisioning

 

   of IPv6 hosts attached to it.  The document also = covers IP transition

   of IPv6 hosts attached to it.  The document = also covers IP transition

 

   technologies.  Two transition technologies in = RFC 5969's 6rd and RFC

   technologies.  Two transition technologies = in RFC 5969's 6rd and RFC

 

   6333's DS-Lite are covered in the document.  The = document obsoletes

   6333's DS-Lite are covered in the = document.  The document obsoletes

 

   RFC 6204, if approved.

   RFC 6204, if = approved.

 

 

 

skipping to change = at page 1, line =

42

 

skipping to change = at page 1, line =

42

 

   Internet-Drafts are working documents of the Internet = Engineering

   Internet-Drafts are working documents of the = Internet Engineering

 

   Task Force (IETF).  Note that other groups may = also distribute

   Task Force (IETF).  Note that other groups = may also distribute

 

   working documents as Internet-Drafts.  The list = of current Internet-

   working documents as Internet-Drafts.  The = list of current Internet-

 

   Drafts is at = http://datatracker.ietf.org/drafts/current/.

   Drafts is at = http://datatracker.ietf.org/drafts/current/.

 

   Internet-Drafts are draft documents valid for a = maximum of six months

   Internet-Drafts are draft documents valid for a = maximum of six months

 

   and may be updated, replaced, or obsoleted by other = documents at any

   and may be updated, replaced, or obsoleted by = other documents at any

 

   time.  It is inappropriate to use = Internet-Drafts as reference

   time.  It is inappropriate to use = Internet-Drafts as reference

 

   material or to cite them other than as "work in = progress."

   material or to cite them other than as = "work in progress."

 

 

 

   This Internet-Draft will expire on October 8, 2012.

   This Internet-Draft will expire on November 11, 2012.

 

 

Copyright Notice

Copyright Notice

 

 

   Copyright (c) 2012 IETF Trust and the persons = identified as the

   Copyright (c) 2012 IETF Trust and the persons = identified as the

 

   document authors.  All rights = reserved.

   document authors.  All rights = reserved.

 

 

   This document is subject to BCP 78 and the IETF = Trust's Legal

   This document is subject to BCP 78 and the IETF = Trust's Legal

 

   Provisions Relating to IETF = Documents

   Provisions Relating to IETF = Documents

 

   (http://trustee.ietf.org/license-info) in effect on = the date of

   (http://trustee.ietf.org/license-info) in effect = on the date of

 

   publication of this document.  Please review = these documents

   publication of this document.  Please = review these documents

 

 

 

skipping to change = at page 2, line =

33

 

skipping to change = at page 2, line =

33

 

     4.1.  General Requirements . . . . . = . . . . . . . . . . . . . .  7

     4.1.  General Requirements . . = . . . . . . . . . . . . . . . . .  7

 

     4.2.  WAN-Side Configuration . . . . = . . . . . . . . . . . . . .  7

     4.2.  WAN-Side Configuration . = . . . . . . . . . . . . . . . . .  7

 

     4.3.  LAN-Side Configuration . . . . = . . . . . . . . . . . . . . 11

     4.3.  LAN-Side Configuration . = . . . . . . . . . . . . . . . . . 11

 

     4.4.  Transition Technologies = Support  . . . . . . . . . . . . . 13

     4.4.  Transition Technologies = Support  . . . . . . . . . . . . . 13

 

       4.4.1.  6rd  . . . = . . . . . . . . . . . . . . . . . . . . . . = 13

       4.4.1.  6rd  . = . . . . . . . . . . . . . . . . . . . . . . . . = 13

 

       4.4.2.  Dual-Stack Lite = (DS-Lite)  . . . . . . . . . . . . . . = 14

       4.4.2.  Dual-Stack = Lite (DS-Lite)  . . . . . . . . . . . . . . = 14

 

     4.5.  Security Considerations  = . . . . . . . . . . . . . . . . . 15

     4.5.  Security = Considerations  . . . . . . . . . . . . . . . . . = 15

 

   5.  IANA Considerations  . . . . . . . . . = . . . . . . . . . . . . 16

   5.  IANA Considerations  . . . . . . . = . . . . . . . . . . . . . . 16

 

   6.  Acknowledgements . . . . . . . . . . . . . . = . . . . . . . . . 16

   6.  Acknowledgements . . . . . . . . . . . = . . . . . . . . . . . . 16

 

   7.  Contributors . . . . . . . . . . . . . . . . = . . . . . . . . . 16

   7.  Contributors . . . . . . . . . . . . . = . . . . . . . . . . . . 16

 

 

   8.  References . . . . . . . . . . . . . . . . . = . . . . . . . . . 16

   8.  References . . . . . . . . . . . . . . = . . . . . . . . . . . . 17

 

     8.1.  Normative References . . . . . = . . . . . . . . . . . . . . 16

     8.1.  Normative References . . = . . . . . . . . . . . . . . . . . 17

 

     8.2.  Informative References . . . . = . . . . . . . . . . . . . . 19

     8.2.  Informative References . = . . . . . . . . . . . . . . . . . 19

 

 

   Appendix A.  Changes from RFC 6204 . . . . . . . = . . . . . . . . . 19

   Appendix A.  Changes from RFC 6204 . . . . = . . . . . . . . . . . . 20

 

   Authors' Addresses . . . . . . . . . . . . . . . . . = . . . . . . . 20

   Authors' Addresses . . . . . . . . . . . . . . . = . . . . . . . . . 21

 

 

1.  Introduction

1.  Introduction

 

 

   This document defines basic IPv6 features for a = residential or small-

   This document defines basic IPv6 features for a = residential or small-

 

   office router, referred to as an IPv6 CE = router.  Typically, these

   office router, referred to as an IPv6 CE = router.  Typically, these

 

   routers also support = IPv4.

   routers also support = IPv4.

 

 

   Mixed environments of dual-stack hosts and IPv6-only = hosts (behind

   Mixed environments of dual-stack hosts and = IPv6-only hosts (behind

 

   the CE router) can be more complex if the IPv6-only = devices are using

   the CE router) can be more complex if the = IPv6-only devices are using

 

   a translator to access IPv4 servers [RFC6144].  = Support for such

   a translator to access IPv4 servers = [RFC6144].  Support for such

 

 

 

skipping to change = at page 9, line =

33

 

skipping to change = at page 9, line =

33

 

 

   WAA-3:   The IPv6 CE router MUST support = DHCPv6 [RFC3315] client

   WAA-3:   The IPv6 CE router MUST = support DHCPv6 [RFC3315] client

 

            = behavior.

           &= nbsp;behavior.

 

 

   WAA-4:   The IPv6 CE router MUST be able to = support the following

   WAA-4:   The IPv6 CE router MUST be = able to support the following

 

            = DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], = and

           &= nbsp;DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], = and

 

            = DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able = to

           &= nbsp;DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able = to

 

            = support the DNS Search List DNSSL option as specified = in

           &= nbsp;support the DNS Search List DNSSL option as specified = in

 

            = [RFC3646].

           &= nbsp;[RFC3646].

 

 

 

   WAA-5:   The IPv6 CE router SHOULD = implement the Simple Network = Time

   WAA-5:   The IPv6 CE router SHOULD = implement the Network Time

 

            = Protocol (SNTP) as specified in [RFC2030].  If the CE = router

           &= nbsp;Protocol (NTP) as specified in [RFC5905].  If the CE = router

 

            = implements SNTP, it requests the SNTP option [RFC4075] and

           &= nbsp;implements NTP, it requests the NTP Server DHCPv6 = option

 

            = uses the received list of servers as primary time = reference,

           &= nbsp;[RFC5908] and uses the received list = of servers as primary

 

            = unless explicitly configured otherwise.

           &= nbsp;time reference, unless explicitly configured = otherwise.

 

 

   WAA-6:   If the IPv6 CE router receives a = Router Advertisement

   WAA-6:   If the IPv6 CE router = receives a Router Advertisement

 

            = message (described in [RFC4861]) with the M flag set to = 1,

           &= nbsp;message (described in [RFC4861]) with the M flag set to = 1,

 

            = the IPv6 CE router MUST do DHCPv6 address = assignment

           &= nbsp;the IPv6 CE router MUST do DHCPv6 address = assignment

 

            = (request an IA_NA option).

           &= nbsp;(request an IA_NA option).

 

 

   WAA-7:   If the IPv6 CE router does not = acquire global IPv6

   WAA-7:   If the IPv6 CE router does = not acquire global IPv6

 

            = address(es) from either SLAAC or DHCPv6, then it MUST = create

           &= nbsp;address(es) from either SLAAC or DHCPv6, then it MUST = create

 

            = global IPv6 address(es) from its delegated prefix(es) = and

           &= nbsp;global IPv6 address(es) from its delegated prefix(es) = and

 

            = configure those on one of its internal virtual = network

           &= nbsp;configure those on one of its internal virtual = network

 

            = interfaces, unless configured to require a global = IPv6

           &= nbsp;interfaces, unless configured to require a global = IPv6

 

            = address on the WAN interface.

           &= nbsp;address on the WAN interface.

 

 

 

   WAA-8:   The CE Router MUST support the DHCPv6 SOL_MAX_RT = option

   WAA-8:   The CE Router MUST set its DHCPv6 SOL_MAX_RT parameter = to

 

            = [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received = DHCPv6

           &= nbsp;3600 by default.  When the CE Router = receives the = DHCPv6

 

            = Advertise or Reply message and set its = internal SOL_MAX_RT

           &= nbsp;SOL_MAX_RT option [I-D.droms-dhc-dhcpv6-maxsolrt-update] = in

 

            = parameter to the value contained in the SOL_MAX_RT = option.

           &= nbsp;a received DHCPv6 Advertise or Reply message it sets its

 

           &= nbsp;internal SOL_MAX_RT parameter to the value contained in = the

 

           &= nbsp;SOL_MAX_RT option.

 

 

   WAA-9:   As a router, the IPv6 CE router = MUST follow the weak host

   WAA-9:   As a router, the IPv6 CE = router MUST follow the weak host

 

            = (Weak ES) model [RFC1122].  When originating packets from = an

           &= nbsp;(Weak ES) model [RFC1122].  When originating packets from = an

 

            = interface, it will use a source address from another one = of

           &= nbsp;interface, it will use a source address from another one = of

 

            = its interfaces if the outgoing interface does not have = an

           &= nbsp;its interfaces if the outgoing interface does not have = an

 

            = address of suitable scope.

           &= nbsp;address of suitable scope.

 

 

   WAA-10:  The IPv6 CE router SHOULD implement the = Information Refresh

   WAA-10:  The IPv6 CE router SHOULD = implement the Information Refresh

 

            = Time option and associated client behavior as specified = in

           &= nbsp;Time option and associated client behavior as specified = in

 

            = [RFC4242].

           &= nbsp;[RFC4242].

 

 

 

skipping to change = at page 14, line =

28

 

skipping to change = at page 14, line =

28

 

           of = IPv4 through IPCP (i.e., over a PPP connection), it = MUST

           o= f IPv4 through IPCP (i.e., over a PPP connection), it = MUST

 

           = support user-entered configuration of 6rd.

           s= upport user-entered configuration of 6rd.

 

 

   6RD-3:  If the CE router supports configuration = mechanisms other than

   6RD-3:  If the CE router supports = configuration mechanisms other than

 

           the = 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the = CE

           t= he 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the = CE

 

           = router MUST support 6rd in "hub and spoke" mode. 6rd in = "hub

           r= outer MUST support 6rd in "hub and spoke" mode. 6rd in = "hub

 

           and = spoke" requires all IPv6 traffic to go to the 6rd = Border

           a= nd spoke" requires all IPv6 traffic to go to the 6rd = Border

 

           = Relay.  In effect, this requirement removes the = "direct

           R= elay.  In effect, this requirement removes the = "direct

 

           = connect to 6rd" route defined in Section 7.1.1 of = [RFC5969].

           c= onnect to 6rd" route defined in Section 7.1.1 of = [RFC5969].

 

 

 

   6RD-4:  Per [RFC3704], = Section 4.3, the CE router MUST send = traffic

   6RD-4:  A CE = router MUST allow 6rd and native IPv6 WAN interfaces = to

 

           using = a prefix learned via 6rd over the 6rd tunnel.

           b= e active alone as well as simultaneously in order to = support

 

           c= oexistence of the two technologies during an = incremental

 

           m= igration period such as a migration from 6rd to native IPv6.

 

 

 

   6RD-5:  The IPv6 CE router = MUST support two operational modes:

   6RD-5:  Each packet = sent on a 6rd or native WAN interface MUST = be

 

           = different prefixes on 6rd and native interfaces or identical

           d= irected such that its source IP address is derived from = the

 

           = prefixes on 6rd and native interfaces.

           d= elegated prefix associated with the upstream network the = WAN

 

           i= nterface is connected to [Section 4.3 [RFC3704]].

 

 

 

   6RD-6:  By default, the = IPv6 CE router MUST prefer a native = IPv6

   6RD-6:  The CE = router MUST allow different as well as = identical

 

           = interface over a 6rd virtual = interface.

           d= elegated prefixes to be configured via each (6rd or = native)

 

           W= AN interface.

 

 

 

   6RD-7:  The IPv6 CE router = SHOULD support independent WAN = interface

   6RD-7:  In the event = that forwarding rules produce a tie between = 6rd

 

           = configuration for 6rd and native = IPv6.

           a= nd native IPv6, by default, the IPv6 CE Router = MUST prefer

 

           n= ative IPv6.

 

 

4.4.2.  Dual-Stack Lite = (DS-Lite)

4.4.2.  Dual-Stack Lite = (DS-Lite)

 

 

   Dual-Stack Lite [RFC6333] enables both continued = support for IPv4

   Dual-Stack Lite [RFC6333] enables both continued = support for IPv4

 

   services and incentives for the deployment of = IPv6.  It also de-

   services and incentives for the deployment of = IPv6.  It also de-

 

   couples IPv6 deployment in the Service Provider = network from the rest

   couples IPv6 deployment in the Service Provider = network from the rest

 

   of the Internet, making incremental deployment = easier.  Dual-Stack

   of the Internet, making incremental deployment = easier.  Dual-Stack

 

   Lite enables a broadband service provider to share = IPv4 addresses

   Lite enables a broadband service provider to = share IPv4 addresses

 

   among customers by combining two well-known = technologies: IP in IP

   among customers by combining two well-known = technologies: IP in IP

 

   (IPv4-in-IPv6) and Network Address Translation = (NAT).  It is expected

   (IPv4-in-IPv6) and Network Address Translation = (NAT).  It is expected

 

 

 

skipping to change = at page 18, line =

5

 

skipping to change = at page 18, line =

13

 

   [RFC3646]  Droms, R., "DNS Configuration = options for Dynamic Host

   [RFC3646]  Droms, R., "DNS = Configuration options for Dynamic Host

 

           &= nbsp;  Configuration Protocol for IPv6 (DHCPv6)", RFC = 3646,

           &= nbsp;  Configuration Protocol for IPv6 (DHCPv6)", RFC = 3646,

 

           &= nbsp;  December 2003.

           &= nbsp;  December 2003.

 

 

   [RFC3704]  Baker, F. and P. Savola, = "Ingress Filtering for Multihomed

   [RFC3704]  Baker, F. and P. Savola, = "Ingress Filtering for Multihomed

 

           &= nbsp;  Networks", BCP 84, RFC 3704, March = 2004.

           &= nbsp;  Networks", BCP 84, RFC 3704, March = 2004.

 

 

   [RFC3736]  Droms, R., "Stateless Dynamic = Host Configuration Protocol

   [RFC3736]  Droms, R., "Stateless = Dynamic Host Configuration Protocol

 

           &= nbsp;  (DHCP) Service for IPv6", RFC 3736, April = 2004.

           &= nbsp;  (DHCP) Service for IPv6", RFC 3736, April = 2004.

 

 

 

   [RFC4075]  Kalusivalingam, = V., "Simple Network Time Protocol = (SNTP)

 

           &= nbsp;  Configuration Option for DHCPv6", RFC 4075, May = 2005.

 

         =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;   

 

 

   [RFC4191]  Draves, R. and D. Thaler, = "Default Router Preferences and

   [RFC4191]  Draves, R. and D. Thaler, = "Default Router Preferences and

 

           &= nbsp;  More-Specific Routes", RFC 4191, November = 2005.

           &= nbsp;  More-Specific Routes", RFC 4191, November = 2005.

 

 

   [RFC4193]  Hinden, R. and B. Haberman, = "Unique Local IPv6 Unicast

   [RFC4193]  Hinden, R. and B. Haberman, = "Unique Local IPv6 Unicast

 

           &= nbsp;  Addresses", RFC 4193, October = 2005.

          Address= es", RFC 4193, October 2005.

 

 

   [RFC4242]  Venaas, S., Chown, T., and B. Volz, = "Information Refresh

   [RFC4242]  Venaas, S., Chown, T., and B. = Volz, "Information Refresh

 

           &= nbsp;  Time Option for Dynamic Host Configuration Protocol = for

           &= nbsp;  Time Option for Dynamic Host Configuration Protocol = for

 

           &= nbsp;  IPv6 (DHCPv6)", RFC 4242, November = 2005.

           &= nbsp;  IPv6 (DHCPv6)", RFC 4242, November = 2005.

 

 

 

 

skipping to change = at page 18, line =

49

 

skipping to change = at page 19, line =

6

 

   [RFC4862]  Thomson, S., Narten, T., and T. = Jinmei, "IPv6 Stateless

   [RFC4862]  Thomson, S., Narten, T., and T. = Jinmei, "IPv6 Stateless

 

           &= nbsp;  Address Autoconfiguration", RFC 4862, September = 2007.

           &= nbsp;  Address Autoconfiguration", RFC 4862, September = 2007.

 

 

   [RFC4864]  Van de Velde, G., Hain, T., Droms, = R., Carpenter, B., and

   [RFC4864]  Van de Velde, G., Hain, T., = Droms, R., Carpenter, B., and

 

           &= nbsp;  E. Klein, "Local Network Protection for IPv6", RFC = 4864,

           &= nbsp;  E. Klein, "Local Network Protection for = IPv6", RFC 4864,

 

           &= nbsp;  May 2007.

           &= nbsp;  May 2007.

 

 

   [RFC5072]  S.Varada, Haskins, D., and E. Allen, = "IP Version 6 over

   [RFC5072]  S.Varada, Haskins, D., and E. = Allen, "IP Version 6 over

 

           &= nbsp;  PPP", RFC 5072, September = 2007.

           &= nbsp;  PPP", RFC 5072, September = 2007.

 

 

 

   [RFC5905]  Mills, D., = Martin, J., Burbank, J., and W. Kasch, = "Network

 

           &= nbsp;  Time Protocol Version 4: Protocol and = Algorithms

 

           &= nbsp;  Specification", RFC 5905, June = 2010.

 

 

   [RFC5908]  Gayraud, R. and B. Lourdelet, = "Network Time Protocol (NTP)

 

           &= nbsp;  Server Option for DHCPv6", RFC 5908, June = 2010.

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  

 

   [RFC5942]  Singh, H., Beebee, W., and E. = Nordmark, "IPv6 Subnet

   [RFC5942]  Singh, H., Beebee, W., and E. = Nordmark, "IPv6 Subnet

 

           &= nbsp;  Model: The Relationship between Links and = Subnet

           &= nbsp;  Model: The Relationship between Links and = Subnet

 

           &= nbsp;  Prefixes", RFC 5942, July = 2010.

           &= nbsp;  Prefixes", RFC 5942, July = 2010.

 

 

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 = Rapid Deployment on IPv4

   [RFC5969]  Townsley, W. and O. Troan, = "IPv6 Rapid Deployment on IPv4

 

           &= nbsp;  Infrastructures (6rd) -- Protocol = Specification",

           &= nbsp;  Infrastructures (6rd) -- Protocol = Specification",

 

           &= nbsp;  RFC 5969, August 2010.

           &= nbsp;  RFC 5969, August 2010.

 

 

   [RFC6092]  Woodyatt, J., "Recommended = Simple Security Capabilities in

   [RFC6092]  Woodyatt, J., "Recommended = Simple Security Capabilities in

 

           &= nbsp;  Customer Premises Equipment (CPE) for = Providing

           &= nbsp;  Customer Premises Equipment (CPE) for = Providing

 

 

 

 End of = changes. 14 change

blocks. 

 

29 lines changed or = deleted

 

40 lines changed or = added

 


This html diff = was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/t= ools/rfcdiff/

 

------_=_NextPart_001_01CD2ED1.B6DC3097-- From marka@isc.org Thu May 10 17:06:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6679E21F85E7 for ; Thu, 10 May 2012 17:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtkKyy3KG27e for ; Thu, 10 May 2012 17:06:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 82E7321F85D9 for ; Thu, 10 May 2012 17:06:49 -0700 (PDT) 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 id 43617C979B; Fri, 11 May 2012 00:06:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d1b6:e92a:d0d:792c]) (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 00E0F216C3B; Fri, 11 May 2012 00:06: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 AB60A2096353; Fri, 11 May 2012 10:06:24 +1000 (EST) To: "Dan Wing" From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6110C1604@GAALPA1MSGUSR9N.ITServices.sbc.com> <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> In-reply-to: Your message of "Thu, 10 May 2012 10:24:16 MST." <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> Date: Fri, 11 May 2012 10:06:24 +1000 Message-Id: <20120511000624.AB60A2096353@drugs.dv.isc.org> Cc: 'IPv6 Operations' Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 00:06:50 -0000 In message <0a9701cd2ed1$ba0932e0$2e1b98a0$@com>, "Dan Wing" writes: > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > > Of Chris Donley > > Sent: Tuesday, May 08, 2012 2:18 PM > > To: STARK, BARBARA H; Ole Tr=F8an; Hans Liu > > Cc: IPv6 Operations > > Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) > > > > > Our testing shows that NAT444 offers a better user experience than DS- > > Lite (due in part to MTU issues). > > > On the MTU issue, Dual-Stack Lite suggests that ISPs deploy larger > MTU between the subscriber's B4 and the AFTR element. The same > paragraph admits this may not always be feasible. > http://tools.ietf.org/html/rfc6333#section-5.3 > > I assume, without knowing for sure, that your testing did not > follow RFC6333's recommendation to use a larger MTU over that > path. > > > The industry has long experience with PPPoE, which also has a > shorter MTU, and causes various problems. The problems are > generally resolved by CPE routers that rewrite the MSS > option of outgoing TCP SYNs. However, such MSS option rewriting > is frowned upon by many technologists as a layering violation > and thus is not mentioned in RFC6333. However, it is effective > at reducing round trips for servers to discover the smaller MTU > (where ICMP packet too big succeeds) and avoids the delays > > of PMTUD blackhole discovery (when ICMP packet too big fails). > > I assume, without knowing for sure, that your testing did not > include TCP MSS rewriting. > > -d I hate to say it but we need MTU pain now with IPv4. With PMTUD on by default for everything in IPv6 we need to get rid of this mindset that one can filter out ICMP{v6} messages and have a working connection. Do we really want every router with mismatching next hop MTUs looking at every SYN packet and deciding if it needs to trim MSS? That is the way it is heading if we don't stop this ICMP{v6} filtering idiocy. > > Customer hat on - I would strongly prefer > > native IPv4 to DS-Lite, even if that native v4 address were behind a > > CGN. > > > > > > > > Chris > > > > > > > > > > On 5/8/12 7:16 AM, "STARK, BARBARA H" wrote: > > > > >> do we all agree that for IPv4, a CPE should prefer a DS-lite > > connection > > >>over a > > >> native one? > > > > > >Is the native one giving me a CGN NATted IPv4 address, or a public > > IPv4 > > >address? I think I would prefer public IPv4 over DS-Lite over CGN. > > >Barbara -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Thu May 10 18:03:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6DA21F859F for ; Thu, 10 May 2012 18:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.388 X-Spam-Level: X-Spam-Status: No, score=-110.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzEVjRQCEHa4 for ; Thu, 10 May 2012 18:03:19 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C51EA21F8596 for ; Thu, 10 May 2012 18:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=522; q=dns/txt; s=iport; t=1336698199; x=1337907799; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=uUEfOaNKUd7L5B3X0ialXsJnm0qXts0gkRksRC4Mkl0=; b=iPV6kGbbk01zx8ePbZ2D7XBIk9VLlTLQVm4tlwvfIm7a9c+z8UySWkSA IZRjFnLiIlztm3JN4EoZ0Ms89awRCApBCne9nenayk4JMNajz5HaLV9DU 0i1k8E8Oo0VzMbhyAdEAK4gjmOj3gBgtvXmTUYGK/AoPgnfkzcOSLRTey I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHFkrE+rRDoH/2dsb2JhbABEoyKQfYEHghUBAQEDAQgKARdPBQgDAgkPNxkjGwEBBB4Xh2cEmzGgLJEvBIgwNIUWllqBaYMJ X-IronPort-AV: E=Sophos;i="4.75,567,1330905600"; d="scan'208";a="41236812" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 11 May 2012 01:03:18 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4B13HAG017876; Fri, 11 May 2012 01:03:17 GMT From: "Dan Wing" To: "'Mark Andrews'" References: <2D09D61DDFA73D4C884805CC7865E6110C1604@GAALPA1MSGUSR9N.ITServices.sbc.com> <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> <20120511000624.AB60A2096353@drugs.dv.isc.org> In-Reply-To: <20120511000624.AB60A2096353@drugs.dv.isc.org> Date: Thu, 10 May 2012 18:03:17 -0700 Message-ID: <0cc601cd2f11$d9cb9600$8d62c200$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0vCfQXTM5oa8C9RPu7z0+tUPapzAAB6WvA Content-Language: en-us Cc: 'IPv6 Operations' Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 01:03:20 -0000 > I hate to say it but we need MTU pain now with IPv4. With PMTUD > on by default for everything in IPv6 we need to get rid of this > mindset that one can filter out ICMP{v6} messages and have a working > connection. Do we really want every router with mismatching next > hop MTUs looking at every SYN packet and deciding if it needs to > trim MSS? That is the way it is heading if we don't stop this > ICMP{v6} filtering idiocy. A science fiction writer said the answer is 42, but the answer is 1280. -d From marka@isc.org Thu May 10 19:48:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456E921F8474 for ; Thu, 10 May 2012 19:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdzKlz3u5C6s for ; Thu, 10 May 2012 19:48:29 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A84F721F8473 for ; Thu, 10 May 2012 19:48:29 -0700 (PDT) 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 id 0CD2FC9699; Fri, 11 May 2012 02:48:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d1b6:e92a:d0d:792c]) (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 BB21C216C33; Fri, 11 May 2012 02:48:16 +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 DAA9C2097AD9; Fri, 11 May 2012 12:48:14 +1000 (EST) To: "Dan Wing" From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6110C1604@GAALPA1MSGUSR9N.ITServices.sbc.com> <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> <20120511000624.AB60A2096353@drugs.dv.isc.org> <0cc601cd2f11$d9cb9600$8d62c200$@com> In-reply-to: Your message of "Thu, 10 May 2012 18:03:17 MST." <0cc601cd2f11$d9cb9600$8d62c200$@com> Date: Fri, 11 May 2012 12:48:14 +1000 Message-Id: <20120511024814.DAA9C2097AD9@drugs.dv.isc.org> Cc: 'IPv6 Operations' Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 02:48:30 -0000 In message <0cc601cd2f11$d9cb9600$8d62c200$@com>, "Dan Wing" writes: > > I hate to say it but we need MTU pain now with IPv4. With PMTUD > > on by default for everything in IPv6 we need to get rid of this > > mindset that one can filter out ICMP{v6} messages and have a working > > connection. Do we really want every router with mismatching next > > hop MTUs looking at every SYN packet and deciding if it needs to > > trim MSS? That is the way it is heading if we don't stop this > > ICMP{v6} filtering idiocy. > > A science fiction writer said the answer is 42, but the answer > is 1280. > > -d And RFC 4821 support for at least TCP. RFC 4821 - Don't get IPv6 without it! -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ichiroumakino@gmail.com Fri May 11 00:27:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9AD21F8497; Fri, 11 May 2012 00:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8+05ajpCm0O; Fri, 11 May 2012 00:27:46 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 904A821F847E; Fri, 11 May 2012 00:27:45 -0700 (PDT) Received: by wibhr2 with SMTP id hr2so1148223wib.13 for ; Fri, 11 May 2012 00:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=H+XQjcRqizkOD6Pbt6bbTfTFJ1sgSEzeQqoiWSLkJWY=; b=GGOPPgH//jypxBDj11EsPBR6aq8y1hto+pOnQrjQbqbTpxCYekM6KOYyP9nHRJB7Om Ap8PJLoxgTKynJpSMp3L2JS0W09F/YAQAXpk2E0ye+NQUQqnASFzb1wAgo87don8jGQx ojJ9J3wxiv1VuSWLfwtlL5a4K982OnnhaJ4YHReO6vbDNVJOTxvtHQyhGP9kaVR2DtS1 fE4H/KtZRn9JymBvdOt8Y1KNt70bJ2cL7L3sS34uDzzbJ8QG77vhmtwgWsjWWsI5DjrJ K7+phOxl+kaUTybGWf3LhdnR7w7PAFvcStlk4aDPWoYV0DTTPn3CzmxPduaVgBqYDyiu YLzg== Received: by 10.216.139.73 with SMTP id b51mr803060wej.72.1336721263312; Fri, 11 May 2012 00:27:43 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm8793392wib.2.2012.05.11.00.27.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 00:27:42 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <20120507032857.32055.91989.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 09:27:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120507032857.32055.91989.idtracker@ietfa.amsl.com> To: dhc WG X-Mailer: Apple Mail (2.1257) Cc: v6ops WG Subject: Re: [v6ops] [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 11 May 2012 07:27:47 -0000 All, greatly appreciated if you could give this a once-over. it is meant to = fix the issues identified by the RFC6204 effort in v6ops, and be the = basis for 3315bis. cheers, Ole On May 7, 2012, at 5:28 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Dynamic Host Configuration = Working Group of the IETF. >=20 > Title : Issues with multiple stateful DHCPv6 options > Author(s) : Ole Troan > Bernie Volz > Filename : draft-ietf-dhc-dhcpv6-stateful-issues-00.txt > Pages : 8 > Date : 2012-05-06 >=20 > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not = written > with the expectation that additional stateful DHCPv6 options would = be > developed. IPv6 Prefix Options for Dynamic Host Configuration > Protocol (DHCP) version 6 shoe-horned the new options for Prefix > Delegation into DHCPv6. Implementation experience of the CPE model > described in has shown multiple issues with the DHCPv6 protocol in > supporting multiple stateful options. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-= 00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-0= 0.txt >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From joelja@bogus.com Fri May 11 03:50:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36B21F85E5 for ; Fri, 11 May 2012 03:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJxZ8q-KxDtO for ; Fri, 11 May 2012 03:50:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AC31121F8570 for ; Fri, 11 May 2012 03:50:18 -0700 (PDT) Received: from wifi-208-85.mtg.afnog.org (wifi-208-85.mtg.afnog.org [196.200.208.85]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q4BAo4Eb027459 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 11 May 2012 10:50:15 GMT (envelope-from joelja@bogus.com) Message-ID: <4FACEED9.6030002@bogus.com> Date: Fri, 11 May 2012 10:50:01 +0000 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 11 May 2012 10:50:18 +0000 (UTC) Subject: [v6ops] The IETF potential large interim following RIPE 65 e.g. Sept 28 and later. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 10:50:19 -0000 we had a show of hands during the paris meeting to guage potential interest on the basis of workload on the possibility of an interim v6ops wg meeting. while there was some interest it's time to flesh that out in more detail. Can we get a headcount of people would would be receptive to the idea of an interim scheduled to coincide with the end of Ripe 65 (which is Amsterdam this time sept 24-28). Some indication of an ability to participate remotely vs in person would also be helpful. While we can't forecast exactly which documents will be in the critical still path after Vancouver, I have a pretty good idea which one's we want to done with by then. Thanks joel From warren@kumari.net Fri May 11 06:45:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F9221F85FF for ; Fri, 11 May 2012 06:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.682 X-Spam-Level: X-Spam-Status: No, score=-105.682 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNnfCFHsL7-H for ; Fri, 11 May 2012 06:45:27 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2D521F85D5 for ; Fri, 11 May 2012 06:45:27 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4805E1B40098; Fri, 11 May 2012 09:45:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4FACEED9.6030002@bogus.com> Date: Fri, 11 May 2012 09:45:24 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4FACEED9.6030002@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG , V6ops Chairs Subject: Re: [v6ops] The IETF potential large interim following RIPE 65 e.g. Sept 28 and later. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 13:45:28 -0000 On May 11, 2012, at 6:50 AM, Joel jaeggli wrote: > we had a show of hands during the paris meeting to guage potential > interest on the basis of workload on the possibility of an interim v6ops > wg meeting. while there was some interest it's time to flesh that out in > more detail. > > Can we get a headcount of people would would be receptive to the idea of > an interim scheduled to coincide with the end of Ripe 65 (which is > Amsterdam this time sept 24-28). Some indication of an ability to > participate remotely vs in person would also be helpful. I'll attend, in person... W > > While we can't forecast exactly which documents will be in the critical > still path after Vancouver, I have a pretty good idea which one's we > want to done with by then. > > Thanks > joel > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nick@inex.ie Fri May 11 06:49:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E5C21F860B for ; Fri, 11 May 2012 06:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqts2Fv7e1A5 for ; Fri, 11 May 2012 06:49:34 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5768621F85D5 for ; Fri, 11 May 2012 06:49:34 -0700 (PDT) X-Envelope-To: Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q4BDn0sg090215 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 11 May 2012 14:49:00 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FAD18EB.9090700@inex.ie> Date: Fri, 11 May 2012 14:49:31 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FACEED9.6030002@bogus.com> In-Reply-To: <4FACEED9.6030002@bogus.com> X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] The IETF potential large interim following RIPE 65 e.g. Sept 28 and later. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 13:49:43 -0000 On 11/05/2012 11:50, Joel jaeggli wrote: > Can we get a headcount of people would would be receptive to the idea of > an interim scheduled to coincide with the end of Ripe 65 (which is > Amsterdam this time sept 24-28). Some indication of an ability to > participate remotely vs in person would also be helpful. I will probably attend this. Nick From C.Donley@cablelabs.com Fri May 11 07:19:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A0221F8541 for ; Fri, 11 May 2012 07:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAUS7cxjbR+r for ; Fri, 11 May 2012 07:19:34 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1D15B21F8532 for ; Fri, 11 May 2012 07:19:34 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q4BEJTnT015140; Fri, 11 May 2012 08:19:29 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 11 May 2012 08:19:29 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 11 May 2012 08:19:29 -0600 From: Chris Donley To: Dan Wing , "'STARK, BARBARA H'" , =?iso-8859-1?Q?=27Ole_Tr=F8an=27?= , "'Hans Liu'" Date: Fri, 11 May 2012 08:19:26 -0600 Thread-Topic: DS-Lite worse than native IPv4 [was RE: [v6ops] 6rd sunsetting requirements (version 3)] Thread-Index: Ac0vgRMc6fW/MunkQc+jgjScr/27rQ== Message-ID: In-Reply-To: <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: 'IPv6 Operations' Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 14:19:34 -0000 We did our testing on a DOCSIS network, which allows 1522 byte frames. We did not enable MSS rewriting. Chris On 5/10/12 11:24 AM, "Dan Wing" wrote: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Chris Donley >> Sent: Tuesday, May 08, 2012 2:18 PM >> To: STARK, BARBARA H; Ole Tr=F8an; Hans Liu >> Cc: IPv6 Operations >> Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) >>=20 >> Our testing shows that NAT444 offers a better user experience than DS- >> Lite (due in part to MTU issues). > >On the MTU issue, Dual-Stack Lite suggests that ISPs deploy larger >MTU between the subscriber's B4 and the AFTR element. The same >paragraph admits this may not always be feasible. >http://tools.ietf.org/html/rfc6333#section-5.3 > >I assume, without knowing for sure, that your testing did not >follow RFC6333's recommendation to use a larger MTU over that >path. > > >The industry has long experience with PPPoE, which also has a >shorter MTU, and causes various problems. The problems are >generally resolved by CPE routers that rewrite the MSS >option of outgoing TCP SYNs. However, such MSS option rewriting >is frowned upon by many technologists as a layering violation >and thus is not mentioned in RFC6333. However, it is effective >at reducing round trips for servers to discover the smaller MTU >(where ICMP packet too big succeeds) and avoids the delays >of PMTUD blackhole discovery (when ICMP packet too big fails). > >I assume, without knowing for sure, that your testing did not >include TCP MSS rewriting. > >-d > >> Customer hat on - I would strongly prefer >> native IPv4 to DS-Lite, even if that native v4 address were behind a >> CGN. >>=20 >>=20 >> Chris >>=20 >>=20 >>=20 >>=20 >> On 5/8/12 7:16 AM, "STARK, BARBARA H" wrote: >>=20 >> >> do we all agree that for IPv4, a CPE should prefer a DS-lite >> connection >> >>over a >> >> native one? >> > >> >Is the native one giving me a CGN NATted IPv4 address, or a public >> IPv4 >> >address? I think I would prefer public IPv4 over DS-Lite over CGN. >> >Barbara >> >_______________________________________________ >> >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 cb.list6@gmail.com Fri May 11 08:22:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E474C21F86B0 for ; Fri, 11 May 2012 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYq05pIPEalJ for ; Fri, 11 May 2012 08:22:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1241C21F865B for ; Fri, 11 May 2012 08:22:09 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3585770pbc.31 for ; Fri, 11 May 2012 08:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hTYNgTRZVDAr0/pxXZcCzpT2YdXTTh4IyYGvQP0fd+Q=; b=XBjMd9fgjPcHHetwhBEzmIKRJpAa9GWmyKKkN6zYeE5IR01fNYHPmYwgfWak+rQXhf cGWcqMAqoiL+a2e8BnSPRLGpCx1YQtsrs6F+aodXuGn2bNvdIlJS0tK9XwwNtGy2bxPm QwmENGlx/7pFdZqPkexM1fQeGc+zTfZULuLW3PtYMNlNF7eDyHp035OWRprXlnYisN12 oaIS+YoKJEHX53tQpDlppmQjAa6jBcwevThLf4cKX/JInRCv7X6UC1SKLdYbTakMZZ2S XFimGFz/yTK1sArLU5/wL5ZxNd9P80VbrMnkjanTQyI8cQSFhGw1dKxfzTjj2VafN4dr /F3w== MIME-Version: 1.0 Received: by 10.68.189.9 with SMTP id ge9mr12215662pbc.127.1336749728888; Fri, 11 May 2012 08:22:08 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Fri, 11 May 2012 08:22:08 -0700 (PDT) In-Reply-To: References: <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> Date: Fri, 11 May 2012 08:22:08 -0700 Message-ID: From: Cameron Byrne To: Chris Donley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 15:22:10 -0000 On Fri, May 11, 2012 at 7:19 AM, Chris Donley wrot= e: > We did our testing on a DOCSIS network, which allows 1522 byte frames. = =A0We > did not enable MSS rewriting. > If this issue is systemic for DOCSIS, and MSS rewrite is a known and common solution, should 6204bis include language about MSS rewrite? From shemant@cisco.com Fri May 11 08:58:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01EF21F8666 for ; Fri, 11 May 2012 08:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LimGMM2urSBL for ; Fri, 11 May 2012 08:58:57 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 131E221F865F for ; Fri, 11 May 2012 08:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4925; q=dns/txt; s=iport; t=1336751937; x=1337961537; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=xfOBq8cNR/Pu2gR5IPdTHpyWlUxgRb5BC7bGfVczsgc=; b=iruv+n4hUeGNPmaqWzyQY0MOh9iLDFd1ICrQn5lKbfevx1relw1F5lre DU2yEI6Gwll5I66LfFX0PyCY+N4yDnNDZXwzKTw4dXYBUtwnS45XhpxoV OnV4MGG/zI0TiMvvWbSxBIPy11Ksk6V3SgpjqKIymiYRxTefDRVQTn6Vt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPI1rU+rRDoG/2dsb2JhbABEgkaxX4EHghUBAQEEEgEJEQNJDAQCAQgOAwQBAQsGFwEGASAlCQgBAQQBEggTB4deAwoBmxiWFA2JU4opboU6YwSIMDSYVoMagWmDBw X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208,217";a="44335879" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 11 May 2012 15:58:56 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4BFwuRW031535; Fri, 11 May 2012 15:58:56 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 May 2012 10:58:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2F8E.F7F26FDA" Date: Fri, 11 May 2012 10:58:55 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A017A3@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] Thread-Index: Ac0vietuxKx78L45QfKG/bmx4w5VQQABJXow References: <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> From: "Hemant Singh (shemant)" To: "Cameron Byrne" , "Chris Donley" X-OriginalArrivalTime: 11 May 2012 15:58:56.0070 (UTC) FILETIME=[F8444E60:01CD2F8E] Cc: IPv6 Operations , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 15:58:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2F8E.F7F26FDA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 Sent: Friday, May 11, 2012 11:22 AM To: Chris Donley Cc: Dan Wing (dwing); STARK, BARBARA H; Ole Tr=F8an; Hans Liu; IPv6 = Operations; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd = sunsetting requirements (version 3)] =20 =20 >If this issue is systemic for DOCSIS, and MSS rewrite is a known and >common solution, should 6204bis include language about MSS rewrite? =20 The DS-Lite RFC in RFC 6333 already did not include the MSS rewrite = because the rewrite is considered a hack due to a layer violation (as = also mentioned by Dan Wing) for this thread. Thus if RFC 6333 does not = mention the MSS rewrite, rfc6204bis should not either. =20 Hemant ------_=_NextPart_001_01CD2F8E.F7F26FDA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: Cameron Byrne = [mailto:cb.list6@gmail.com]
Sent: Friday, May 11, 2012 11:22 = AM
To: Chris Donley
Cc: Dan Wing (dwing); STARK, BARBARA H; Ole = Tr=F8an; Hans Liu; IPv6 Operations; = draft-ietf-v6ops-6204bis@tools.ietf.org
Subject: Re: [v6ops] DS-Lite = worse than native IPv4 [was RE: 6rd sunsetting requirements (version = 3)]

 

 

>If this issue is systemic for = DOCSIS, and MSS rewrite is a known and

>common solution, should 6204bis include language about MSS = rewrite?

 

The DS-Lite RFC in RFC 6333 already did not include = the MSS rewrite because the rewrite is considered a hack due to a layer = violation (as also mentioned by Dan Wing) for this thread.=A0 Thus if = RFC 6333 does not mention the MSS rewrite, rfc6204bis should not = either.

 

Hemant

------_=_NextPart_001_01CD2F8E.F7F26FDA-- From cb.list6@gmail.com Fri May 11 09:08:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBA821F8647 for ; Fri, 11 May 2012 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI6tUYCTpS0d for ; Fri, 11 May 2012 09:08:46 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 033CB21F8638 for ; Fri, 11 May 2012 09:08:45 -0700 (PDT) Received: by dacx6 with SMTP id x6so3449698dac.31 for ; Fri, 11 May 2012 09:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pu1xs6bJ8nxaHZDrNFbLnTEkkqTuZt7BjYhMKIJK9QM=; b=jQER5H1vKmDV+8P80n6KFL1wY9XyCYLFICmXZ82IC+3RYy2uRJsx6aY3nwij2PD23q bbmczmrO512Aaoe9k1pIVETAfrWHt8+gBTsVxSOxovAmm1XAUq/mmO0sIfvOeTejrpVq AedbPBFjJHDHmvpub6HU09NklRWcqN27FL2uQUkNBoKUo+Ux8ZOIV+B+IUUrFtaVr8rn LPVfySclOBfKmT1COalGdIfVDtlJzxf/ZURfLo5IoxoEKDQp4XI7ku6SvMqdup8zjx6u +JUHg5nGJOPHePN1kQqwW+xj9n8dk86vtXDmXxhcM1fB+l0HtivEKNdcIEj9pqkmJpux Cdyg== MIME-Version: 1.0 Received: by 10.68.129.42 with SMTP id nt10mr32382175pbb.164.1336752525611; Fri, 11 May 2012 09:08:45 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Fri, 11 May 2012 09:08:45 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A017A3@XMB-RCD-109.cisco.com> References: <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A017A3@XMB-RCD-109.cisco.com> Date: Fri, 11 May 2012 09:08:45 -0700 Message-ID: From: Cameron Byrne To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 16:08:46 -0000 On Fri, May 11, 2012 at 8:58 AM, Hemant Singh (shemant) wrote: > > > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Friday, May 11, 2012 11:22 AM > To: Chris Donley > Cc: Dan Wing (dwing); STARK, BARBARA H; Ole Tr=F8an; Hans Liu; IPv6 > Operations; draft-ietf-v6ops-6204bis@tools.ietf.org > Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetti= ng > requirements (version 3)] > > > > > >>If this issue is systemic for DOCSIS, and MSS rewrite is a known and > >>common solution, should 6204bis include language about MSS rewrite? > > > > The DS-Lite RFC in RFC 6333 already did not include the MSS rewrite becau= se > the rewrite is considered a hack due to a layer violation (as also mentio= ned > by Dan Wing) for this thread.=A0 Thus if RFC 6333 does not mention the MS= S > rewrite, rfc6204bis should not either. > > > > Hemant Neither of those documents are v6ops, and they do not need to serve the operator community in the same way v6ops does. 6204bis is a v6ops document. So, if MSS rewrite is required to "operationalize" DS-lite, perhaps it should be added. No? CB From dwing@cisco.com Fri May 11 10:26:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4B221F8675 for ; Fri, 11 May 2012 10:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.955 X-Spam-Level: X-Spam-Status: No, score=-109.955 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM6aEe8WFcic for ; Fri, 11 May 2012 10:26:15 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFBE21F8647 for ; Fri, 11 May 2012 10:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3067; q=dns/txt; s=iport; t=1336757175; x=1337966775; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=AyC0XkTOLwqyeVAag0smz/Df4LsJUCW4R1eN7TWKlJs=; b=PnZhz0gGs3FURCIpARbaAPxk3tNM1W+J53M0mLz+kq2B13NeC+HUQHnu v4gIzBZW/+69cmVDstzToHmxjiwtbgvTpfrP3cyjouDaWW145+kI4xfWH rvU7/kpaNClqgx+GrAb+r5UnOD2xLwxcVNVnuuKaSb4uoI41SAVB7MkjP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF5KrU+rRDoG/2dsb2JhbABEoy6QNIEHghUBAQEDAQEBAQUKARdECwwBAwIJDgECBAEBAScHGQ4VCgkIAQEEARILF4dnBAybKp92ixeGHQSIMDSFFokUjUaBaYMJ X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="41326075" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 11 May 2012 17:26:15 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4BHQEZI006396; Fri, 11 May 2012 17:26:14 GMT From: "Dan Wing" To: "'Chris Donley'" , "'STARK, BARBARA H'" , "=?iso-8859-1?Q?'Ole_Tr=F8an'?=" , "'Hans Liu'" References: <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> In-Reply-To: Date: Fri, 11 May 2012 10:26:14 -0700 Message-ID: <0ef201cd2f9b$2acbd450$80637cf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0vgRMc6fW/MunkQc+jgjScr/27rQAEKdxQ Content-Language: en-us Cc: 'IPv6 Operations' Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 17:26:16 -0000 > -----Original Message----- > From: Chris Donley [mailto:C.Donley@cablelabs.com] > Sent: Friday, May 11, 2012 7:19 AM > To: Dan Wing; 'STARK, BARBARA H'; 'Ole Tr=F8an'; 'Hans Liu' > Cc: 'IPv6 Operations' > Subject: Re: DS-Lite worse than native IPv4 [was RE: [v6ops] 6rd > sunsetting requirements (version 3)] >=20 > We did our testing on a DOCSIS network, which allows 1522 byte frames. > We did not enable MSS rewriting. Thanks. That certainly explains why the user experience suffered. -d >=20 >=20 > Chris >=20 >=20 >=20 >=20 > On 5/10/12 11:24 AM, "Dan Wing" wrote: >=20 > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > >> Of Chris Donley > >> Sent: Tuesday, May 08, 2012 2:18 PM > >> To: STARK, BARBARA H; Ole Tr=F8an; Hans Liu > >> Cc: IPv6 Operations > >> Subject: Re: [v6ops] 6rd sunsetting requirements (version 3) > >> > >> Our testing shows that NAT444 offers a better user experience than > DS- > >> Lite (due in part to MTU issues). > > > >On the MTU issue, Dual-Stack Lite suggests that ISPs deploy larger > >MTU between the subscriber's B4 and the AFTR element. The same > >paragraph admits this may not always be feasible. > >http://tools.ietf.org/html/rfc6333#section-5.3 > > > >I assume, without knowing for sure, that your testing did not > >follow RFC6333's recommendation to use a larger MTU over that > >path. > > > > > >The industry has long experience with PPPoE, which also has a > >shorter MTU, and causes various problems. The problems are > >generally resolved by CPE routers that rewrite the MSS > >option of outgoing TCP SYNs. However, such MSS option rewriting > >is frowned upon by many technologists as a layering violation > >and thus is not mentioned in RFC6333. However, it is effective > >at reducing round trips for servers to discover the smaller MTU > >(where ICMP packet too big succeeds) and avoids the delays > >of PMTUD blackhole discovery (when ICMP packet too big fails). > > > >I assume, without knowing for sure, that your testing did not > >include TCP MSS rewriting. > > > >-d > > > >> Customer hat on - I would strongly prefer > >> native IPv4 to DS-Lite, even if that native v4 address were behind = a > >> CGN. > >> > >> > >> Chris > >> > >> > >> > >> > >> On 5/8/12 7:16 AM, "STARK, BARBARA H" wrote: > >> > >> >> do we all agree that for IPv4, a CPE should prefer a DS-lite > >> connection > >> >>over a > >> >> native one? > >> > > >> >Is the native one giving me a CGN NATted IPv4 address, or a public > >> IPv4 > >> >address? I think I would prefer public IPv4 over DS-Lite over CGN. > >> >Barbara > >> >_______________________________________________ > >> >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 dr@cluenet.de Fri May 11 10:34:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F7C21F8675 for ; Fri, 11 May 2012 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqW0ypwryl8i for ; Fri, 11 May 2012 10:34:04 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7B30721F8604 for ; Fri, 11 May 2012 10:34:04 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 776A310842C; Fri, 11 May 2012 19:34:03 +0200 (CEST) Date: Fri, 11 May 2012 19:34:03 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120511173403.GA13896@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> <0ef201cd2f9b$2acbd450$80637cf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ef201cd2f9b$2acbd450$80637cf0$@com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 17:34:05 -0000 On Fri, May 11, 2012 at 10:26:14AM -0700, Dan Wing wrote: > > We did our testing on a DOCSIS network, which allows 1522 byte frames. > > We did not enable MSS rewriting. > > Thanks. That certainly explains why the user experience suffered. And at the same time is a completely unrealistic testing scenario for today's Internet. Just as fragmenting the tunnel instead of the payload, but that's another story. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From internet-drafts@ietf.org Fri May 11 11:30:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA1921F86D8; Fri, 11 May 2012 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x8OV5iQ0MaT; Fri, 11 May 2012 11:30:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EE621F8624; Fri, 11 May 2012 11:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120511183001.26924.33901.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 11:30:01 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-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, 11 May 2012 18:30:01 -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 : Implementation Advice for IPv6 Router Advertisement Guar= d (RA-Guard) Author(s) : Fernando Gont Filename : draft-ietf-v6ops-ra-guard-implementation-03.txt Pages : 18 Date : 2012-05-11 The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and provides advice on the implementation of RA-Guard, such that the RA-Guard evasion vectors are eliminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementatio= n-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation= -03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ From fgont@si6networks.com Fri May 11 12:00:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907D921F8749 for ; Fri, 11 May 2012 12:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_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 Mc0GdnF0LD+h for ; Fri, 11 May 2012 12:00:32 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5421F8723 for ; Fri, 11 May 2012 12:00:31 -0700 (PDT) Received: from [24.114.252.237] (helo=[192.168.16.183]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SSv4U-0004nt-Ns; Fri, 11 May 2012 21:00:11 +0200 Message-ID: <4FAD61B4.2000301@si6networks.com> Date: Fri, 11 May 2012 16:00:04 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: 'james woodyatt' , Nick Hilliard , "Bjoern A. Zeeb" References: <20120511183001.26924.33901.idtracker@ietfa.amsl.com> In-Reply-To: <20120511183001.26924.33901.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-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, 11 May 2012 19:00:57 -0000 Folks (Bjoern, James & Nick), COuld youuuble-check/confirm that this version addresses the issues you raised during the WGLC? Thanks! Best regards, Fernando On 05/11/2012 03:30 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the IPv6 Operations Working > Group of the IETF. > > Title : Implementation Advice for IPv6 Router Advertisement > Guard (RA-Guard) Author(s) : Fernando Gont Filename : > draft-ietf-v6ops-ra-guard-implementation-03.txt Pages : 18 > Date : 2012-05-11 > > The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly > employed to mitigate attack vectors based on forged ICMPv6 Router > Advertisement messages. Many existing IPv6 deployments rely on RA- > Guard as the first line of defense against the aforementioned attack > vectors. However, some implementations of RA-Guard have been found > to be prone to circumvention by employing IPv6 Extension Headers. > This document describes the evasion techniques that affect the > aforementioned implementations, and provides advice on the > implementation of RA-Guard, such that the RA-Guard evasion vectors > are eliminated. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-03.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From C.Donley@cablelabs.com Fri May 11 15:47:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A436321F8464 for ; Fri, 11 May 2012 15:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ddk39eOd8yU for ; Fri, 11 May 2012 15:47:36 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3D47E21F8463 for ; Fri, 11 May 2012 15:47:36 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q4BMlTbm011521; Fri, 11 May 2012 16:47:31 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 11 May 2012 16:47:29 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 11 May 2012 16:45:57 -0600 From: Chris Donley To: Cameron Byrne Date: Fri, 11 May 2012 16:45:54 -0600 Thread-Topic: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] Thread-Index: Ac0vx9TaBUswzVNsQ2Wx98CRts43ZQ== 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.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: IPv6 Operations , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 22:47:36 -0000 I don't support MSS rewrite language in 6204bis. Most of our members are considering solutions other than DS-Lite. I suggest that those who are planning DS-Lite deployments talk with their vendors if they think they need MSS rewrite support. Chris On 5/11/12 9:22 AM, "Cameron Byrne" wrote: >On Fri, May 11, 2012 at 7:19 AM, Chris Donley >wrote: >> We did our testing on a DOCSIS network, which allows 1522 byte frames. >>We >> did not enable MSS rewriting. >> > >If this issue is systemic for DOCSIS, and MSS rewrite is a known and >common solution, should 6204bis include language about MSS rewrite? From randy@psg.com Fri May 11 16:35:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E3C21F8517 for ; Fri, 11 May 2012 16:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4h4mlPMUrdz for ; Fri, 11 May 2012 16:35:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6F37521F84FF for ; Fri, 11 May 2012 16:35:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SSzMU-000PfP-3m; Fri, 11 May 2012 23:35:02 +0000 Date: Fri, 11 May 2012 13:35:01 -1000 Message-ID: From: Randy Bush To: Chris Donley 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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 May 2012 23:35:04 -0000 > I don't support MSS rewrite language in 6204bis. Most of our members are > considering solutions other than DS-Lite. so you want ds-lite to fail? and here i thought we tried to engineer things to succeed. live and learn. randy, who is not particularly a ds-lite fan From cb.list6@gmail.com Fri May 11 17:45:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8F021F85FB for ; Fri, 11 May 2012 17:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mc-C4HzLbsi for ; Fri, 11 May 2012 17:45:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEB821F84A7 for ; Fri, 11 May 2012 17:45:39 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4069630pbc.31 for ; Fri, 11 May 2012 17:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XJ3vVFTc55IGAiz8XiyQISrNjd7tx08oYho0KUabUco=; b=wjzE2BBKyk4yqMI1pTe7+6aBO2i7gdl3aC6CXv8k5oVaEInoRUVi5y3T6QB8TfLqJ8 co+SR9RT62aNVECKg10X4dlfA2xwnA6TlLwyfGSbebWtOwHH+uo7HZRGIhUW8fepwsqo rZNwmWz5PjeoyR55+khinD1sLJ9OZNydBHIsjCbcDN/KcjMPbOI87pInai6nPNNB7P68 3j2D3V/3sjrDVbMlj3Ohqco6IFyWxzCXgMyCmYGLHQsISphL+7iKpdyXvibvVYajnM49 hOm2VYPr1MRhOwSXWVhnKeX619yLwS+ZJnHQR/QOA9Dxa7hGJg+Ea2JkeIzTVIkfO5E0 YrCw== MIME-Version: 1.0 Received: by 10.68.132.34 with SMTP id or2mr304509pbb.118.1336783539148; Fri, 11 May 2012 17:45:39 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Fri, 11 May 2012 17:45:39 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Fri, 11 May 2012 17:45:39 -0700 (PDT) Date: Fri, 11 May 2012 17:45:39 -0700 Message-ID: From: Cameron Byrne To: IPv6 Operations Content-Type: multipart/alternative; boundary=047d7b15a4d9fe168404bfcc2b0f Subject: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 00:45:40 -0000 --047d7b15a4d9fe168404bfcc2b0f Content-Type: text/plain; charset=ISO-8859-1 On May 11, 2012 4:35 PM, "Randy Bush" wrote: > > > I don't support MSS rewrite language in 6204bis. Most of our members are > > considering solutions other than DS-Lite. > > so you want ds-lite to fail? > > and here i thought we tried to engineer things to succeed. live and > learn. > > randy, who is not particularly a ds-lite fan > 6204bis is about bringing ds-lite into opetation. So it needs to address a well know and highly impactful issue regarding mtu treatment. Make ds-lite operational or send it to historical. Allowing operators to slam into this brick wall is not acceptable. Cb _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7b15a4d9fe168404bfcc2b0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 11, 2012 4:35 PM, "Randy Bush" <randy@psg.com> wrote:
>
> > I don't support MSS rewrite language in 6204bis. =A0Most of o= ur members are
> > considering solutions other than DS-Lite.
>
> so you want ds-lite to fail?
>
> and here i thought we tried to engineer things to succeed. =A0live and=
> learn.
>
> randy, who is not particularly a ds-lite fan
>

6204bis is about bringing ds-lite into opetation. So it needs to address= a well know and highly impactful issue regarding mtu treatment.

Make ds-lite operational or send it to historical.

Allowing operators to slam into this brick wall is not acceptable.

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

--047d7b15a4d9fe168404bfcc2b0f-- From shemant@cisco.com Fri May 11 20:30:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5119E8007 for ; Fri, 11 May 2012 20:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tn2fLyGQMOa for ; Fri, 11 May 2012 20:30:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4568B21F85AF for ; Fri, 11 May 2012 20:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7628; q=dns/txt; s=iport; t=1336793447; x=1338003047; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=nYiG8Sp2xHPxbTp/nPYFdkJQmSGuT+1YuZSyHD3Yl1w=; b=mQGm71jbVZWEgwdJDUsTb/NcJ5ISvIK3wzTQ96c/k0YR9M4OGKCG0U8V Kf8WbYTINWU7r+krKgt13JraiIlHHPIGYrI/6GbgfwBiGBAif8TRh+IAx Zer89XhAojf+/FNR0Qoq6TKVMFg8RF4IO7nLozYhf5cO/nDnx+J2zS15n g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAD3YrU+tJXHA/2dsb2JhbABEgkanbgGJO4EHghUBAQEEEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEARIIDA6HbAubKJ9dixeFJWMEiGSOKo1GgWmDBw X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208,217";a="82567397" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 12 May 2012 03:30:46 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q4C3Ukhl026298; Sat, 12 May 2012 03:30:46 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 May 2012 22:30:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2FEF.9DDD2692" Date: Fri, 11 May 2012 22:30:44 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0v2JPc5ONYesfDTm+w57Q4vrjDtQAFDlyQ References: From: "Hemant Singh (shemant)" To: "Cameron Byrne" , "IPv6 Operations" X-OriginalArrivalTime: 12 May 2012 03:30:46.0536 (UTC) FILETIME=[9E6EC080:01CD2FEF] Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 03:30:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2FEF.9DDD2692 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Cameron Byrne Sent: Friday, May 11, 2012 8:46 PM To: IPv6 Operations Subject: [v6ops] 6204 bis and mtu >6204bis is about bringing ds-lite into opetation. So it needs to address a well know and highly impactful issue regarding mtu >treatment. Thinking some more, for a protocol document such as RFC 6333 the community will not let the document through if the document specifies any layer violation. That is why DS-Lite could not add the MSS Rewrite for the CPE router. However the CPE router specification certainly has some flexibility towards adding minor tweaks to solve major problems. RFC 6204 came into being with one example as a tweak to DHCPv6 where RFC 3315 said, the DUID SHOULD be persistent but three different CPE routers implemented the time-based DUID and on each reset of the CPE router, the DUID changed and the DHCPv6 server was allocating a new prefix to the same CPE seeing a new DUID. I could reset my CPE every few minutes and exhaust the DHCPv6 server prefix pool. So RFC 6204 said something like the "DUID MUST be persistent across reloads". Thus along the same lines, the CPE router can add the MSS Rewrite requirement especially since most CPE routers can perform stateful inspection of every packet traversing the CPE router. Here is proposed text. The CPE router MUST support adjusting the MSS value of the TCP SYN packets.=20 The question now is where does the new bullet go? Should the text be added to the DS-Lite section or the General Requirements section? The URL to rfc6204bis is below. http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08 Thanks, Hemant ------_=_NextPart_001_01CD2FEF.9DDD2692 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Cameron Byrne
Sent: Friday, May 11, 2012 8:46 = PM
To: IPv6 Operations
Subject: [v6ops] 6204 bis and = mtu

>6204bis is about bringing ds-lite into opetation. So it needs to = address a well know and highly impactful issue regarding mtu >treatment.

Thinking some more, for a protocol document such as RFC 6333 the = community will not let the document through if the document specifies = any layer violation.   That is why DS-Lite could not add the = MSS Rewrite for the CPE router.   However the CPE router = specification certainly has some flexibility towards adding minor tweaks = to solve major problems.   RFC 6204 came into being with one = example as a tweak to DHCPv6 where RFC 3315 said, the DUID SHOULD be = persistent but three different CPE routers implemented the time-based = DUID and on each reset of the CPE router, the DUID changed and the = DHCPv6 server was allocating a new prefix to the same CPE seeing a new = DUID.  I could reset my CPE every few minutes and exhaust the = DHCPv6 server prefix pool.   So RFC 6204 said something like = the “DUID MUST be persistent across = reloads”.

Thus along the same lines, the CPE router can add the MSS Rewrite = requirement especially since most CPE routers can perform stateful = inspection of every packet traversing the CPE router.   Here = is proposed text.

The CPE router MUST support adjusting the MSS value of the TCP SYN = packets.

The question now is where does the new bullet go?  Should the = text be added to the DS-Lite section or the General Requirements = section?  The URL to rfc6204bis is = below.

http://to= ols.ietf.org/html/draft-ietf-v6ops-6204bis-08

Thanks,

Hemant

------_=_NextPart_001_01CD2FEF.9DDD2692-- From randy@psg.com Fri May 11 20:42:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11DB21F85B6 for ; Fri, 11 May 2012 20:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgMdMb1J6Rim for ; Fri, 11 May 2012 20:42:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5939C21F852B for ; Fri, 11 May 2012 20:42:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ST3DS-0001pd-AJ; Sat, 12 May 2012 03:41:58 +0000 Date: Fri, 11 May 2012 17:41:56 -1000 Message-ID: From: Randy Bush To: "Hemant Singh (shemant)" In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 03:42:00 -0000 > Thinking some more, for a protocol document such as RFC 6333 the > community will not let the document through if the document specifies > any layer violation. ok. i give. where is this rule enshrined? randy From dwing@cisco.com Fri May 11 22:44:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1487E21F8526 for ; Fri, 11 May 2012 22:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.405 X-Spam-Level: X-Spam-Status: No, score=-110.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLdYtR0npi+0 for ; Fri, 11 May 2012 22:44:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 21D2C21F8525 for ; Fri, 11 May 2012 22:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2536; q=dns/txt; s=iport; t=1336801464; x=1338011064; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=pFf2iA0WINAWMsj55H1RcYTdVxQwQS4wupXsV0KHBtw=; b=SUkqsxLcptjA+sT6fMSbEqx2Zy1f2pnb7gss7dBYuL521eRbthlnslg1 259RJ3ziuAZepEQcmMv8BhvssdziLBIkRbll4TWOSAcpZr9jChqYlwqgw QFIcBQ47nEpKaHMMSW/PXwp3hcqvNUd0Bzfe11WGaj95psdzCNpYfAPW1 Y=; X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="41937328" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 12 May 2012 05:44:23 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4C5iNdF006688; Sat, 12 May 2012 05:44:23 GMT From: "Dan Wing" To: "'Hemant Singh \(shemant\)'" , "'Cameron Byrne'" , "'IPv6 Operations'" References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> Date: Fri, 11 May 2012 22:44:23 -0700 Message-ID: <10e101cd3002$4917d960$db478c20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0v2JPc5ONYesfDTm+w57Q4vrjDtQAFDlyQAAUcOgA= Content-Language: en-us Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 05:44:25 -0000 > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com] > Sent: Friday, May 11, 2012 8:31 PM > To: Cameron Byrne; IPv6 Operations > Cc: Dan Wing (dwing); Chris Donley > Subject: RE: [v6ops] 6204 bis and mtu > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Cameron Byrne > Sent: Friday, May 11, 2012 8:46 PM > To: IPv6 Operations > Subject: [v6ops] 6204 bis and mtu > > >6204bis is about bringing ds-lite into opetation. So it needs to > address a well know and highly impactful issue regarding mtu > >treatment. > > Thinking some more, for a protocol document such as RFC 6333 the > community will not let the document through if the document specifies > any layer violation. That is why DS-Lite could not add the MSS > Rewrite for the CPE router. However the CPE router specification > certainly has some flexibility towards adding minor tweaks to solve > major problems. RFC 6204 came into being with one example as a tweak > to DHCPv6 where RFC 3315 said, the DUID SHOULD be persistent but three > different CPE routers implemented the time-based DUID and on each reset > of the CPE router, the DUID changed and the DHCPv6 server was > allocating a new prefix to the same CPE seeing a new DUID. I could > reset my CPE every few minutes and exhaust the DHCPv6 server prefix > pool. So RFC 6204 said something like the "DUID MUST be persistent > across reloads". > > Thus along the same lines, the CPE router can add the MSS Rewrite > requirement especially since most CPE routers can perform stateful > inspection of every packet traversing the CPE router. Here is > proposed text. > > The CPE router MUST support adjusting the MSS value of the TCP SYN > packets. In which direction (inbound, outbound, or both)? What value should operators adjust the MSS to? Should the MSS be adjusted by default, or should it not be adjustment by default? Is MSS adjustment best done by the CPE, or best done by the DS-Lite AFTR or 6rd BR? > The question now is where does the new bullet go? Should the text be > added to the DS-Lite section or the General Requirements section? The > URL to rfc6204bis is below. > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08 The problem occurs whenever the effective MTU is reduced, such as with a tunnel. 6rd is also a tunnel, and I doubt is immune from the problem. The use of 1280 byte MTUs by IPv6 servers helps to obscure the problem over IPv6. -d From brian.e.carpenter@gmail.com Fri May 11 23:50:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6861C21F8634 for ; Fri, 11 May 2012 23:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.586 X-Spam-Level: X-Spam-Status: No, score=-101.586 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrQRq0+L2s2x for ; Fri, 11 May 2012 23:50:06 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 616DA21F8624 for ; Fri, 11 May 2012 23:50:05 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so760571wib.13 for ; Fri, 11 May 2012 23:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GToxNEw9ZERNdjmc5q4jkTXko0050uDxkRNG0prY7EA=; b=nmYEeGwu2mg8T0nX+FW2mSgFWizANiSazw9UYyXLqad7e2fpk2FXa/Lgp1pvkY+4v/ borNLHbRnuPt/c3t7ZH0BFzlmpXiazmROJBnr3zi6L67yHA2+QnQn67VZtWd98Yd+rEy xiRDo1nn7mBeLDGsj5kb1ioEguKMyX3adGSZMCaVhC9zXwrwn8UkWDthvRRqo0pkWP0F CR0Jn1LwPCAsdOGQyAsQIwO8P/CElpviXxanHF5Pp21eFlVvfxhl7XJ4d1bDWmoFcT+d iARjpAiLDB0JJHy9SPf0HhU8rku/92YnwcYE1ZFmgUCSec2a7nVXygL6ESpVCp/g1ey0 Qzwg== Received: by 10.180.105.69 with SMTP id gk5mr2276509wib.3.1336805404625; Fri, 11 May 2012 23:50:04 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-118.as13285.net. [2.102.216.118]) by mx.google.com with ESMTPS id fn2sm26113948wib.0.2012.05.11.23.50.02 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 23:50:03 -0700 (PDT) Message-ID: <4FAE0818.8090604@gmail.com> Date: Sat, 12 May 2012 07:50:00 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 06:50:07 -0000 On 2012-05-12 04:41, Randy Bush wrote: >> Thinking some more, for a protocol document such as RFC 6333 the >> community will not let the document through if the document specifies >> any layer violation. > > ok. i give. where is this rule enshrined? Not in RFC 1958, I'm glad to say. Somewhere in the OSI scrolls, I suspect. MSS breakage has been seen in the wild for 6to4, and will undoubtedly be a real problem for ds-lite. Certainly we need to document it. > The CPE router MUST support adjusting the MSS value of the TCP SYN > packets. That seems too brief to me. It doesn't tell the implementer what to do. Something: The CPE router MUST support reducing the MSS value of the TCP SYN packets if necessary to fit within the effective MTU of the tunnel. Brian From randy@psg.com Sat May 12 00:40:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD41F21F8555 for ; Sat, 12 May 2012 00:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6FjyE+xFjsa for ; Sat, 12 May 2012 00:40:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2420C21F8546 for ; Sat, 12 May 2012 00:40:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ST6wD-0002Dv-1u; Sat, 12 May 2012 07:40:25 +0000 Date: Fri, 11 May 2012 21:40:23 -1000 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4FAE0818.8090604@gmail.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <4FAE0818.8090604@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 07:40:34 -0000 >>> Thinking some more, for a protocol document such as RFC 6333 the >>> community will not let the document through if the document >>> specifies any layer violation. >> ok. i give. where is this rule enshrined? > Not in RFC 1958, I'm glad to say. Somewhere in the OSI scrolls, I > suspect. let's be honest here. what it means is "i will get as many of my friends as i can to object at wglc or ietf lc." > MSS breakage has been seen in the wild for 6to4 it's a tunnel problem. didn't pekka or someone do a draft on that some years back? might have even become an rfc. randy From joelja@bogus.com Sat May 12 01:51:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D5921F854E for ; Sat, 12 May 2012 01:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JSr0eg8SVyX for ; Sat, 12 May 2012 01:51:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C183821F854C for ; Sat, 12 May 2012 01:51:10 -0700 (PDT) Received: from wifi-208-85.mtg.afnog.org (wifi-208-85.mtg.afnog.org [196.200.208.85]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q4C8oulX051178 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 12 May 2012 08:51:00 GMT (envelope-from joelja@bogus.com) Message-ID: <4FAE246E.9080406@bogus.com> Date: Sat, 12 May 2012 08:50:54 +0000 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Randy Bush References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 12 May 2012 08:51:01 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 08:51:11 -0000 On 5/12/12 03:41 , Randy Bush wrote: >> Thinking some more, for a protocol document such as RFC 6333 the >> community will not let the document through if the document specifies >> any layer violation. > > ok. i give. where is this rule enshrined? arp much? > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sat May 12 02:45:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293D021F85D5 for ; Sat, 12 May 2012 02:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqTriXpvn-Wt for ; Sat, 12 May 2012 02:45:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B050A21F85D8 for ; Sat, 12 May 2012 02:45:42 -0700 (PDT) Received: from wifi-208-85.mtg.afnog.org (wifi-208-85.mtg.afnog.org [196.200.208.85]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q4C9jYjm052197 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 12 May 2012 09:45:37 GMT (envelope-from joelja@bogus.com) Message-ID: <4FAE313C.7060501@bogus.com> Date: Sat, 12 May 2012 09:45:32 +0000 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Chris Donley References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 12 May 2012 09:45:39 +0000 (UTC) Cc: IPv6 Operations , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 09:45:43 -0000 On 5/11/12 22:45 , Chris Donley wrote: > I don't support MSS rewrite language in 6204bis. Most of our members are > considering solutions other than DS-Lite. I suggest that those who are > planning DS-Lite deployments talk with their vendors if they think they > need MSS rewrite support. While I am unconvinced that we need to address this, I think the rational expressed here is rather poor. If requirements for DS-Lite are not germain to cpe router deployment it wouldn't be represented in 6204bis. It is in fact not a feature of 6204. joel > > Chris > > > > > On 5/11/12 9:22 AM, "Cameron Byrne" wrote: > >> On Fri, May 11, 2012 at 7:19 AM, Chris Donley >> wrote: >>> We did our testing on a DOCSIS network, which allows 1522 byte frames. >>> We >>> did not enable MSS rewriting. >>> >> >> If this issue is systemic for DOCSIS, and MSS rewrite is a known and >> common solution, should 6204bis include language about MSS rewrite? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Sat May 12 06:01:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9665A21F861F for ; Sat, 12 May 2012 06:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.59 X-Spam-Level: X-Spam-Status: No, score=-101.59 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T3Xw1+I8RFm for ; Sat, 12 May 2012 06:01:44 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D644821F8507 for ; Sat, 12 May 2012 06:01:43 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2449194wgb.13 for ; Sat, 12 May 2012 06:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EZcoEmLuqXIpHeHncQlLkny3hmKuzQoLfF/9RtEqvA8=; b=Puras+AT1QcO4BpzadxZ8HievajTvsab8bd9o3mCxG/JvBQUMDWNzUNJiknfFkF+tJ SW8k1h8GdV0ZydSSSe12AZdQrd+awKCK6Pix/huOnbTtPtaeNTqcmvbBEgta17SFVqe8 Jj01nkq10YnZG00hxeAuDpSKKF8c3l01wQnyMg7g+Aahhj1C0EjZ2t2z6Qd5DUX+Mox6 njEaRto1J4jp7/2NYNSZX3/5qQWbIeSDWYiBJX2t0WoHxkjsBQbXA++39LNoPvqGNLKj zpoiNyYlWcvLoDM4ul7l4TODbomru5UVXlKgnR3Dj3RffoQ4qx5PY5NRTfgANqks0nxw Isng== Received: by 10.180.92.9 with SMTP id ci9mr4174937wib.15.1336827702690; Sat, 12 May 2012 06:01:42 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-118.as13285.net. [2.102.216.118]) by mx.google.com with ESMTPS id h8sm29646200wix.4.2012.05.12.06.01.40 (version=SSLv3 cipher=OTHER); Sat, 12 May 2012 06:01:41 -0700 (PDT) Message-ID: <4FAE5F34.5050805@gmail.com> Date: Sat, 12 May 2012 14:01:40 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <4FAE0818.8090604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 13:01:44 -0000 On 2012-05-12 08:40, Randy Bush wrote: >>>> Thinking some more, for a protocol document such as RFC 6333 the >>>> community will not let the document through if the document >>>> specifies any layer violation. >>> ok. i give. where is this rule enshrined? >> Not in RFC 1958, I'm glad to say. Somewhere in the OSI scrolls, I >> suspect. > > let's be honest here. what it means is "i will get as many of my > friends as i can to object at wglc or ietf lc." > >> MSS breakage has been seen in the wild for 6to4 > > it's a tunnel problem. didn't pekka or someone do a draft on that some > years back? might have even become an rfc. 4459, but it's nothing like a recommendation to clamp the MSS. Brian From fgont@si6networks.com Sat May 12 06:38:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45C321F8659 for ; Sat, 12 May 2012 06:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EImhO8fBUxe7 for ; Sat, 12 May 2012 06:38:48 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 16F4D21F8657 for ; Sat, 12 May 2012 06:38:48 -0700 (PDT) Received: from [24.114.252.237] (helo=[192.168.16.183]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1STCWx-0001Y7-HT; Sat, 12 May 2012 15:38:44 +0200 Message-ID: <4FAE67DE.7000300@si6networks.com> Date: Sat, 12 May 2012 09:38:38 -0400 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 13:38:48 -0000 On 05/11/2012 11:30 PM, Hemant Singh (shemant) wrote: >>6204bis is about bringing ds-lite into opetation. So it needs to address > a well know and highly impactful issue regarding mtu >treatment. > > Thinking some more, for a protocol document such as RFC 6333 the > community will not let the document through if the document specifies > any layer violation. Then I'd wonder how the IETF got to publish specifications for e.g. TCP, UDP, ICMP, ICMPv6, FTP, etc. -- All of the former compute a checksum that includes (n-1)-layer values (IP or IPv6 addresses), while the later hardcodes internet-layer addresses into an application protocol. -- And no, this should not be taken as criticism against the aforementioned protocols, but rather as an indication that "layering violation" is quite common practice... so I'm not sure why this should be an issue particularly in an *operations* wg... -- I wonder if those that "will not let the document through" would suffer if there's widespread breakage just because of their "purism", or whether it's just that having real networks break is simply not their problem. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From joelja@bogus.com Sat May 12 07:02:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D20421F84BF for ; Sat, 12 May 2012 07:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdYQiZLyCaXW for ; Sat, 12 May 2012 07:02:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0974A21F84AF for ; Sat, 12 May 2012 07:02:51 -0700 (PDT) Received: from Joels-MacBook-Pro.local ([41.223.215.14]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q4CE2gES056566 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 12 May 2012 14:02:47 GMT (envelope-from joelja@bogus.com) Message-ID: <4FAE6D7A.3020709@bogus.com> Date: Sat, 12 May 2012 14:02:34 +0000 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Fernando Gont References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <4FAE67DE.7000300@si6networks.com> In-Reply-To: <4FAE67DE.7000300@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 12 May 2012 14:02:49 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 14:02:51 -0000 On 5/12/12 13:38 , Fernando Gont wrote: > On 05/11/2012 11:30 PM, Hemant Singh (shemant) wrote: > >>> 6204bis is about bringing ds-lite into opetation. So it needs to address >> a well know and highly impactful issue regarding mtu >treatment. >> >> Thinking some more, for a protocol document such as RFC 6333 the >> community will not let the document through if the document specifies >> any layer violation. In the ops case I find it hard to countenance that if we found that clamping the mss was necessary that we would not accordingly provide advice to that end. > Then I'd wonder how the IETF got to publish specifications for e.g. TCP, > UDP, ICMP, ICMPv6, FTP, etc. -- All of the former compute a checksum > that includes (n-1)-layer values (IP or IPv6 addresses), while the later > hardcodes internet-layer addresses into an application protocol. > > -- And no, this should not be taken as criticism against the > aforementioned protocols, but rather as an indication that "layering > violation" is quite common practice... so I'm not sure why this should > be an issue particularly in an *operations* wg... -- I wonder if those > that "will not let the document through" would suffer if there's > widespread breakage just because of their "purism", or whether it's just > that having real networks break is simply not their problem. > > Cheers, From shemant@cisco.com Sat May 12 08:31:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5408F21F8615 for ; Sat, 12 May 2012 08:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2UBuEgI4zbd for ; Sat, 12 May 2012 08:31:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD4621F8576 for ; Sat, 12 May 2012 08:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=13852; q=dns/txt; s=iport; t=1336836673; x=1338046273; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=0NWkMRr/UmxQpfGKp2x1X5pl8v2vZRxzip7tLy/kwN0=; b=htbQGj2uLjbrVB5wxlbtbV0a39gTP8yFTsKDt+C8tGbfFNdR3nRSMrPA r12ii9+KohYBRcOzpuzARPOdfOlTVXGUY1esvrj6Fb7opc3MM8gu1pO8B Wfz2XceOLT3kvpI7k93sGwf6s+PLlUfoUKbgTKa3f4xVH8UDo9xpb4gXs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAP2Ark+tJV2a/2dsb2JhbABEgkaxKoEHghUBAQEEEgEJEQNJDAQCAQgRBAEBCwYYBgFOCAEBBAEaGodsmwyfRYsahSVjBIhkm3CBaYMH X-IronPort-AV: E=Sophos;i="4.75,576,1330905600"; d="scan'208,217";a="82634623" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 12 May 2012 15:31:12 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4CFVC12030664; Sat, 12 May 2012 15:31:12 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 May 2012 10:31:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3054.42627866" Date: Sat, 12 May 2012 10:31:09 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> In-Reply-To: <10e101cd3002$4917d960$db478c20$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0v2JPc5ONYesfDTm+w57Q4vrjDtQAFDlyQAAUcOgAAEuawQA== References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <10e101cd3002$4917d960$db478c20$@com> From: "Hemant Singh (shemant)" To: "Dan Wing (dwing)" , "Cameron Byrne" , "IPv6 Operations" X-OriginalArrivalTime: 12 May 2012 15:31:12.0084 (UTC) FILETIME=[42DDF140:01CD3054] Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 15:31:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3054.42627866 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, =20 -----Original Message----- From: Dan Wing (dwing)=20 Sent: Saturday, May 12, 2012 1:44 AM To: Hemant Singh (shemant); 'Cameron Byrne'; 'IPv6 Operations' Cc: 'Chris Donley' Subject: RE: [v6ops] 6204 bis and mtu =20 =20 >In which direction (inbound, outbound, or both)? =20 =20 At least outbound which is the direction from the CPE router to the SP. =20 >What value should operators adjust the MSS to? =20 =20 Most PC hosts have default MTU set to 1500. Thus, for PPPOE, the value of MSS to use is 1452. Then there is room left for 20 bytes for the IP header, 20 bytes for the TCP header, and 8 bytes for the PPPOE header. The MSS value changes based on effective MTU for other technologies such as 6rd and DS-Lite for non-PPPOE use cases for connecting to the SP. Thus one could compute a common denominator that works for all uses cases for the CPE to use. =20 >Should the MSS be adjusted by default, or should it not be adjustment by default? =20 =20 Default because the hosts happen to have a default MTU of 1500. =20 >Is MSS adjustment best done by the CPE, or best done by the DS-Lite AFTR or 6rd BR? =20 It's tricky. I would say the AFTR or the BR. Any one node in the path from the host in the home (the host is behind the CPE router) and the TCP server can set the MSS. The host in the home has initiated a TCP client connection. Both the CPE router and the AFTR or the BR sit before the host TCP client and the TCP server on the Internet. It's a hassle to have the CPE router compute a common denominator for the MSS value to use. It is best left to individual technology to set the MSS because the SP knows if 6rd (with/without PPPOE) or DS-Lite (with/without PPPOE) is being deployed. The SP should also cater to the fact the some PC hosts will still initiate 6to4. =20 =20 Now comes the tricky part. What if 6rd traffic does not go thru the BR? Then who sets the MSS but the CPE. Additionally, what if the BR or the AFTR set the MSS and the CPE router also sets the MSS? I think, since the CPE router is closest to the TCP client in the home, the MSS of the CPE router will be used. =20 >The problem occurs whenever the effective MTU is reduced, such >as with a tunnel. 6rd is also a tunnel, and I doubt is immune=20 >from the problem. The use of 1280 byte MTUs by IPv6 servers=20 >helps to obscure the problem over IPv6. =20 Agree. If any text gets added to rfc6204bis for the MSS the text goes into a common section for both 6rd and DS-Lite. =20 Thanks. =20 Hemant =20 =20 ------_=_NextPart_001_01CD3054.42627866 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan,

 

-----Original Message-----
From: = Dan Wing (dwing)
Sent: Saturday, May 12, 2012 1:44 AM
To: Hemant = Singh (shemant); 'Cameron Byrne'; 'IPv6 Operations'
Cc: 'Chris = Donley'
Subject: RE: [v6ops] 6204 bis and mtu

 

 

>In = which direction (inbound, outbound, or both)?  =

 

At least = outbound which is the direction from the CPE router to the = SP.

 

>What = value should operators adjust the MSS to? 

 

Most PC hosts have default MTU set = to 1500.  Thus, for PPPOE, the value of MSS to use is 1452.  = Then there is room left for 20 bytes for the IP header, 20 bytes for the = TCP header, and 8 bytes for the PPPOE header.  The MSS value = changes based on effective MTU for other technologies such as 6rd and = DS-Lite for non-PPPOE use cases for connecting to the SP.  Thus one = could compute a common denominator that works for all uses cases for the = CPE to use.

 

>Should the MSS be adjusted by default, or should it not be = adjustment by default? 

 

Default because the hosts happen to = have a default MTU of 1500.

 

>Is MSS adjustment best done by = the CPE, or best done by the DS-Lite AFTR or 6rd = BR?

 

It’s tricky.  I would say the AFTR or the = BR.  Any one node in the path from the host in the home (the host = is behind the CPE router) and the TCP server can set the MSS. The host = in the home has initiated a TCP client connection.  Both the CPE = router and the AFTR or the BR sit before the host TCP client and the TCP = server on the Internet.  It’s a hassle to have the CPE router = compute a common denominator for the MSS value to use.  It is best = left to individual technology to set the MSS because the SP knows if 6rd = (with/without PPPOE) or DS-Lite (with/without PPPOE) is being = deployed.  The SP should also cater to the fact the some PC hosts = will still initiate 6to4.  

 

Now comes the tricky part.  What if 6rd traffic = does not go thru the BR?  Then who sets the MSS but the = CPE.   Additionally, what if the BR or the AFTR set the MSS = and the CPE router also sets the MSS?  I think, since the CPE = router is closest to the TCP client in the home, the MSS of the CPE = router will be used.

 

>The = problem occurs whenever the effective MTU is reduced, = such

>as with a tunnel.  6rd is = also a tunnel, and I doubt is immune

>from = the problem.  The use of 1280 byte MTUs by IPv6 servers =

>helps to obscure the problem = over IPv6.

 

Agree.  If any text gets added to rfc6204bis for = the MSS the text goes into a common section for both 6rd and = DS-Lite.

 

Thanks.

 

Hemant

 

 

------_=_NextPart_001_01CD3054.42627866-- From Tina.Tsou.Zouting@huawei.com Sat May 12 09:06:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9BA21F85A0 for ; Sat, 12 May 2012 09:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QBn-P+z+xUn for ; Sat, 12 May 2012 09:06:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6E15F21F854F for ; Sat, 12 May 2012 09:06:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFV95178; Sat, 12 May 2012 12:06:30 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 12 May 2012 09:04:52 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Sat, 12 May 2012 09:04:48 -0700 From: Tina TSOU To: "Hemant Singh (shemant)" Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: AQHNL9iYEJKix0ifpEKlx7IAMvUSbZbF9OEAgAAlV4CAAKPxgP//lA4e Date: Sat, 12 May 2012 16:04:47 +0000 Message-ID: <52F40CF6-7FD1-4E5C-8617-C885F1D7AE9E@huawei.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <10e101cd3002$4917d960$db478c20$@com>, <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_52F40CF67FD14E5C8617C885F1D7AE9Ehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 16:06:37 -0000 --_000_52F40CF67FD14E5C8617C885F1D7AE9Ehuaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sent from my iPad On May 12, 2012, at 8:31 AM, "Hemant Singh (shemant)" > wrote: Dan, -----Original Message----- From: Dan Wing (dwing) Sent: Saturday, May 12, 2012 1:44 AM To: Hemant Singh (shemant); 'Cameron Byrne'; 'IPv6 Operations' Cc: 'Chris Donley' Subject: RE: [v6ops] 6204 bis and mtu >In which direction (inbound, outbound, or both)? At least outbound which is the direction from the CPE router to the SP. >What value should operators adjust the MSS to? Most PC hosts have default MTU set to 1500. Thus, for PPPOE, the value of = MSS to use is 1452. Then there is room left for 20 bytes for the IP header= , 20 bytes for the TCP header, and 8 bytes for the PPPOE header. The MSS v= alue changes based on effective MTU for other technologies such as 6rd and = DS-Lite for non-PPPOE use cases for connecting to the SP. Thus one could c= ompute a common denominator that works for all uses cases for the CPE to us= e. >Should the MSS be adjusted by default, or should it not be adjustment by d= efault? Default because the hosts happen to have a default MTU of 1500. >Is MSS adjustment best done by the CPE, or best done by the DS-Lite AFTR o= r 6rd BR? It=92s tricky. I would say the AFTR or the BR. Any one node in the path f= rom the host in the home (the host is behind the CPE router) and the TCP se= rver can set the MSS. The host in the home has initiated a TCP client conne= ction. Both the CPE router and the AFTR or the BR sit before the host TCP = client and the TCP server on the Internet. It=92s a hassle to have the CPE= router compute a common denominator for the MSS value to use. It is best = left to individual technology to set the MSS because the SP knows if 6rd (w= ith/without PPPOE) or DS-Lite (with/without PPPOE) is being deployed. The = SP should also cater to the fact the some PC hosts will still initiate 6to4= . Now comes the tricky part. What if 6rd traffic does not go thru the BR? In what case the 6rd traffic does not go thru the BR? Then who sets the MSS but the CPE. Additionally, what if the BR or the AF= TR set the MSS and the CPE router also sets the MSS? I think, since the CP= E router is closest to the TCP client in the home, the MSS of the CPE route= r will be used. >The problem occurs whenever the effective MTU is reduced, such >as with a tunnel. 6rd is also a tunnel, and I doubt is immune >from the problem. The use of 1280 byte MTUs by IPv6 servers >helps to obscure the problem over IPv6. Agree. If any text gets added to rfc6204bis for the MSS the text goes into= a common section for both 6rd and DS-Lite. Thanks. Hemant --_000_52F40CF67FD14E5C8617C885F1D7AE9Ehuaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Sent from my iPad

On May 12, 2012, at 8:31 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:

Dan,

 

-----Original Message-----
From: Dan Wing (dwing)
Sent: Saturday, May 12, 2012 1:44 AM
To: Hemant Singh (shemant); 'Cameron Byrne'; 'IPv6 Operations'
Cc: 'Chris Donley'
Subject: RE: [v6ops] 6204 bis and mtu

 

 

>In which direction (inbound, outbound, or both)? 

 

At least outbound which is the direction from the CPE router to the SP.<= o:p>

 

>What value should operators adjust the MSS to? 

 

Most PC hosts have default MTU set to 1500.  Thus, for PPPOE, the v= alue of MSS to use is 1452.  Then there is room left for 20 bytes for = the IP header, 20 bytes for the TCP header, and 8 bytes for the PPPOE header.  The MSS value changes based on effective MTU f= or other technologies such as 6rd and DS-Lite for non-PPPOE use cases for c= onnecting to the SP.  Thus one could compute a common denominator that= works for all uses cases for the CPE to use.

 

>Should the MSS be adjusted by default, or should it not be adjustmen= t by default? 

 

Default because the hosts happen to have a default MTU of 1500.

 

>Is MSS adjustment best done by the CPE, or best done by the DS-Lite = AFTR or 6rd BR?

 

It=92s tricky.  I would say the AFTR or the BR.  A= ny one node in the path from the host in the home (the host is behind the C= PE router) and the TCP server can set the MSS. The host in the home has initiated a TCP client connection.  Both the CPE router = and the AFTR or the BR sit before the host TCP client and the TCP server on= the Internet.  It=92s a hassle to have the CPE router compute a commo= n denominator for the MSS value to use.  It is best left to individual technology to set the MSS because the SP knows = if 6rd (with/without PPPOE) or DS-Lite (with/without PPPOE) is being deploy= ed.  The SP should also cater to the fact the some PC hosts will still= initiate 6to4.  

 

Now comes the tricky part.  What if 6rd traffic does no= t go thru the BR? 

In what case the 6rd traffic does not go thru the BR?

Then who sets the MSS but the CPE.   Additionally,= what if the BR or the AFTR set the MSS and the CPE router also sets the MS= S?  I think, since the CPE router is closest to the TCP client in the home, the MSS of the CPE router will be used.

 

>The problem occurs whenever the effective MTU is reduced, such<= /o:p>

>as with a tunnel.  6rd is also a tunnel, and I doubt is immune

>from the problem.  The use of 1280 byte MTUs by IPv6 servers

>helps to obscure the problem over IPv6.

 

Agree.  If any text gets added to rfc6204bis for the MS= S the text goes into a common section for both 6rd and DS-Lite.<= /span>

 

Thanks.

 

Hemant

 

 

--_000_52F40CF67FD14E5C8617C885F1D7AE9Ehuaweicom_-- From shemant@cisco.com Sat May 12 10:15:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D8F21F85C4 for ; Sat, 12 May 2012 10:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0CX7kUufIup for ; Sat, 12 May 2012 10:15:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F17F721F85B5 for ; Sat, 12 May 2012 10:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4921; q=dns/txt; s=iport; t=1336842947; x=1338052547; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=1NgltOOhMP31B58SpdHAcqfGNs5NPXcvDlJnNn3oUEc=; b=JBy56w+53/z2etdaus6QW40IKofO9Pjy4jwEyUbg/p3Bd2BBsCrejYyC mj9gx1jhbBPqESdqw24IV0wq/mlf0krjv/emCJLc0PehVrlY3i+09m8VD ooEylFcFemf2fttKTQJLHA89GVBDGNSVy60JLRR9dnOypk8nalEH17mGr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAqYrk+tJV2c/2dsb2JhbABEgkaxKoEHghUBAQEEEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgCBBMIGodsmnyfNIsahSVjBIhkm3CBaYMH X-IronPort-AV: E=Sophos;i="4.75,576,1330905600"; d="scan'208,217";a="82464313" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 12 May 2012 17:08:09 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q4CH89XV001749; Sat, 12 May 2012 17:08:09 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 May 2012 12:08:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3061.CDB247EA" Date: Sat, 12 May 2012 12:08:06 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C393@XMB-RCD-109.cisco.com> In-Reply-To: <52F40CF6-7FD1-4E5C-8617-C885F1D7AE9E@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: AQHNL9iYEJKix0ifpEKlx7IAMvUSbZbF9OEAgAAlV4CAAKPxgP//lA4egAAQt2A= References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com><10e101cd3002$4917d960$db478c20$@com>, <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> <52F40CF6-7FD1-4E5C-8617-C885F1D7AE9E@huawei.com> From: "Hemant Singh (shemant)" To: "Tina TSOU" X-OriginalArrivalTime: 12 May 2012 17:08:09.0121 (UTC) FILETIME=[CE175910:01CD3061] Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 17:15:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3061.CDB247EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20 Sent: Saturday, May 12, 2012 12:05 PM To: Hemant Singh (shemant) Cc: Dan Wing (dwing); Cameron Byrne; IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu =20 >In what case the 6rd traffic does not go thru the BR? =20 There is already a use case that an SP in the U.S. is considering to deploy 6rd as. An additional route is added to the CPE router to have two 6rd CPE's talk directly to each other rather than going thru the BR. That is why rfc6204bis includes a bullet related to a "user-configured" CPE in the 6rd section. =20 Hemant ------_=_NextPart_001_01CD3061.CDB247EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Tina TSOU = [mailto:Tina.Tsou.Zouting@huawei.com]
Sent: Saturday, May 12, = 2012 12:05 PM
To: Hemant Singh (shemant)
Cc: Dan = Wing (dwing); Cameron Byrne; IPv6 Operations
Subject: Re: = [v6ops] 6204 bis and mtu

 

>In what case the = 6rd traffic does not go thru the BR?

 

There is already a use = case that an SP in the U.S. is considering to deploy 6rd as.  An = additional route is added to the CPE router to have two 6rd CPE’s = talk directly to each other rather than going thru the BR.   = That is why rfc6204bis includes a bullet related to a =  “user-configured” CPE in the 6rd = section.

 

Hemant



------_=_NextPart_001_01CD3061.CDB247EA-- From fred@cisco.com Sat May 12 10:16:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A9421F85BB for ; Sat, 12 May 2012 10:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1OWSl6eqITW for ; Sat, 12 May 2012 10:16:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7A50221F85B9 for ; Sat, 12 May 2012 10:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=904; q=dns/txt; s=iport; t=1336843014; x=1338052614; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=pWDDQ+p41HdbAa0+M63EaNGDytUoz0IUX912Wh0D6Zs=; b=HuNNJDxUkC775EJfk1MWFjTJwEzTRc4fla5XnfF9ZBRu1nSwQIb6yh5h e82jMSqYDoEDh8i6pdfnO4tMKUeHw/vh+9Nx2yCrv3zcj8Miaim7p2Ly9 nSE2uvCKS08jTARbc0EolSGEC0Y+VcgYZFJpa4gEo/pqwWibVjuWThjAb c=; X-IronPort-AV: E=Sophos;i="4.75,576,1330905600"; d="scan'208";a="82682058" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 12 May 2012 17:09:53 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q4CH9qec021355; Sat, 12 May 2012 17:09:52 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Sat, 12 May 2012 10:09:53 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Sat, 12 May 2012 10:09:53 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> Date: Sat, 12 May 2012 10:09:31 -0700 Message-Id: <62129DB3-B653-4715-BD1B-41F5156D5E81@cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 17:16:55 -0000 On May 11, 2012, at 8:30 PM, Hemant Singh (shemant) wrote: > The CPE router MUST support adjusting the MSS value of the TCP SYN = packets. >=20 chair hat off - two points. One, you were the guy complaining about 6rd sunset as adding an infinite = string of new requirements when it in fact added a very finite set of = new requirements. This seems in fact to be more in line with "an = undelimited set of new requirements - and as noted, it is a layer = violation. Two, this is a feature I use on my home router. It is not specific to = ds-lite, it is needed for any form of tunneling, due to the lack of = deployment of RFC 4821 and the fact that filtering of ICMP is common. It = prevents the use of IPsec (it can be done before placing traffic into an = IPsec tunnel, but not on traffic that has already been signed), and = doesn't work at all on IPsec-encrypted traffic.= From Tina.Tsou.Zouting@huawei.com Sat May 12 10:25:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAFB21F858F for ; Sat, 12 May 2012 10:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d64ksRtxc0NA for ; Sat, 12 May 2012 10:25:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7301821F858A for ; Sat, 12 May 2012 10:25:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGC97460; Sat, 12 May 2012 13:25:58 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 12 May 2012 10:24:18 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Sat, 12 May 2012 10:24:13 -0700 From: Tina TSOU To: "Hemant Singh (shemant)" Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: AQHNL9iYEJKix0ifpEKlx7IAMvUSbZbF9OEAgAAlV4CAAKPxgP//lA4egAAQt2CAAAV4Kw== Date: Sat, 12 May 2012 17:24:12 +0000 Message-ID: <567B0281-2C6D-4CF6-9669-6BE99E5BE00B@huawei.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com><10e101cd3002$4917d960$db478c20$@com>, <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> <52F40CF6-7FD1-4E5C-8617-C885F1D7AE9E@huawei.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C393@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C393@XMB-RCD-109.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_567B02812C6D4CF696696BE99E5BE00Bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 17:25:59 -0000 --_000_567B02812C6D4CF696696BE99E5BE00Bhuaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sent from my iPad On May 12, 2012, at 10:08 AM, "Hemant Singh (shemant)" > wrote: From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Sent: Saturday, May 12, 2012 12:05 PM To: Hemant Singh (shemant) Cc: Dan Wing (dwing); Cameron Byrne; IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu >In what case the 6rd traffic does not go thru the BR? There is already a use case that an SP in the U.S. is considering to deploy= 6rd as. An additional route is added to the CPE router to have two 6rd CP= E=92s talk directly to each other rather than going thru the BR. That is = why rfc6204bis includes a bullet related to a =93user-configured=94 CPE in= the 6rd section. Is it for residential service or enterprise service? For example, For residential service, does it mean my home CPE talks directly to my neig= hbor's home CPE? For enterprise service, does it mean my Comcast CE Router in Futuwerwei tal= ks directly to CE router in Nvidia? Hemant --_000_567B02812C6D4CF696696BE99E5BE00Bhuaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Sent from my iPad

On May 12, 2012, at 10:08 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:

 

From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.c= om]
Sent: Saturday, May 12, 2012 12:05 PM
To: Hemant Singh (shemant)
Cc: Dan Wing (dwing); Cameron Byrne; IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

=  

>In what case the 6rd traffic does not g= o thru the BR?

 

There is already a use= case that an SP in the U.S. is considering to deploy 6rd as.  An addi= tional route is added to the CPE router to have two 6rd CPE=92s talk direct= ly to each other rather than going thru the BR.   That is why rfc6204bis includes a bullet related to a &nbs= p;=93user-configured=94 CPE in the 6rd section.

Is it for residential service or enterprise service?
For example,
For residential service, does it mean my home CPE talks directly to my= neighbor's home CPE?
For enterprise service, does it mean my Comcast CE Router in Futuwerwe= i talks directly to CE router in Nvidia?

 

Hemant



--_000_567B02812C6D4CF696696BE99E5BE00Bhuaweicom_-- From randy@psg.com Sat May 12 14:32:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5364A21F8453 for ; Sat, 12 May 2012 14:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPnl5vg37AYf for ; Sat, 12 May 2012 14:32:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E793021F844C for ; Sat, 12 May 2012 14:32:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1STJvU-0003X4-R3; Sat, 12 May 2012 21:32:33 +0000 Date: Sat, 12 May 2012 11:32:32 -1000 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <62129DB3-B653-4715-BD1B-41F5156D5E81@cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <62129DB3-B653-4715-BD1B-41F5156D5E81@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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 May 2012 21:32:34 -0000 fwiw. at home in tokyo, i am on ntt bflets with pppoe. any device for which i have performance requirements is down-tuned. randy From mark@townsley.net Sun May 13 09:46:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AF621F852A for ; Sun, 13 May 2012 09:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ08PcvBrmZ0 for ; Sun, 13 May 2012 09:46:33 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id A189521F8526 for ; Sun, 13 May 2012 09:46:31 -0700 (PDT) Received: by wibhm6 with SMTP id hm6so840519wib.1 for ; Sun, 13 May 2012 09:46:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=5Q/X7wLtgUX6/TIRaGMWtiDSI4AAaVhJZgBpw7m+R90=; b=AcGFDqGLEJyaNJN5IBWWrqPVUYrar91ou4OzKAtOovVBZnjMXEIafBPjNm4qHYPqxk 6iNwMVtIuGF8A/ETdbVFbrYZA7EZ7SSqhWWfzEXOjNYq3MVjxX7BWPlpzNPENAXfsyks YWy5yZu8s/yrgJqqbpX5uMh923wn5W/k/t4x7ADFHO7Mcl0JgXtCwmUg772Agzah0sfw qjAWdHmH3bdJOLYzDaVIlJH0A0abmu6+p6mY1u6Ey39V9eGwWJo7Jc4BruGg5OkNiYRy TdahWK0AzvYmBxPIpf7iC2LS+ryaHxbiEoA+TcB4fEydpac58IgPfJ1W9jNvOep+GeIZ KDnA== Received: by 10.216.139.67 with SMTP id b45mr3399207wej.0.1336927590634; Sun, 13 May 2012 09:46:30 -0700 (PDT) Received: from ams-townsley-8915.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ez4sm28762423wid.3.2012.05.13.09.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 May 2012 09:46:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_611BA99B-A59E-47F0-B50E-6C3D881495B0" From: Mark Townsley In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C393@XMB-RCD-109.cisco.com> Date: Sun, 13 May 2012 18:46:26 +0200 Message-Id: <7B93EA23-7A06-481D-9E97-7DE1DE12A76B@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com><10e101cd3002$4917d960$db478c20$@com>, <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> <52F40CF6-7FD1-4E5C-8617-C885F1D7AE9E@huawei.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C393@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkHJWo52N7X1GhzCfPdVEzlvGTLdl3O9da0UjABVfiUdfFfc0Y+ruDCeGKXKWWiBuB8RJHb Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 May 2012 16:46:34 -0000 --Apple-Mail=_611BA99B-A59E-47F0-B50E-6C3D881495B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 12, 2012, at 7:08 PM, Hemant Singh (shemant) wrote: > =20 > From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20 > Sent: Saturday, May 12, 2012 12:05 PM > To: Hemant Singh (shemant) > Cc: Dan Wing (dwing); Cameron Byrne; IPv6 Operations > Subject: Re: [v6ops] 6204 bis and mtu > =20 > >In what case the 6rd traffic does not go thru the BR? > =20 > There is already a use case that an SP in the U.S. is considering to = deploy 6rd as. An additional route is added to the CPE router to have = two 6rd CPE=92s talk directly to each other rather than going thru the = BR. =20 What you describe above is standard RFC 5969 behavior.=20 > That is why rfc6204bis includes a bullet related to a = =93user-configured=94 CPE in the 6rd section. No, that bullet is there to override the standard RFC 5969 behavior and = force all traffic through the BR if configured to do so. - Mark > =20 > Hemant >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_611BA99B-A59E-47F0-B50E-6C3D881495B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On May 12, 2012, at 7:08 PM, Hemant = Singh (shemant) wrote:

 
From: Tina TSOU = [mailto:Tina.Tsou.Zouting@huawei.com] 
Sent: Saturday, May 12, 2012 = 12:05 PM
To: Hemant Singh = (shemant)
Cc: Dan Wing (dwing); Cameron = Byrne; IPv6 Operations
Subject: Re: [v6ops] 6204 bis and = mtu
 
>In what case the 6rd traffic does not go thru the BR?
There is already a use case that an SP in the U.S. is = considering to deploy 6rd as.  An additional route is added to the = CPE router to have two 6rd CPE=92s talk directly to each other rather = than going thru the = BR.  

What you describe above is standard RFC 5969 = behavior. 

That is why = rfc6204bis includes a bullet related to a  =93user-configured=94 = CPE in the 6rd = section.

N= o, that bullet is there to override the standard RFC 5969 behavior and = force all traffic through the BR if configured to do = so.

- Mark

 
Hemant
Date: Sun, 13 May 2012 11:01:41 -0700 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-50--4867802 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 18:03:33 -0000 --Apple-Mail-50--4867802 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The working group last call for this draft announced last week continues = for another week. Please feel free to comment on it. --Apple-Mail-50--4867802 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

--Apple-Mail-50--4867802-- From victor.kuarsingh@gmail.com Sun May 13 11:21:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8F421F857A for ; Sun, 13 May 2012 11:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7YnOmYdh9dY for ; Sun, 13 May 2012 11:21:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C63621F8577 for ; Sun, 13 May 2012 11:21:16 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so7649561obb.31 for ; Sun, 13 May 2012 11:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=7oWO87XSGhTkmHWEsBXTpqQioOu1oJ8xatUD1BYazuE=; b=WLJr00e6YlwkxW+BbG7ooxVm4KnZm/SAoLaVWCqIUuWtsMzSYqT3u1C2w6M5WankAv WJ0dOQNdaoDoRA98deHlSR3NfskrHq9pizWqnSU9TXFBACfCoTSBP9S5BoK1o+UhnJz5 9KQLIGnK9WLQyIJcznyRhuEJqoRr8FSQ686JAAmDu8eDkUqeoVHihY2K4OsUXYhhIqIj OuIjAFi9RvEZ3dbic+0hZa3OzM5RcRnns9Rb8/hUe2UHW2aTqEQibG5kzrZITBkGUB9x sfZqlz4eGtWehEzWwmsuYdeewLAuuPGkcWccK0vqUTFqrIh28Y9JCdDJQWBdJF6GIIDH Oaug== Received: by 10.50.180.225 with SMTP id dr1mr2726611igc.52.1336933275691; Sun, 13 May 2012 11:21:15 -0700 (PDT) Received: from [192.168.100.235] (CPE84c9b2590d49-CM80c6ab7f57ed.cpe.net.cable.rogers.com. [99.229.196.236]) by mx.google.com with ESMTPS id ai6sm14851955igc.0.2012.05.13.11.21.12 (version=SSLv3 cipher=OTHER); Sun, 13 May 2012 11:21:14 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 13 May 2012 14:21:09 -0400 From: Victor Kuarsingh To: Message-ID: Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3419763673_253376" Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 18:21:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3419763673_253376 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable WG, As a note, an updated version was posted with the NAT64 updates per comment= s in Paris. As of now, we still have not changed the tone of the document from the "deploy IPv6" and "consider IPv4". Also, there had been some comments from one of the contributors that would have put stronger language round IPv6-only methods of operation (to the CPE) which would have operators potentially allow IPv4 to suffer in performance to promote IPv6 operation =AD this has not yet been included. My personal opinion is that making IPv4 operate worse on purpose when given other options is counterintuitive to the job of an operator. Other opinions welcome. =20 So basic points still remain: * Deploy IPv6 as soon as you can * Prepare for IPv6 (training, architecture, protocols etc) * Do it with forward considerations of IPv6-only operation * Consider the duality of IPv4 and IPv6 when you choose transition technologies and path forward * Try and keep IP flows off transition techs to the best extent possible (cost, scaling, performance benefits) * Operator can choose to deploy transition techs differently if they choose= , but should be aware of consequences (cost, scale, performance) Regards, Victor K From: Fred Baker Date: Sun, 13 May 2012 11:01:41 -0700 To: Cc: , Ron Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC The working group last call for this draft announced last week continues fo= r another week. Please feel free to comment on it. =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3419763673_253376 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
WG,

As a note, an updated version was posted with the NAT64 updates per comment= s in Paris.

As of now, we still have not changed th= e tone of the document from the "deploy IPv6" and "consider IPv4".  Als= o, there had been some comments from one of the contributors that would have= put stronger language round IPv6-only methods of operation (to the CPE) whi= ch would have operators potentially allow IPv4 to suffer in performance to p= romote IPv6 operation – this has not yet been included.

=
My personal opinion is that making IPv4 operate worse on purpose = when given other options is counterintuitive to the job of an operator. Othe= r opinions welcome.  

So basic points still re= main:

  • Deploy IPv6 as soon as you can
  • Pre= pare for IPv6 (training, architecture, protocols etc)
  • Do it with for= ward considerations of IPv6-only operation
  • Consider the duality of I= Pv4 and IPv6 when you choose transition technologies and path forward
    • Try and keep IP flows off transition techs to the best extent possible (co= st, scaling, performance benefits)
  • Operator can choose to deploy tra= nsition techs differently if they choose, but should be aware of consequence= s (cost, scale, performance)

Regards,

Victor K

Fro= m: Fred Baker <fred@cisco.com= >
Date: Sun, 13 May 2012 11:01:= 41 -0700
To: <v6ops@ietf.org>
Cc: = <v6ops-chairs@tools.= ietf.org>, Ron Bonica <ron@bonica.= org>
Subject: [v6ops] Remin= der: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC

The working group last call for this dra= ft announced last week continues for another week. Please feel free to comme= nt on it.

_____________________= __________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3419763673_253376-- From Tina.Tsou.Zouting@huawei.com Sun May 13 20:26:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2C021F84A1 for ; Sun, 13 May 2012 20:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdoj8vk2vtlP for ; Sun, 13 May 2012 20:26:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9821F8497 for ; Sun, 13 May 2012 20:26:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGD75115; Sun, 13 May 2012 23:26:54 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 13 May 2012 20:23:01 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Sun, 13 May 2012 20:23:01 -0700 From: Tina TSOU To: Mark Townsley Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: AQHNL9iYEJKix0ifpEKlx7IAMvUSbZbF9OEAgAAlV4CAAKPxgP//lA4egAAQt2CAAgKZAIAAPIJD Date: Mon, 14 May 2012 03:23:00 +0000 Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com><10e101cd3002$4917d960$db478c20$@com>, <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> <52F40CF6-7FD1-4E5C-8617-C885F1D7AE9E@huawei.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C393@XMB-RCD-109.cisco.com>, <7B93EA23-7A06-481D-9E97-7DE1DE12A76B@townsley.net> In-Reply-To: <7B93EA23-7A06-481D-9E97-7DE1DE12A76B@townsley.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8E89C0907784C17AA58E3C8E07AC48Dhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 03:26:55 -0000 --_000_C8E89C0907784C17AA58E3C8E07AC48Dhuaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In traditional 6RD scenarios, the IPv6 packets must be encapsulated into th= e IPv4 packets with DIP pointing to BR. So in traditional 6RD scenarios, th= e IPv6 packets must go through the BR. In Gateway Initiated 6RD scenarios, there is case that the packets do not g= o through the BR: IPv6 receiver and sender are connected to the same (GI 6RD) gateway, the pa= ckets are transported to sender and do not go through BR. Sent from my iPad On May 13, 2012, at 9:46 AM, "Mark Townsley" > wrote: On May 12, 2012, at 7:08 PM, Hemant Singh (shemant) wrote: From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Sent: Saturday, May 12, 2012 12:05 PM To: Hemant Singh (shemant) Cc: Dan Wing (dwing); Cameron Byrne; IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu >In what case the 6rd traffic does not go thru the BR? There is already a use case that an SP in the U.S. is considering to deploy= 6rd as. An additional route is added to the CPE router to have two 6rd CP= E=92s talk directly to each other rather than going thru the BR. What you describe above is standard RFC 5969 behavior. That is why rfc6204bis includes a bullet related to a =93user-configured= =94 CPE in the 6rd section. No, that bullet is there to override the standard RFC 5969 behavior and for= ce all traffic through the BR if configured to do so. - Mark Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_C8E89C0907784C17AA58E3C8E07AC48Dhuaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

In traditional 6RD scenarios, the IPv6 packets must be= encapsulated into the IPv4 packets with DIP pointing to BR. So in traditio= nal 6RD scenarios, the IPv6 packets must go through the BR.

 

In Gateway Initiated 6RD scenarios, there is case that= the packets do not go through the BR:

IPv6 receiver and sender are connected to the same (GI= 6RD) gateway, the packets are transported to sender and do not go through = BR.


Sent from my iPad

On May 13, 2012, at 9:46 AM, "Mark Townsley" <mark@townsley.net> wrote:


On May 12, 2012, at 7:08 PM, Hemant Singh (shemant) wrote:

=  
From: Tina TSOU [mailto:Tina.Tsou.Zou= ting@huawei.com] 
Sent: Saturday, Ma= y 12, 2012 12:05 PM
To: Hemant Singh (= shemant)
Cc: Dan Wing (dwin= g); Cameron Byrne; IPv6 Operations
Subject: Re: [v6op= s] 6204 bis and mtu
 
>In what case the 6rd traffic does not go thru the BR?
 
There is already a use case that = an SP in the U.S. is considering to deploy 6rd as.  An additional rout= e is added to the CPE router to have two 6rd CPE=92s talk directly to each = other rather than going thru the BR.  

What you describe above is standard RFC 5969 behavior. 

That is why rfc6204bis includes a= bullet related to a  =93user-configured=94 CPE in the 6rd section.

No, that bullet is there to override the standard RFC 5969 behavior an= d force all traffic through the BR if configured to do so.

- Mark

 
Hemant

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

--_000_C8E89C0907784C17AA58E3C8E07AC48Dhuaweicom_-- From lorenzo@google.com Sun May 13 20:53:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB7821F8532 for ; Sun, 13 May 2012 20:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.92 X-Spam-Level: X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.056, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPWiMCd4OGFf for ; Sun, 13 May 2012 20:53:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57ACF21F8510 for ; Sun, 13 May 2012 20:53:34 -0700 (PDT) Received: by yhq56 with SMTP id 56so4700022yhq.31 for ; Sun, 13 May 2012 20:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wmJnoqMTHOCIIfHN2zV6LoMauXtHVz+MKWbJ8sDxRLE=; b=dhh+Igq01chjFuISjD6EifU1nehXMjXmS7znS8kouTkzsZFBbaHj+Gdez2RSkGN16h z4niuDyAUZRNNIAwwop7w4Q9XvF3sSmsxGDcMEhIAnyos8gb/y5c5YN4nvhwQgwkkquy mihxDV2O4H0E5z7/lweHDWKLJrmKbLqW+9F76XBo6+U7i0lFfP5Stim6ghVTyw7gC4X/ heTZXwTqLVbDY9lZcvY0elpiKieNScnUmfL6E7K9/ZujNuz3rLwaEx1ANOplC2EXozOc Y1XBAJO/LE3efs5iRoJEepywoZ2yEmMaOt3UzSy7gbc43au97Als46krKUH6qqzKmD/O Mc8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=wmJnoqMTHOCIIfHN2zV6LoMauXtHVz+MKWbJ8sDxRLE=; b=S6z/R4A+3HtSkLuQQdFKx6icsfNa1gW/Sd5D8IFY/eE0sQv0bBg9iaBQrV21Q2UZvY TS5LRLfwY8yIRhvExXl413CVdo6hFysrddwjO6RXwcKcBMJaqHlAeVoA7cobYr3kmrhi DLJnH8kVSJLbdBFUgLzCvG+o1Y4i/aLcSiu8cIjmPgecxr2zNc6cqf1Att4nSNx60l3O Fv4hb/aAeDAm3g2Lq2osLk8PHOinvPPjmCHNi6jbwBLo6a/d/p8rD6B1jBagBifAu67C vwrWDPPbH0gnq/lLL+iuZtJtejBlvbzDuBFUIOFcbQpZPeAI32J9EgH5RhvHl3A/I01A +y2g== Received: by 10.42.166.194 with SMTP id p2mr2901596icy.19.1336967613666; Sun, 13 May 2012 20:53:33 -0700 (PDT) Received: by 10.42.166.194 with SMTP id p2mr2901585icy.19.1336967613463; Sun, 13 May 2012 20:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.196.206 with HTTP; Sun, 13 May 2012 20:53:13 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Mon, 14 May 2012 12:53:13 +0900 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=90e6ba6e8882ad3da704bff70739 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl98myWzJdncdiEpStJ+xTdqUQWue9qdyWsXuaAJbOV20rq7kQ+yEVLBK1U8a9Av9xBtwlsthhBu06tqxo7vnJKDQdo+Ix8cyglpPlySXlDw1aKHDHTn5coEZdwVMq67rd6UVPG Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 03:53:35 -0000 --90e6ba6e8882ad3da704bff70739 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 12, 2012 at 12:30 PM, Hemant Singh (shemant) wrote: > Here is proposed text. > > *The CPE router MUST support adjusting the MSS value of the TCP SYN > packets.* > * * > > The question now is where does the new bullet go? Should the text be > added to the DS-Lite section or the General Requirements section? > It should not go into the general requirements section, because inspecting every SYN packet has a performance cost, and is unnecessary for native IPv6 (which is what we're primarily designing for here. It's only really necessary for DS-lite. It's not necessary for 6rd because there are other ways to get around this issue (e.g., reduce the MTU in the RA to 1480). --90e6ba6e8882ad3da704bff70739 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 12, 2012 at 12:30 PM, Hemant Singh (= shemant) <shemant@cisco.com> wrote:

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">Here is proposed text.

Th= e CPE router MUST support adjusting the MSS value of the TCP SYN packets.

=

The question now is where does the new bullet= go?=A0 Should the text be added to the DS-Lite section or the General Requ= irements section?

It should not go into the general requirements sect= ion, because inspecting every SYN packet has a performance cost, and is=A0u= nnecessary for native IPv6 (which is what we're primarily designing for= here.

It's only really necessary for DS-lite. It's no= t necessary for 6rd because there are other ways to get around this issue (= e.g., reduce=A0the MTU in the RA to 1480).
--90e6ba6e8882ad3da704bff70739-- From lorenzo@google.com Sun May 13 21:34:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C12121F8510 for ; Sun, 13 May 2012 21:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=0.053, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aPROPcDdb0Y for ; Sun, 13 May 2012 21:34:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46B9021F84EA for ; Sun, 13 May 2012 21:34:43 -0700 (PDT) Received: by yenq13 with SMTP id q13so4676833yen.31 for ; Sun, 13 May 2012 21:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=H31NmPeTvEdymJlIU5C9ZJHCeNQJX1VrXhO8plzvY1U=; b=TY1b2HtQyM9SUjeE25Ugk72jEMpByZPf03xzUDsDuGDCbmT+WC3k2j2syQ4JyYFHXX WSgqFWeHkdVnRhcPyVIPa5EWAcXVbcx3jlymRtjVuH/XVcPxfAMi1qwzZCxFsqw+z9cc tYMfHCbmJ4Uw19wil8QNG9uqs7ZY9K2aJ80mAAMxuETXkdFYaKH0Cx4WbYRX1k8pYGsE FwXwXwbQVN2neV+YReHiXJ6RlDMrzwKnSlxInU4X/R8NDluBMCHDVpksVYx1KeC18inl R3cSs3SMl2SO/z4TrpREUnYZkWPhzFAngw/ruczLyL7FpMIgcLASEYv+pUXhuf48mo2K Xssg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=H31NmPeTvEdymJlIU5C9ZJHCeNQJX1VrXhO8plzvY1U=; b=kuD3USEKKmiHMwdAVK3qqzbZ29HpSBhitznwM+ZZPja4VjOhC927ve36bHG818Oxt7 H3Ag55msv2LtShAkIP0o3mxkdCi3s/zX+4w8YDI0zaA7ksXAx9MLGR0gIzGcOJz6lR1U KCe1YWyJ3fMZsYJKARrLmCYrOb3JwQxai0AFESCR+ONy5hK9axcuwzuABma5ZD1wElz9 w31AHTX/7t82VPyzR6RJzmkoPOVp654pkMRUWBpG4+ec4TX8ASpwYup209u4mSiWX2Dw rcO6Uo2lk9vq65a+cQOmUm+h+b2Cj5r762+Wt4PXfCt5ZUJVdzFJ/E6uLbytx8UMZXWy tWhg== Received: by 10.50.196.232 with SMTP id ip8mr3361874igc.50.1336970082566; Sun, 13 May 2012 21:34:42 -0700 (PDT) Received: by 10.50.196.232 with SMTP id ip8mr3361863igc.50.1336970082417; Sun, 13 May 2012 21:34:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.196.206 with HTTP; Sun, 13 May 2012 21:34:22 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> From: Lorenzo Colitti Date: Mon, 14 May 2012 13:34:22 +0900 Message-ID: To: Washam Fan Content-Type: multipart/alternative; boundary=14dae9341241d67dfe04bff79a48 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnJeyjv2U8+P0+PP7TNSEswCxr5Xl+gPr8TbT9ldEIEJEKFsA8v6C//35OMU/EGWc7MfgIMEeZaRZd/0h2aOVc+vyFJHq0+xPggdXVacdsDmn/TCDKE+A38VSW09eelCh7fsQbC Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 14 May 2012 04:34:46 -0000 --14dae9341241d67dfe04bff79a48 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 10, 2012 at 2:51 PM, Washam Fan wrote: > The CLAT SHOULD set itself as the DNS server > via DHCP or other means and proxy DNS queries for IPv4 and IPv6 > clients. > > I just don't get it why proxy IPv6 DNS traffic since there would no > translation applied to IPv6 traffic. Would it be correct to remove the > words 'and IPv6' of the sentence? > Agreed. On a phone that implements tethering, you might want to do this for other reasons, but I don't see anything in 464xlat that would require it. --14dae9341241d67dfe04bff79a48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 10, 2012 at 2:51 PM, Washam Fan <washam.fan@gmail.com> wrote:
=A0 The CLAT SHOULD set itself as the DNS server
=A0 via DHCP or other means and proxy DNS queries for IPv4 and IPv6
=A0 clients.

I just don't get it why proxy IPv6 DNS traffic since there would no
translation applied to IPv6 traffic. Would it be correct to remove the
words 'and IPv6' of the sentence?

Agreed. On a phone that implements tethering, you might want to do this = for other reasons, but I don't see anything in 464xlat that would requi= re it.
--14dae9341241d67dfe04bff79a48-- From lorenzo@google.com Sun May 13 21:43:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EBC21F8565 for ; Sun, 13 May 2012 21:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpJi5NF-oEq6 for ; Sun, 13 May 2012 21:43:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64A21F8549 for ; Sun, 13 May 2012 21:43:51 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8377709obb.31 for ; Sun, 13 May 2012 21:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=vL8+Pyk4fuoHFD5sNCRPYSwA2AdpU3JEX3pjFz5a4cg=; b=gKGFD665zMjcclhrAzxjX6DCbdN5abjivotWvljw+AUE6PY3DR15P9CpWB/A9LDVHz vH+AlkDIHmrfhpq6FMUcR4X3es9AK0jykkx/yqkfeYYkpOwpmdQB2Q5UL/15py71VcFj NsBrMANMIOjIheBaaBboJQln7CAjPVwi/+qDTCljWH14T1Zt67Bfn8pFggQ29pTITb4s s31Tih0eFf0TRe1AcEBZn7D2m3vPThQp9ZV8epp/+R8aamhKfyROFwUNimzEy9dmEULt sCCkjO2GbSAS71CH1/IOCL4AfkPYcg8fiQcrMju0JIbjNnF7IEdeRK265o3/o9xr+xTJ pzNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=vL8+Pyk4fuoHFD5sNCRPYSwA2AdpU3JEX3pjFz5a4cg=; b=Crfdokui0YciHUqxlVZ8tN2OWmniXZ6yRv+SY45kk0xxKBF3O+OTpZt8/D1fR26a/8 EEVQbS8B6opTi1dQAP6SrSoB8uFwiemPUziwAIWhjvQsd5Txr2YxfRRcrsePFPfdm4Ih QhsLkNEl7czgj6RHDWt/FSgYH1ceLpP77M/048kSEH66SbSNUDVhBJpTk1alyyS0bdRZ R3l6aSlz6aXoEuS+SJEjY/43jEDi/ZBxrAGufCieMa8LzRpkXynJbH4oKyO10qv8osF0 pls5ZHIigANr4JodrO7S+L2XEzCBau+emjhd2tJPET35lpmzwx19TCHqBrTlCkY06v4K B19g== Received: by 10.50.89.166 with SMTP id bp6mr3365960igb.69.1336970630694; Sun, 13 May 2012 21:43:50 -0700 (PDT) Received: by 10.50.89.166 with SMTP id bp6mr3365951igb.69.1336970630600; Sun, 13 May 2012 21:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.196.206 with HTTP; Sun, 13 May 2012 21:43:30 -0700 (PDT) In-Reply-To: <335C5D38-19A0-4F9D-80D5-7DF4FBFC9E7C@employees.org> References: <6E3CE2F2-4565-48D6-A3EA-837538A710DC@laposte.net> <09163042-6F3F-40BB-9C96-7CEDD0A5FF9E@employees.org> <335C5D38-19A0-4F9D-80D5-7DF4FBFC9E7C@employees.org> From: Lorenzo Colitti Date: Mon, 14 May 2012 13:43:30 +0900 Message-ID: To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=e89a8f3ba7a18316ad04bff7bbf1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnEP49ANzuxULmfO9qVEI3CE/zMJaCUU8LmguN+hntXB8jjVBTSHk8YgEYG4D4CMVAXey/fM5mj2Rexhsqm2/JK/+pLe0SW4nmdA5LFJaJHpSqGAHqscdXrgd4cOdZ5H3F9kHGb Cc: v6ops WG Subject: Re: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-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, 14 May 2012 04:43:56 -0000 --e89a8f3ba7a18316ad04bff7bbf1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 9, 2012 at 2:00 AM, Ole Tr=F8an wrote: > > The proposal is not for "removing the NAT44". It is to make the NAT44 a > MUST when the CNAT node acts as an IPv4 a router. > > this would still be an implementation choice. why prohibit an > implementation to do better, if it has been deployed with enough address > space? For what it's worth, +1 to Remi's arguments on simplicity. Increasing the possible number of modes of operation superlinearly complicates implementations and exponentially complicates interoperability testing. --e89a8f3ba7a18316ad04bff7bbf1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 9, 2012 at 2:00 AM, Ole Tr=F8an <otroan@employees.org> wrote:
> The proposal is not for "removing the NAT44&quo= t;. It is to make the NAT44 a MUST when the CNAT node acts as an IPv4 a rou= ter.

this would still be an implementation choice. why prohibit an impleme= ntation to do better, if it has been deployed with enough address space?

For what it's worth, +1 to Remi's arg= uments on simplicity. Increasing the possible number of modes of operation = superlinearly complicates implementations and exponentially complicates=A0i= nteroperability testing.
--e89a8f3ba7a18316ad04bff7bbf1-- From despres.remi@laposte.net Sun May 13 22:29:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1597B21F851A for ; Sun, 13 May 2012 22:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp3L79CGtx65 for ; Sun, 13 May 2012 22:29:08 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4FB21F84F0 for ; Sun, 13 May 2012 22:29:06 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5D4B794011C; Mon, 14 May 2012 07:28:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FAE313C.7060501@bogus.com> Date: Mon, 14 May 2012 07:28:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96CC8418-B586-4065-A571-EF64E58C2CF1@laposte.net> References: <4FAE313C.7060501@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 05:29:09 -0000 Le 2012-05-12 =E0 11:45, Joel jaeggli a =E9crit : > On 5/11/12 22:45 , Chris Donley wrote: >> I don't support MSS rewrite language in 6204bis. Most of our members = are >> considering solutions other than DS-Lite. I suggest that those who = are >> planning DS-Lite deployments talk with their vendors if they think = they >> need MSS rewrite support. >=20 > While I am unconvinced that we need to address this, I think the > rational expressed here is rather poor. What about having it with a MAY, to document the technical rationale = without making it a requirement? RD >=20 > If requirements for DS-Lite are not germain to cpe router deployment = it > wouldn't be represented in 6204bis. It is in fact not a feature of = 6204. >=20 > joel >=20 >>=20 >> Chris >>=20 >>=20 >>=20 >>=20 >> On 5/11/12 9:22 AM, "Cameron Byrne" wrote: >>=20 >>> On Fri, May 11, 2012 at 7:19 AM, Chris Donley = >>> wrote: >>>> We did our testing on a DOCSIS network, which allows 1522 byte = frames. >>>> We >>>> did not enable MSS rewriting. >>>>=20 >>>=20 >>> If this issue is systemic for DOCSIS, and MSS rewrite is a known and >>> common solution, should 6204bis include language about MSS rewrite? >>=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 From Carl.Wuyts@technicolor.com Sun May 13 22:53:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D96221F857D for ; Sun, 13 May 2012 22:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgU2REvjcFc1 for ; Sun, 13 May 2012 22:53:18 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id EC49121F8562 for ; Sun, 13 May 2012 22:53:15 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT7CdyglZeWbQxapk0XB7VfUhLTQXc6C6@postini.com; Sun, 13 May 2012 22:53:17 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 14 May 2012 07:53:09 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 14 May 2012 07:53:13 +0200 From: Wuyts Carl To: Lorenzo Colitti , "Hemant Singh (shemant)" Date: Mon, 14 May 2012 07:53:12 +0200 Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0xhSqzjxWRoNYCTx6fknJayPEdfAAEDSdg Message-ID: <867F4B6A1672E541A94676D556793ACD10E22DB768@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD10E22DB768MOPESMBX01eut_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 05:53:19 -0000 --_000_867F4B6A1672E541A94676D556793ACD10E22DB768MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, same comment as often: Another CPE requirement ? What's next ? As agree with Lorenzo that this is a (potential) DSLite-only issue, not for= 6RD. So, why should this be done by the (very low cost, limited CPU/memor= y-powered) CPE device and not the (big, powerful, expensive) AFTR ? Regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L= orenzo Colitti Sent: maandag 14 mei 2012 5:53 To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu On Sat, May 12, 2012 at 12:30 PM, Hemant Singh (shemant) > wrote: Here is proposed text. The CPE router MUST support adjusting the MSS value of the TCP SYN packets. The question now is where does the new bullet go? Should the text be added= to the DS-Lite section or the General Requirements section? It should not go into the general requirements section, because inspecting = every SYN packet has a performance cost, and is unnecessary for native IPv6= (which is what we're primarily designing for here. It's only really necessary for DS-lite. It's not necessary for 6rd because = there are other ways to get around this issue (e.g., reduce the MTU in the = RA to 1480). --_000_867F4B6A1672E541A94676D556793ACD10E22DB768MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, sam= e comment as often: Another CPE requirement ?

What’s next ? 

 

As agree with Lorenzo that this is a (potential) DSLite-only issue, not f= or 6RD.  So, why should this be done by the (very low cost, limited CP= U/memory-powered) CPE device and not the (big, powerful, expensive) AFTR ? =

 <= /p>

Regs

Carl

 

From: v6ops-bounces@ietf.org [mailto:v= 6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: = maandag 14 mei 2012 5:53
To: Hemant Singh (shemant)
Cc:= IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu=

 

On Sat, May 12, 2012 at 12:30 PM, Hemant Singh (shemant) <shemant@cisco.com>= ; wrote:

Here is proposed text.

The CPE router MUST support adjusting the MSS value= of the TCP SYN packets.

The question now is where= does the new bullet go?  Should the text be added to the DS-Lite sect= ion or the General Requirements section?

It should not go into the general requireme= nts section, because inspecting every SYN packet has a performance cost, an= d is unnecessary for native IPv6 (which is what we're primarily design= ing for here.

 

It's only really necessary for DS-lit= e. It's not necessary for 6rd because there are other ways to get around th= is issue (e.g., reduce the MTU in the RA to 1480).

= --_000_867F4B6A1672E541A94676D556793ACD10E22DB768MOPESMBX01eut_-- From dr@cluenet.de Mon May 14 00:09:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92221F85A8 for ; Mon, 14 May 2012 00:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDeTRshTOL48 for ; Mon, 14 May 2012 00:09:24 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id CCC3C21F85A2 for ; Mon, 14 May 2012 00:09:23 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 215F6108407; Mon, 14 May 2012 09:09:21 +0200 (CEST) Date: Mon, 14 May 2012 09:09:21 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120514070921.GA6906@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 07:09:24 -0000 On Mon, May 14, 2012 at 12:53:13PM +0900, Lorenzo Colitti wrote: > It's only really necessary for DS-lite. It's not necessary for 6rd because > there are other ways to get around this issue (e.g., reduce the MTU in the > RA to 1480). PLEASE don't spread the idea of playing with the LAN MTU to cope for any WAN interface related issues. I've just managed to convince one CPE vendor to NOT arbitrarily mock around with the LAN MTU. Proper PMTUD behaviour is what is being asked for. Not workarounds bouncing around with the LAN MTU. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Mon May 14 00:15:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DEC9E8008 for ; Mon, 14 May 2012 00:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWwsF-XQs8Da for ; Mon, 14 May 2012 00:15:51 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5DC9E8007 for ; Mon, 14 May 2012 00:15:51 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 938E8108407; Mon, 14 May 2012 09:15:50 +0200 (CEST) Date: Mon, 14 May 2012 09:15:50 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120514071550.GB6906@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E22DB768@MOPESMBX01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E22DB768@MOPESMBX01.eu.thmulti.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 07:15:51 -0000 On Mon, May 14, 2012 at 07:53:12AM +0200, Wuyts Carl wrote: > As agree with Lorenzo that this is a (potential) DSLite-only issue, > not for 6RD. So, why should this be done by the (very low cost, > limited CPU/memory-powered) CPE device and not the (big, powerful, > expensive) AFTR ? Because all the DSL CPEs already do it anyway, and distributing workload is a better idea in regard to scalability? If CPE (and AFTR) performance would be of any real concern, RFC6333 would have never mandated RFC2473 behaviour (specifically section 7.2b). That is a real performance killer (and DoS vector). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From ichiroumakino@gmail.com Mon May 14 01:47:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B349A21F85AA for ; Mon, 14 May 2012 01:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6crdhzqOtS6I for ; Mon, 14 May 2012 01:47:58 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE6B921F85A4 for ; Mon, 14 May 2012 01:47:57 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so1191974wib.13 for ; Mon, 14 May 2012 01:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9MXqbVBTEVLWPaYRU4VuTbXPHNriqTl0xB5DZ3AUjtw=; b=A4K7upFipOyGSyB2pirfI/RKeaDiaATL7p5GfrfIG5C8PzkNhtMQp9nHNzg9RxJ6FQ nhQznr+OIcVcn/Uv0jUb76zy8f16iEQKX7fzZKAmsmXkLH369qQ6mD/PDRZ4o/Rzwc8d 89fgwWAQQnJKHDGTbgZ5l0Ca/sonVX20S8DXWFv34CJu8cDMwpH3zMTYW57awIJQW5w5 X0uX7BA52PEEBOlCLio2T3t2dLiprLNxjxzxuf/YzoPmzCdlksDsiGrtHflYXbsVy/eP SGmnZ1Pb7QMRCBzB1pgeBZZzmpHO/JJHwbML/5j6Ix5fN7aCmght45CfFEYmwvKZ5yrc z4CQ== Received: by 10.216.134.14 with SMTP id r14mr4765980wei.17.1336985277143; Mon, 14 May 2012 01:47:57 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fl2sm52996713wib.2.2012.05.14.01.47.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 01:47:56 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 14 May 2012 10:47:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F1F03B5-4219-4AC6-AAAF-7B7AB5881DB2@employees.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com><10e101cd3002$4917d960$db478c20$@com>, <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> <52F40CF6-7FD1-4E5C-8617-C885F1D7AE9E@huawei.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C393@XMB-RCD-109.cisco.com>, <7B93EA23-7A06-481D-9E97-7DE1DE12A76B@townsley.net> To: Tina TSOU X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 08:47:58 -0000 Tina, > In traditional 6RD scenarios, the IPv6 packets must be encapsulated = into the IPv4 packets with DIP pointing to BR. So in traditional 6RD = scenarios, the IPv6 packets must go through the BR. incorrect. you have misunderstood how 6rd works. 6rd is a mesh mode = tunnel. cheers, Ole From gert@space.net Mon May 14 02:00:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8C21F85F8 for ; Mon, 14 May 2012 02:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWRMCDp8IM99 for ; Mon, 14 May 2012 02:00:38 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9819A21F848F for ; Mon, 14 May 2012 02:00:37 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 4C25FF8AF5 for ; Mon, 14 May 2012 11:00:36 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3A808F8AE6 for ; Mon, 14 May 2012 11:00:36 +0200 (CEST) Received: (qmail 66139 invoked by uid 1007); 14 May 2012 11:00:36 +0200 Date: Mon, 14 May 2012 11:00:36 +0200 From: Gert Doering To: v6ops@ietf.org Message-ID: <20120514090036.GK84425@Space.Net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120514070921.GA6906@srv03.cluenet.de> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 09:00:39 -0000 Hi, On Mon, May 14, 2012 at 09:09:21AM +0200, Daniel Roesen wrote: > PLEASE don't spread the idea of playing with the LAN MTU to cope for any > WAN interface related issues. I've just managed to convince one CPE > vendor to NOT arbitrarily mock around with the LAN MTU. > > Proper PMTUD behaviour is what is being asked for. Not workarounds > bouncing around with the LAN MTU. Seconded. Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From shemant@cisco.com Mon May 14 04:58:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269CA21F85A5 for ; Mon, 14 May 2012 04:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.45 X-Spam-Level: X-Spam-Status: No, score=-10.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X5X9SvPnP+y for ; Mon, 14 May 2012 04:58:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 939E321F8589 for ; Mon, 14 May 2012 04:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=11574; q=dns/txt; s=iport; t=1336996709; x=1338206309; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=8haAXPw9mBKC/NmIDMl7GOtZUNV30WJ+elQcUNWzFwA=; b=hc4CNbzmu6etrPoEnMQDxFtIDGduH4SesdG9dlpqdIE04XueQKhj5tJe emtdURpYmxwkrVnU+9aQdPoRZ9ifDj62BiOvIAoGEVBO8RT5psBMtgPOD sNJJmaEMw6L7H1QMUvfjyJqHVtIGmzYHT+F0wpIKu8x0xI8l+f8Kymw+S c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADvysE+tJXG//2dsb2JhbABEgkaxLIEHghUBAQEEEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQTCBqHbJpXn2KLGoUlYwSIZJtwgWmDBw X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208,217";a="82975213" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 14 May 2012 11:58:29 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4EBwTd3026457; Mon, 14 May 2012 11:58:29 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 06:58:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD31C8.DFF09016" Date: Mon, 14 May 2012 06:58:27 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0xhSiNdjAfDOGMTy2YrDQNfaJumwAPbgcg References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" X-OriginalArrivalTime: 14 May 2012 11:58:28.0746 (UTC) FILETIME=[E0269EA0:01CD31C8] Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 11:58:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD31C8.DFF09016 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Sunday, May 13, 2012 11:53 PM To: Hemant Singh (shemant) Cc: Cameron Byrne; IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu =20 >It should not go into the general requirements section, because inspecting every SYN packet has a performance cost, and >is unnecessary for native IPv6 (which is what we're primarily designing for here. =20 The CPE is a device that already supports a stateful firewall that ends up inspecting every packet and parsing the packet to maintain state. It's no big deal for such a CPE to edit MSS statelessly for packets traversing the CPE. The CPE also adds the MSS option when originating/terminating any TCP client connection. If a knob is needed on the CPE to not do dynamic MSS editing, that be fine too. =20 >It's only really necessary for DS-lite. It's not necessary for 6rd because there are other ways to get around this issue (e.g., >reduce the MTU in the RA to 1480). =20 If you speak of the RA, note, the RA from the SP to the CPE is present in the DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 tunnel. The CPE does not see any RA from the SP in the 6rd case. =20 Additionally, note in the case where 6rd can have CPEs communicated by going thru the BR, the BR suffices to clamp the MSS per protocol. In the case when 6rd has the two CPE's communicate directly, then the CPE has to clamp the MSS per protocol. The examples of protocols are PPPOE, PPP, Ethernet etc. Based on what routes are configured on the CPE, the CPE does know if the CPE is communicating directly or thru the BR in 6rd mode.=20 =20 Back to what the DS-Lite problem is. Thanks to Daniel Rosen for pointing it out. DS-Lite mandates RFC 2473, section 7.2 behavior. That behavior means the tunnel gets fragmented not the payload. Thus now the AFTR and the CPE perform fragmentation and reassembly. =20 =20 Hemant ------_=_NextPart_001_01CD31C8.DFF09016 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Lorenzo Colitti = [mailto:lorenzo@google.com]
Sent: Sunday, May 13, 2012 11:53 = PM
To: Hemant Singh (shemant)
Cc: Cameron Byrne; = IPv6 Operations
Subject: Re: [v6ops] 6204 bis and = mtu

 

>It should not go into the general = requirements section, because inspecting every SYN packet has a = performance cost, and >is unnecessary for native IPv6 = (which is what we're primarily designing for = here.

 

The CPE is a device that already supports a stateful firewall that = ends up inspecting every packet and parsing the packet to maintain = state.   It’s no big deal for such a CPE to edit MSS = statelessly for packets traversing the CPE.   The CPE also = adds the MSS option when originating/terminating any TCP client = connection.    If a knob is needed on the CPE to not do = dynamic MSS editing, that be fine too.

 

>It's only really necessary for = DS-lite. It's not necessary for 6rd because there are other ways to get = around this issue (e.g., >reduce the MTU in the RA to = 1480).

 

If you speak of the RA, note, the RA from the SP to the CPE is = present in the DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 = tunnel.  The CPE does not see any RA from the SP in the 6rd = case.

 

Additionally, note in the case where 6rd can have CPEs communicated = by going thru the BR, the BR suffices to clamp the MSS per = protocol.  In the case when 6rd has the two CPE’s communicate = directly, then the CPE has to clamp the MSS per protocol.  The = examples of protocols are PPPOE, PPP, Ethernet etc.   Based on = what routes are configured on the CPE, the CPE does know if the CPE is = communicating directly or thru the BR in 6rd mode. =

 

Back to what the DS-Lite problem is.  Thanks to Daniel Rosen for = pointing it out.  DS-Lite mandates RFC 2473, section 7.2 = behavior.  That behavior means the tunnel gets fragmented not the = payload.  Thus now the  AFTR and the CPE perform fragmentation = and reassembly.  

 

Hemant

------_=_NextPart_001_01CD31C8.DFF09016-- From Carl.Wuyts@technicolor.com Mon May 14 05:18:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA7A21F85FC for ; Mon, 14 May 2012 05:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VN6MTKcpgaF for ; Mon, 14 May 2012 05:18:53 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 420BF21F8600 for ; Mon, 14 May 2012 05:18:51 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKT7D4KlwR4WCzjy5qdjq4gHg9hBXpcdWG@postini.com; Mon, 14 May 2012 05:18:53 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 14 May 2012 14:17:32 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 14 May 2012 14:17:37 +0200 From: Wuyts Carl To: "Hemant Singh (shemant)" , Lorenzo Colitti Date: Mon, 14 May 2012 14:17:36 +0200 Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0xhSiNdjAfDOGMTy2YrDQNfaJumwAPbgcgAAH8CPA= Message-ID: <867F4B6A1672E541A94676D556793ACD10E22DB9F6@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD10E22DB9F6MOPESMBX01eut_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 12:18:55 -0000 --_000_867F4B6A1672E541A94676D556793ACD10E22DB9F6MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I still feel that: 1. Proper path MTU discovery should be the target, so proper MTU disc= overy must be in place 2. If you want to do something on TCP MSS, do it on the PE side, not = on the CPE. It always seems to be "no big deal for the CPE", but still it = is. Besides that, some people feel this should be configurable. Really ? You = expect the avg user to be able to do so ? I think some people expect too m= uch. The end-user typically is interested in connectivity, so doesn't need= to know about IPv4, or IPv6 or a tunnel, or..., let alone to expect him to= enable MSS at some point in time ?? regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: maandag 14 mei 2012 13:58 To: Lorenzo Colitti Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Sunday, May 13, 2012 11:53 PM To: Hemant Singh (shemant) Cc: Cameron Byrne; IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu >It should not go into the general requirements section, because inspecting= every SYN packet has a performance cost, and >is unnecessary for native IP= v6 (which is what we're primarily designing for here. The CPE is a device that already supports a stateful firewall that ends up = inspecting every packet and parsing the packet to maintain state. It's no= big deal for such a CPE to edit MSS statelessly for packets traversing the= CPE. The CPE also adds the MSS option when originating/terminating any T= CP client connection. If a knob is needed on the CPE to not do dynamic M= SS editing, that be fine too. >It's only really necessary for DS-lite. It's not necessary for 6rd because= there are other ways to get around this issue (e.g., >reduce the MTU in th= e RA to 1480). If you speak of the RA, note, the RA from the SP to the CPE is present in t= he DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 tunnel. The C= PE does not see any RA from the SP in the 6rd case. Additionally, note in the case where 6rd can have CPEs communicated by goin= g thru the BR, the BR suffices to clamp the MSS per protocol. In the case = when 6rd has the two CPE's communicate directly, then the CPE has to clamp = the MSS per protocol. The examples of protocols are PPPOE, PPP, Ethernet e= tc. Based on what routes are configured on the CPE, the CPE does know if = the CPE is communicating directly or thru the BR in 6rd mode. Back to what the DS-Lite problem is. Thanks to Daniel Rosen for pointing i= t out. DS-Lite mandates RFC 2473, section 7.2 behavior. That behavior mea= ns the tunnel gets fragmented not the payload. Thus now the AFTR and the = CPE perform fragmentation and reassembly. Hemant --_000_867F4B6A1672E541A94676D556793ACD10E22DB9F6MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I still f= eel that:

1. = ;      Prop= er path MTU discovery should be the target, so proper MTU discovery must be= in place

2. = ;      If y= ou want to do something on TCP MSS, do it on the PE side, not on the CPE.&n= bsp; It always seems to be “no big deal for the CPE”, but still= it is.

 =

Besides that, some people feel this = should be configurable.  Really ?  You expect the avg user to be = able to do so ?  I think some people expect too much.  The end-us= er typically is interested in connectivity, so doesn’t need to know a= bout IPv4, or IPv6 or a tunnel, or…, let alone to expect him to enabl= e MSS at some point in time ??

 

regs

Carl

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Be= half Of Hemant Singh (shemant)
Sent: maandag 14 mei 2012 13:5= 8
To: Lorenzo Colitti
Cc: IPv6 Operations
Subject= : Re: [v6ops] 6204 bis and mtu

 

 

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Sunday, May 13, 2012 1= 1:53 PM
To: Hemant Singh (shemant)
Cc: Cameron Byrne; I= Pv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

>It should not go into the general requirements secti= on, because inspecting every SYN packet has a performance cost, and >is unnecessary for native IPv6 (whic= h is what we're primarily designing for here.

 

The CPE is a d= evice that already supports a stateful firewall that ends up inspecting eve= ry packet and parsing the packet to maintain state.   It’s = no big deal for such a CPE to edit MSS statelessly for packets traversing t= he CPE.   The CPE also adds the MSS option when originating/termi= nating any TCP client connection.    If a knob is needed on = the CPE to not do dynamic MSS editing, that be fine too.<= /p>

 

>= ;It's only really necessar= y for DS-lite. It's not necessary for 6rd because there are other ways to g= et around this issue (e.g., >reduce=  the MTU in the RA to 1480).<= /span>

 

If you speak of the RA, note, the RA from the SP = to the CPE is present in the DS-Lite case because DS-Lite tunnels IPv4 data= in an IPv6 tunnel.  The CPE does not see any RA from the SP in the 6r= d case.

 <= /span>

Additionally, note in the case where = 6rd can have CPEs communicated by going thru the BR, the BR suffices to cla= mp the MSS per protocol.  In the case when 6rd has the two CPE’s= communicate directly, then the CPE has to clamp the MSS per protocol. = ; The examples of protocols are PPPOE, PPP, Ethernet etc.   Based= on what routes are configured on the CPE, the CPE does know if the CPE is = communicating directly or thru the BR in 6rd mode.

 

= Back to what the DS-Lite problem is.  Thanks to Daniel Rosen fo= r pointing it out.  DS-Lite mandates RFC 2473, section 7.2 behavior.&n= bsp; That behavior means the tunnel gets fragmented not the payload.  = Thus now the  AFTR and the CPE perform fragmentation and reassembly.&n= bsp; 

 

Hemant

= --_000_867F4B6A1672E541A94676D556793ACD10E22DB9F6MOPESMBX01eut_-- From despres.remi@laposte.net Mon May 14 05:24:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569FA21F8646 for ; Mon, 14 May 2012 05:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnI5B1CiIbfe for ; Mon, 14 May 2012 05:24:26 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 96DF221F84B2 for ; Mon, 14 May 2012 05:24:23 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 748E194014F; Mon, 14 May 2012 14:24:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120514090036.GK84425@Space.Net> Date: Mon, 14 May 2012 14:24:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> <20120514090036.GK84425@Space.Net> To: v6ops WG X-Mailer: Apple Mail (2.1084) Cc: Daniel Roesen Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 12:24:26 -0000 Le 2012-05-14 =E0 11:00, Gert Doering a =E9crit : > On Mon, May 14, 2012 at 09:09:21AM +0200, Daniel Roesen wrote: ... >> Proper PMTUD behaviour is what is being asked for. +1 (In particular, ICMP-PTB forwarding needs to be treated everywhere as a = real MUST.)=20 It remains that MSS rewrite is a simple and effective way to avoid, for = TCP, consequences of wrong supports of PMTU-PTB. As such it is a nice-to-have feature. Suggestion (already made to Joel on another thread): document it in = 6204bis (a good opportunity for that), but only as a MAY. =20 RD From despres.remi@laposte.net Mon May 14 05:49:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906F721F861A for ; Mon, 14 May 2012 05:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNOwkGL81-qB for ; Mon, 14 May 2012 05:49:28 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 381FD21F864B for ; Mon, 14 May 2012 05:49:26 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id E049A9401BA; Mon, 14 May 2012 14:49:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-30-62790636 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E22DB9F6@MOPESMBX01.eu.thmulti.com> Date: Mon, 14 May 2012 14:49:19 +0200 Message-Id: <8B88CAC3-0AFA-4C70-A18F-8FBBA4AF4E33@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E22DB9F6@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 12:49:29 -0000 --Apple-Mail-30-62790636 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-05-14 =E0 14:17, Wuyts Carl a =E9crit : > I still feel that: > 1. Proper path MTU discovery should be the target, so proper MTU = discovery must be in place > 2. If you want to do something on TCP MSS, do it on the PE side, = not on the CPE. It always seems to be =93no big deal for the CPE=94, = but still it is. > =20 > Besides that, some people feel this should be configurable. AFAIK, it doesn't need to be configurable: if a CPE has a SYN to = transmit on an interface, and if this interface MTU is insufficient to = avoid fragmentation of packets having the MSS contained in the SYN, it = can reduce this MSS to make sure no fragmentation will ever be needed = for this connection on this link. This can do some good, and CANNOT be = harmful. (MTUs are supposedly equal in both directions of the interface = link.) > Really ? You expect the avg user to be able to do so ? I think some = people expect too much.=20 > The end-user typically is interested in connectivity, so doesn=92t = need to know about IPv4, or IPv6 or a tunnel, or=85, Exactly. That's, in my understanding, what MSS achieves. That's why I suggest to document it, at least as a MAY in view of = objections heard to have it a MUST. Regards, RD > let alone to expect him to enable MSS at some point in time ?? > =20 > regs > Carl > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) > Sent: maandag 14 mei 2012 13:58 > To: Lorenzo Colitti > Cc: IPv6 Operations > Subject: Re: [v6ops] 6204 bis and mtu > =20 > =20 > From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Sent: Sunday, May 13, 2012 11:53 PM > To: Hemant Singh (shemant) > Cc: Cameron Byrne; IPv6 Operations > Subject: Re: [v6ops] 6204 bis and mtu > =20 > >It should not go into the general requirements section, because = inspecting every SYN packet has a performance cost, and >is unnecessary = for native IPv6 (which is what we're primarily designing for here. > =20 > The CPE is a device that already supports a stateful firewall that = ends up inspecting every packet and parsing the packet to maintain = state. It=92s no big deal for such a CPE to edit MSS statelessly for = packets traversing the CPE. The CPE also adds the MSS option when = originating/terminating any TCP client connection. If a knob is = needed on the CPE to not do dynamic MSS editing, that be fine too. > =20 > >It's only really necessary for DS-lite. It's not necessary for 6rd = because there are other ways to get around this issue (e.g., >reduce the = MTU in the RA to 1480). > =20 > If you speak of the RA, note, the RA from the SP to the CPE is present = in the DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 tunnel. = The CPE does not see any RA from the SP in the 6rd case. > =20 > Additionally, note in the case where 6rd can have CPEs communicated by = going thru the BR, the BR suffices to clamp the MSS per protocol. In = the case when 6rd has the two CPE=92s communicate directly, then the CPE = has to clamp the MSS per protocol. The examples of protocols are PPPOE, = PPP, Ethernet etc. Based on what routes are configured on the CPE, the = CPE does know if the CPE is communicating directly or thru the BR in 6rd = mode. > =20 > Back to what the DS-Lite problem is. Thanks to Daniel Rosen for = pointing it out. DS-Lite mandates RFC 2473, section 7.2 behavior. That = behavior means the tunnel gets fragmented not the payload. Thus now the = AFTR and the CPE perform fragmentation and reassembly. =20 > =20 > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-30-62790636 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I still feel that:
       Proper path MTU discovery should be the target, so = proper MTU discovery must be in place
       If you want to do something on TCP MSS, do it on the = PE side, not on the CPE.  It always seems to be =93no big deal for = the CPE=94, but still it is.
Besides that, some people feel this should be = configurable. =

AFAIK, = it doesn't need to be configurable: if a CPE has a SYN to transmit = on an interface, and if this interface MTU is insufficient to avoid = fragmentation of packets having the MSS contained in the SYN, it = can reduce this MSS to make sure no fragmentation will ever be needed = for this connection on this link. This can do some good, and CANNOT = be harmful. (MTUs are supposedly equal in both directions of the = interface link.)

Really ?  You expect the avg user to be able to = do so ?  I think some people expect too much.  =


The end-user typically is interested in = connectivity, so doesn=92t need to know about IPv4, or IPv6 or a tunnel, = or=85,

Exa= ctly. That's, in my understanding, what MSS achieves.
That's = why I suggest to document it, at least as a MAY in view of objections = heard to have it a = MUST.

Regards,
RD

<= div>

let alone to expect him to enable MSS at some point = in time ??
 
regs
Carl
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Hemant Singh = (shemant)
Sent: maandag 14 mei 2012 = 13:58
To: Lorenzo = Colitti
Cc: IPv6 = Operations
Subject: Re: [v6ops] 6204 bis and = mtu
From: Lorenzo Colitti [mailto:lorenzo@google.com] 
Sent: Sunday, May 13, 2012 11:53 = PM
To: Hemant = Singh (shemant)
Cc: Cameron Byrne; IPv6 = Operations
Subject: Re: [v6ops] 6204 bis and = mtu
It should not = go into the general requirements section, because inspecting every SYN = packet has a performance cost, and >is unnecessary for native IPv6 = (which is what we're primarily designing for = here.
The CPE is a device that already supports a stateful = firewall that ends up inspecting every packet and parsing the packet to = maintain state.   It=92s no big deal for such a CPE to edit = MSS statelessly for packets traversing the CPE.   The CPE also = adds the MSS option when originating/terminating any TCP client = connection.    If a knob is needed on the CPE to not do = dynamic MSS editing, that be fine too.
It's only = really necessary for DS-lite. It's not necessary for 6rd because there = are other ways to get around this issue (e.g., >reduce the MTU in the RA to = 1480). 
If you speak of the RA, note, the = RA from the SP to the CPE is present in the DS-Lite case because DS-Lite = tunnels IPv4 data in an IPv6 tunnel.  The CPE does not see any RA = from the SP in the 6rd case.
Additionally, note in the case where 6rd can have = CPEs communicated by going thru the BR, the BR suffices to clamp the MSS = per protocol.  In the case when 6rd has the two CPE=92s communicate = directly, then the CPE has to clamp the MSS per protocol.  The = examples of protocols are PPPOE, PPP, Ethernet etc.   Based on = what routes are configured on the CPE, the CPE does know if the CPE is = communicating directly or thru the BR in 6rd = mode.
 
Back to what the DS-Lite problem = is.  Thanks to Daniel Rosen for pointing it out.  DS-Lite = mandates RFC 2473, section 7.2 behavior.  That behavior means the = tunnel gets fragmented not the payload.  Thus now the  AFTR = and the CPE perform fragmentation and = reassembly.  
 
v6ops@ietf.org
Content-Type: multipart/alternative; boundary=e89a8f838db147efcf04bffe9b9b X-System-Of-Record: true X-Gm-Message-State: ALoCoQnCRhzryE9pU4Yq3Co4pNZpF16fU64RzkCjIPgE4LHsEiZYLUrfTWVVtklesGRZFs2Pk1EXkUsCxTkF5agUq/8OVcgS4j2KHDoSdQP8vjjP56hVmT6AfCnmJJb7vRDQnx9j/Ghr Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 12:55:55 -0000 --e89a8f838db147efcf04bffe9b9b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2012 at 8:58 PM, Hemant Singh (shemant) wrote: > >It should not go into the general requirements section, because > inspecting every SYN packet has a performance cost, and >is unnecessary > for native IPv6 (which is what we're primarily designing for here. > > ** ** > > The CPE is a device that already supports a stateful firewall that ends u= p > inspecting every packet and parsing the packet to maintain state. It=92= s no > big deal for such a CPE to edit MSS statelessly for packets traversing th= e > CPE. The CPE also adds the MSS option when originating/terminating any > TCP client connection. If a knob is needed on the CPE to not do dynami= c > MSS editing, that be fine too. > In IPv4, you always have to do stateful inspection because of NAT. In IPv6, not necessarily. My CPE will do 480 Mbps with the firewall off and 280 Mbps with the firewall on. I'd like to avoid the performance hit, please. --e89a8f838db147efcf04bffe9b9b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, May 14, 2012 at 8:58 PM, Hemant Singh (s= hemant) <shemant@cisco.com> wrote:

<= span style=3D"font-family:'Courier New';color:rgb(31,73,125)">><= /span>It should not go in= to the general requirements section, because inspecting every SYN packet ha= s a performance cost, and >is=A0unn= ecessary for native IPv6 (which is what we're primarily designing for h= ere.

=A0

= The CPE is a device that already supports a stat= eful firewall that ends up inspecting every packet and parsing the packet t= o maintain state.=A0 =A0It=92s no big deal for such a CPE to edit MSS state= lessly for packets traversing the CPE.=A0 =A0The CPE also adds the MSS opti= on when originating/terminating any TCP client connection.=A0 =A0=A0If a kn= ob is needed on the CPE to not do dynamic MSS editing, that be fine too.


In IPv4, you always have= to do stateful inspection because of NAT. In IPv6, not necessarily.=A0My C= PE will do 480 Mbps with the firewall off and 280 Mbps with the firewall on= . I'd like to avoid the performance hit, please.
--e89a8f838db147efcf04bffe9b9b-- From Carl.Wuyts@technicolor.com Mon May 14 05:56:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E05421F861A for ; Mon, 14 May 2012 05:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCNUxD6sdDAe for ; Mon, 14 May 2012 05:56:25 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id 29C8B21F8452 for ; Mon, 14 May 2012 05:56:21 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKT7EA83tfu54IzP7sPzO8az0MTd9HV4Bm@postini.com; Mon, 14 May 2012 05:56:24 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 14 May 2012 14:54:31 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 14 May 2012 14:54:36 +0200 From: Wuyts Carl To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Mon, 14 May 2012 14:54:35 +0200 Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0x0AHB8NMropDgSlyhHjbSvFbwJwAABqfQ Message-ID: <867F4B6A1672E541A94676D556793ACD10E22DBA31@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E22DB9F6@MOPESMBX01.eu.thmulti.com> <8B88CAC3-0AFA-4C70-A18F-8FBBA4AF4E33@laposte.net> In-Reply-To: <8B88CAC3-0AFA-4C70-A18F-8FBBA4AF4E33@laposte.net> 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_867F4B6A1672E541A94676D556793ACD10E22DBA31MOPESMBX01eut_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 12:56:28 -0000 --_000_867F4B6A1672E541A94676D556793ACD10E22DBA31MOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A "MAY" might indeed be acceptable, for sure no MUST. But still proper path MTU should be the target to avoid MTU-issues down the= link. I've already had customers complaining we did not do ok on some PPP links. = In the end it was always some ICMPv6 getting dropped somewhere down the pa= th. As a "work-around", PPP MTU got increased with 8 bytes, so supporting = larger MTU can do the trick as well from time to time, although this of cou= rse did not fix the broken path MTU discovery itself. Regs Carl From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] Sent: maandag 14 mei 2012 14:49 To: Wuyts Carl Cc: Hemant Singh (shemant); Lorenzo Colitti; IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu Le 2012-05-14 =E0 14:17, Wuyts Carl a =E9crit : I still feel that: 1. Proper path MTU discovery should be the target, so proper MTU disc= overy must be in place 2. If you want to do something on TCP MSS, do it on the PE side, not = on the CPE. It always seems to be "no big deal for the CPE", but still it = is. Besides that, some people feel this should be configurable. AFAIK, it doesn't need to be configurable: if a CPE has a SYN to transmit o= n an interface, and if this interface MTU is insufficient to avoid fragment= ation of packets having the MSS contained in the SYN, it can reduce this MS= S to make sure no fragmentation will ever be needed for this connection on = this link. This can do some good, and CANNOT be harmful. (MTUs are supposed= ly equal in both directions of the interface link.) Really ? You expect the avg user to be able to do so ? I think some peopl= e expect too much. The end-user typically is interested in connectivity, so doesn't need to kn= ow about IPv4, or IPv6 or a tunnel, or..., Exactly. That's, in my understanding, what MSS achieves. That's why I suggest to document it, at least as a MAY in view of objection= s heard to have it a MUST. Regards, RD let alone to expect him to enable MSS at some point in time ?? regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: maandag 14 mei 2012 13:58 To: Lorenzo Colitti Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Sunday, May 13, 2012 11:53 PM To: Hemant Singh (shemant) Cc: Cameron Byrne; IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu >It should not go into the general requirements section, because inspecting= every SYN packet has a performance cost, and >is unnecessary for native IP= v6 (which is what we're primarily designing for here. The CPE is a device that already supports a stateful firewall that ends up = inspecting every packet and parsing the packet to maintain state. It's no= big deal for such a CPE to edit MSS statelessly for packets traversing the= CPE. The CPE also adds the MSS option when originating/terminating any T= CP client connection. If a knob is needed on the CPE to not do dynamic M= SS editing, that be fine too. >It's only really necessary for DS-lite. It's not necessary for 6rd because= there are other ways to get around this issue (e.g., >reduce the MTU in th= e RA to 1480). If you speak of the RA, note, the RA from the SP to the CPE is present in t= he DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 tunnel. The C= PE does not see any RA from the SP in the 6rd case. Additionally, note in the case where 6rd can have CPEs communicated by goin= g thru the BR, the BR suffices to clamp the MSS per protocol. In the case = when 6rd has the two CPE's communicate directly, then the CPE has to clamp = the MSS per protocol. The examples of protocols are PPPOE, PPP, Ethernet e= tc. Based on what routes are configured on the CPE, the CPE does know if = the CPE is communicating directly or thru the BR in 6rd mode. Back to what the DS-Lite problem is. Thanks to Daniel Rosen for pointing i= t out. DS-Lite mandates RFC 2473, section 7.2 behavior. That behavior mea= ns the tunnel gets fragmented not the payload. Thus now the AFTR and the = CPE perform fragmentation and reassembly. Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_867F4B6A1672E541A94676D556793ACD10E22DBA31MOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A “= MAY” might indeed be acceptable, for sure no MUST.=A0

 

But still proper path MTU should be the target to avoid MTU= -issues down the link.

I&#= 8217;ve already had customers complaining we did not do ok on some PPP link= s.=A0 In the end it was always some ICMPv6 getting dropped somewhere down t= he path. =A0As a “work-around”, PPP MTU got increased with 8 by= tes, so supporting larger MTU can do the trick as well from time to time, a= lthough this of course did not fix the broken path MTU discovery itself.

 

=

Regs

= Carl

 

From: R=E9mi Despr=E9s [mail= to:despres.remi@laposte.net]
Sent: maandag 14 mei 2012 14:49
= To: Wuyts Carl
Cc: Hemant Singh (shemant); Lorenzo Colitti= ; IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

 

 

Le 2012-05= -14 =E0 14:17, Wuyts Carl a =E9crit :



I still fe= el that:

1.       Proper path MTU = discovery should be the target, so proper MTU discovery must be in place

2.       If you want to do something o= n TCP MSS, do it on the PE side, not on the CPE.  It always seems to b= e “no big deal for the CPE”, but still it is.=

 

Besides that, some people feel this shou= ld be configurable.

 

AFAIK, it doesn't= need to be configurable: if a CPE has a SYN to transmit on an interfa= ce, and if this interface MTU is insufficient to avoid fragmentation o= f packets having the MSS contained in the SYN, it can reduce this MSS = to make sure no fragmentation will ever be needed for this connection on th= is link. This can do some good, and CANNOT be harmful. (MTUs are = supposedly equal in both directions of the interface link.)

<= /div>

 

Really ?  You expect the avg user to be able to do so ?  I t= hink some people expect too much. 

<= /blockquote>

 



T= he end-user typically is interested in connectivity, so doesn’t need = to know about IPv4, or IPv6 or a tunnel, or…,

 

Exactly. That's, in my understanding, what MSS achieves.=

That's why I suggest to document = it, at least as a MAY in view of objections heard to have it a MUST.

 

Regards,

RD=

 

<= div>

 


let alone to exp= ect him to enable MSS at some point in time ??

<= /div>
<= p class=3DMsoNormal> 

regs

Carl

=  

From: v6ops-bounces@ie= tf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant)
Sent: maandag 14 mei 2012 13:58
To:=  Lorenzo Colitti
= Cc: IPv6 Operations
= Subject: Re: [v6ops]= 6204 bis and mtu

 

 

<= p class=3DMsoNormal>From: Lorenzo Colitti [mailto:lorenzo@google.com] 
Sent: Sunday, May 13, 2012 11:53 PM
To: Hemant Singh (shemant)
Cc:=  Cameron Byrne; IPv6 Operat= ions
Subject: Re:= [v6ops] 6204 bis and mtu

 

>It should not go into the general requirements section, because inspe= cting every SYN packet has a performance cost, and >is un= necessary for native IPv6 (which is what we're primarily designing for here= .

 

=

The CPE is a device that already sup= ports a stateful firewall that ends up inspecting every packet and parsing = the packet to maintain state.   It’s no big deal for such a= CPE to edit MSS statelessly for packets traversing the CPE.   Th= e CPE also adds the MSS option when originating/terminating any TCP client = connection.    If a knob is needed on the CPE to not do dyna= mic MSS editing, that be fine too.

 

>= ;It's only really necessar= y for DS-lite. It's not necessary for 6rd because there are other ways to g= et around this issue (e.g., >reduce the MTU in the RA to = 1480).

 

If you speak of = the RA, note, the RA from the SP to the CPE is present in the DS-Lite case = because DS-Lite tunnels IPv4 data in an IPv6 tunnel.  The CPE does not= see any RA from the SP in the 6rd case.

 

Additionally, note in the case where 6rd can have CPEs = communicated by going thru the BR, the BR suffices to clamp the MSS per pro= tocol.  In the case when 6rd has the two CPE’s communicate direc= tly, then the CPE has to clamp the MSS per protocol.  The examples of = protocols are PPPOE, PPP, Ethernet etc.   Based on what routes ar= e configured on the CPE, the CPE does know if the CPE is communicating dire= ctly or thru the BR in 6rd mode.

 

Back to what the DS-Lite problem is.  Thanks to Daniel Ros= en for pointing it out.  DS-Lite mandates RFC 2473, section 7.2 behavi= or.  That behavior means the tunnel gets fragmented not the payload.&n= bsp; Thus now the  AFTR and the CPE perform fragmentation and reassemb= ly.  

 

Hemant<= /span>

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

 

= --_000_867F4B6A1672E541A94676D556793ACD10E22DBA31MOPESMBX01eut_-- From lorenzo@google.com Mon May 14 05:58:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F422E21F862A for ; Mon, 14 May 2012 05:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.052, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+S+71bqFzGE for ; Mon, 14 May 2012 05:58:16 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D143521F8627 for ; Mon, 14 May 2012 05:58:15 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1434683ggn.31 for ; Mon, 14 May 2012 05:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=DHTryMVah9qoursCaao3OmMa9aN4TiHJnqZv7uyrVPM=; b=YU6qhEt2ES0IM9Hl2edWw4JabWZrishQI3i9dOr2nqsHtmySULaGBh7jxHzl8YamRm mcFTZjzfxJHwLjd8ptFzsFI6bhP5AphQfE9Ui42t7+ZAzK9AOzGZnh6zyh8ujxQDb3j0 qGnIK//IQsrNCSwqxO56i6qsKPcZIOtDXZ8aBFULzqZJTfoQaddKALTxrdKlKL+Bt/j0 XbhYfeCeeAWz7J4+vpgIHIB6QpBg92IF7qcryD1aE4lpi0dFfuYNgNrOqDFI1lciQX01 pcxv7vhzVypKyy+U9Zl0SirRk1ZCwXafNjBnirBfm2+JsP9/RNHHWmOv8e0Jo9oh8PFk n5xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=DHTryMVah9qoursCaao3OmMa9aN4TiHJnqZv7uyrVPM=; b=ejz9iVRAgSlvqbLhmnyilDLg7942C230YFhiRLf3JQ28LB98fBWxx4K9pG+Xzn733L mUrkZNyHPvTT3HFaWotyqMC0Uok5vkFykQs6nkg+Qx+2dfmtowtROsQgRD/T4sIcD9ZF g/bAUi0Wp3bzGTaB54TiauvHx08O8vESBN8WjAwdb18meOB2CcJbv5MFmvjrGxQ2akMt OuFLUWNkt4M+pRVXvbtkoHrE92S2aOwDE5vM7/vD6r1pz08a5tf1QnKvXVxcVZKFLVBM 5mBRDSKjzS4RI6VZ61tyHD4ECGK6T2lMgjVQ5XQTL0zufxl67wNse9/ymCmiPNgr6QZY DeTA== Received: by 10.60.14.41 with SMTP id m9mr11547083oec.57.1337000295236; Mon, 14 May 2012 05:58:15 -0700 (PDT) Received: by 10.60.14.41 with SMTP id m9mr11547075oec.57.1337000295140; Mon, 14 May 2012 05:58:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Mon, 14 May 2012 05:57:55 -0700 (PDT) In-Reply-To: <20120514070921.GA6906@srv03.cluenet.de> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> From: Lorenzo Colitti Date: Mon, 14 May 2012 21:57:55 +0900 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1fac0a80e0304bffea31a X-System-Of-Record: true X-Gm-Message-State: ALoCoQlPgcWjQAcqHeU9wm8uObS0i+uYt9vPV1Xfp8TrOImp9F3Jw0hzDeaYPlcM5TiSgWKYcpuBw414Pl3l0JPZQkJfzTWUVqeLkLGlB++v/k5xF2agWzCzLtlAeE8GNtZ2P59qKxCo Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 12:58:17 -0000 --e89a8fb1fac0a80e0304bffea31a Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 14, 2012 at 4:09 PM, Daniel Roesen wrote: > On Mon, May 14, 2012 at 12:53:13PM +0900, Lorenzo Colitti wrote: > > It's only really necessary for DS-lite. It's not necessary for 6rd > because > > there are other ways to get around this issue (e.g., reduce the MTU in > the > > RA to 1480). > > PLEASE don't spread the idea of playing with the LAN MTU to cope for any > WAN interface related issues. I've just managed to convince one CPE > vendor to NOT arbitrarily mock around with the LAN MTU. > > Proper PMTUD behaviour is what is being asked for. Not workarounds > bouncing around with the LAN MTU. > PMTUD needs to work. Agreed. However, it's slow. Assuming no packets get dropped, it takes one round-trip time for every new host you connect to that's not in the cache. If you're a CPE whose only means of access to the Internet is a tunnel with an MTU of 1480, you can serve the hosts behind you better by sending out an RA with an MTU of 1480. --e89a8fb1fac0a80e0304bffea31a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 14, 2012 at 4:09 PM, Daniel Roesen <= span dir=3D"ltr"><dr@= cluenet.de> wrote:
On Mon, May 14, 2012 at 12:53:13PM +0900, Lorenzo Colitti= wrote:
> It's only really necessary for DS-lite. It's not necessary for= 6rd because
> there are other ways to get around this issue (e.g., reduce the MTU in= the
> RA to 1480).

PLEASE don't spread the idea of playing with the LAN MTU to cope = for any
WAN interface related issues. I've just managed to convince one CPE
vendor to NOT arbitrarily mock around with the LAN MTU.

Proper PMTUD behaviour is what is being asked for. Not workarounds
bouncing around with the LAN MTU.

PMTUD= needs to work. Agreed. However, it's slow. Assuming no packets get dro= pped, it takes one round-trip time for every new host you connect to that&#= 39;s not in the cache.

If you're a CPE whose only means of access to the I= nternet is a tunnel with an MTU of 1480, you can serve the hosts behind you= better by sending out an RA with an MTU of 1480.
--e89a8fb1fac0a80e0304bffea31a-- From hansliu@gmail.com Mon May 14 06:04:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7AC21F869E for ; Mon, 14 May 2012 06:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0nf2DtUlwDQ for ; Mon, 14 May 2012 06:04:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF0ED21F864D for ; Mon, 14 May 2012 06:04:31 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3738692lbb.31 for ; Mon, 14 May 2012 06:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H/bb8+XOwRAjYkGZCMXCFfcy+H8xn62z4TAR43YNFmE=; b=MJkYZpADQQbS2bxHjQC6d9k4p4/11xrLeGk22CeXRt5EEcvx8IRJC5wIw3kYhfEUfl 4k64yH9L74nHjARP8iuy9XUIsCod2KSqUCbrv7Eh2l2dDih6I4qfOTR/fujQaUHMva4A +hc/RUQQy/gHCiRqv/rKIuBkj+DNGB7z8A11xwLnaJaLAopiymKB0WmCey/PXpoqfbi7 sj7zI4p3PzJQg8JQaOWTjCC0XoyMwHywGTBXj01QIp7s8jXgoDwl/rOmndlc56s6kM/A 1BnlTns55cTj1sbSgaxA861Ota7cj1nLiSBEeO0tAgw4odgFFdZLB9a8RqvKWUIK0u/2 6XUw== MIME-Version: 1.0 Received: by 10.112.23.196 with SMTP id o4mr3622833lbf.49.1337000670684; Mon, 14 May 2012 06:04:30 -0700 (PDT) Received: by 10.112.43.8 with HTTP; Mon, 14 May 2012 06:04:30 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> Date: Mon, 14 May 2012 21:04:30 +0800 Message-ID: From: Hans Liu To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 13:04:32 -0000 Ack! It is not a big problem, and we actually support TCP MSS already for DS-Lite. Cheers, Hans On Mon, May 14, 2012 at 7:58 PM, Hemant Singh (shemant) wrote: > > > From: Lorenzo Colitti [mailto:lorenzo@google.com] > Sent: Sunday, May 13, 2012 11:53 PM > To: Hemant Singh (shemant) > Cc: Cameron Byrne; IPv6 Operations > Subject: Re: [v6ops] 6204 bis and mtu > > > >>It should not go into the general requirements section, because inspectin= g >> every SYN packet has a performance cost, and >is=C2=A0unnecessary for na= tive IPv6 >> (which is what we're primarily designing for here. > > > > The CPE is a device that already supports a stateful firewall that ends u= p > inspecting every packet and parsing the packet to maintain state.=C2=A0 = =C2=A0It=E2=80=99s no > big deal for such a CPE to edit MSS statelessly for packets traversing th= e > CPE.=C2=A0 =C2=A0The CPE also adds the MSS option when originating/termin= ating any TCP > client connection.=C2=A0 =C2=A0=C2=A0If a knob is needed on the CPE to no= t do dynamic MSS > editing, that be fine too. > > > >>It's only really necessary for DS-lite. It's not necessary for 6rd becaus= e >> there are other ways to get around this issue (e.g., >reduce=C2=A0the MT= U in the >> RA to 1480). > > > > If you speak of the RA, note, the RA from the SP to the CPE is present in > the DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 tunnel.=C2= =A0 The > CPE does not see any RA from the SP in the 6rd case. > > > > Additionally, note in the case where 6rd can have CPEs communicated by go= ing > thru the BR, the BR suffices to clamp the MSS per protocol.=C2=A0 In the = case > when 6rd has the two CPE=E2=80=99s communicate directly, then the CPE has= to clamp > the MSS per protocol.=C2=A0 The examples of protocols are PPPOE, PPP, Eth= ernet > etc.=C2=A0=C2=A0 Based on what routes are configured on the CPE, the CPE = does know if > the CPE is communicating directly or thru the BR in 6rd mode. > > > > Back to what the DS-Lite problem is.=C2=A0 Thanks to Daniel Rosen for poi= nting it > out.=C2=A0 DS-Lite mandates RFC 2473, section 7.2 behavior.=C2=A0 That be= havior means > the tunnel gets fragmented not the payload.=C2=A0 Thus now the =C2=A0AFTR= and the CPE > perform fragmentation and reassembly. > > > > Hemant > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Instead of following the fashion, we lead it through. From ichiroumakino@gmail.com Mon May 14 06:10:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27AB21F862A for ; Mon, 14 May 2012 06:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYl7fubh3XVX for ; Mon, 14 May 2012 06:10:44 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4DA21F860E for ; Mon, 14 May 2012 06:10:43 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so2045878wib.13 for ; Mon, 14 May 2012 06:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=For1UkscO98CfT04x9Npd2z/+UnEV2FnbGgRLovW1Ws=; b=LS+dbSMaDM2B+ym/6Y5G9dzLxY+7I9m53O9vpzwL4R/FWaR/rD+01CXmH3SWVoyW0r YhQHiXCZqebrT0bDwsfwgWXCVlaRy73MCeuRTRv6B+r+Ea8Lent8uYtDvQ2+q4Ir6/CZ D7I7qmFgaGvTIxSqLl/FW3EB+RV0S6xA2FOj1YmCuzP5hM0qASR2kapsh43jVVpzLKwn sDDYIQ1PmoACglRAzFl5N8j4/CFixwTLprUh+vn1iefbQmxI6/lBcjjYDEe/PfhA3cVV 6IyoOlfmpXmEB/VwDsge6MsV9/uOAgfm717ETzsHmSoJE4tWc4gNrt4U0VxwTP3hVKJS HWRQ== Received: by 10.216.145.153 with SMTP id p25mr5156410wej.112.1337001041722; Mon, 14 May 2012 06:10:41 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff2sm54943086wib.9.2012.05.14.06.10.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 06:10:40 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 14 May 2012 15:10:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> To: Hans Liu X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 13:10:45 -0000 > Ack! It is not a big problem, and we actually support TCP MSS already > for DS-Lite. given that DS-lite is just another tunnel for IPv4 packets, and this is = "established" practice for IPv4, I have no objection in continuing that. = given that it is already done, and the 6204 does not say anything else = at all about IPv4, I'm not sure it needs a specific requirement. I'm more reluctant to add MSS rewrite as a generic requirement for IPv6 = though. cheers, Ole From v6ops@globis.net Mon May 14 06:49:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13321F865C for ; Mon, 14 May 2012 06:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4dv0RVs69Eo for ; Mon, 14 May 2012 06:49:06 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C87121F865A for ; Mon, 14 May 2012 06:49:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1C9F28700F7; Mon, 14 May 2012 15:49:05 +0200 (CEST) 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 DZTg-esAiOtM; Mon, 14 May 2012 15:49:00 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 2BC49870085; Mon, 14 May 2012 15:49:00 +0200 (CEST) Message-ID: <4FB10D4B.60009@globis.net> Date: Mon, 14 May 2012 15:48:59 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: draft-ietf-v6ops-464xlat@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 13:49:07 -0000 I have read this draft. I do not pretend to be an expert in this particular field so I'm reviewing it more from a general network operator viewpoint. Question 1: If a dual stack IPv4+IPv6 client node is communicating to an IPv4 only server, is the translation path native IPv4 on the client -> 464 -> native IPv4 on the server preferable over the translation path native IPv6 on the client -> NAT64 + DNS64 -> native IPv4 on the server? That may come down to 2 things: preferable in that it's technically better, or not preferable in that the operator wants to discourage use of IPv4. Question 2: If this is true, how do you handle synthesised AAAA records generated by DNS64 on the PLAT that are needed for an IPv6 only client to communicate with a IPv4 only server, but which would be disruptive to a dual stack client communicating to the same IPv4 server? Re: Section 6.3.2 of RFC6147. Would the CLAT have to selectively filter these synthesised AAAA answers out, depending if it detected that the end client was single or dual stack? Question 3: ref /It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts./ Likewise, would the CLAT or PLAT have to perform any special DNS translation to handle an IPv4 only client communicating with an IPv6 only server (DNS46??) Question 4: Would it also be possible to transform IPv4 to IPv6 using RFC6145 for transport across the IPv6 only edge network, and then perform the stateless inverse transform of RFC6145 to get back your original IPv4 packet at the physical location of the PLAT (with private IPv4 source address) before sending this facsimile of the original packet into a standard stateful NAT44 device or other translation device? This would effectively be a two step NAT64. 1st motivation: Previous experience with Ethernet -> FDDI translation bridging suggests to me it's relatively easy to translate outer frame/packet headers on a symmetrical path like client -> Ethernet -> FDDI -> Ethernet -> server , but very difficult to catch all the protocol layer violations and name leaks in devices that perform single translations like client -> Ethernet -> FDDI -> server. 2nd Motivation: Stateful NAT44 devices are already abundant, cheap, and well understood. 3rd motivation: you could deploy an ALG, proxy, or other higher layer alternative at the PLAT location if NAT44 didn't work out for some specific protocols. Thanks! RayH Nits & Spelling =========== Section 1. s/deploy limited IPv4 access service to mobile/deploy a limited IPv4 access service to mobile/ s/The 464XLAT IPv4 service is limited to application that function/The 464XLAT IPv4 service is limited to applications that function/ s/in a client server model/in a client server model where the server has been assigned a globally unique IPv4 address,/ Section 3. s/ CLAT SHOULD perform router function to facilitate packets forwarding through the stateless translation even if it is an end-node/ CLAT SHOULD be combined with a CPE router function to ensure packets are forwarded through the stateless translation even if the CLAT is running on an end-node/ Section 4. s/crucial for enabling the IPv4-only applications/crucial for enabling IPv4-only applications/ s/Unlike other transition architectures associated with tunneling or/Unlike other transition architectures associated with tunneling or A&P/ /If the IXP or another provider operates the PLAT/If the IXP (Internet Exchange Point ) or another ISP provider operates the PLAT/ Section 6. s/Incidentally, Japan Internet Exchange(JPIX) is providing 464XLAT trial service since July 2010. In addition to this, the effectiveness of 464XLAT was confirmed in the WIDE camp Spring 2012. The result is described in [I-D.hazeyama-widecamp-ipv6-only-experience].// Suggest removing from BCP document. s/Since there are 2 PDPs required to support 2 address families/Since a dedicated PDP is required to support each of the IPv4 and IPv6 address families in Pre-Release 9 3GPP standards/ s/Connections sourced from the IPv4 interface are immediately routed to the CLAT function and passed to the IPv6-only mobile network, destine to the PLAT. In summary, the UE has the CLAT function that does a stateless translation [RFC6145], but only when required. The mobile network has a PLAT that does stateful translation [RFC6146]./Connections sourced from the IPv4 interface are immediately routed to the CLAT function and then transported via the IPv6-only mobile network to the PLAT. In summary, the UE implements the CLAT function, providing stateless translation of IPv4 traffic [RFC6145], but only when required. The mobile network implements a PLAT, providing stateful translation of IPv6 traffic [RFC6146], but again only when required./ Section 7. s/consume gateway function/consumer premises equipment gateway function/ Section 7.5. s/ In another cases where/ In other cases where/ Section 7.6. s/not have dedicated IPv6 prefix/not have a dedicated IPv6 prefix/ Section 7.7. s/The router with CLAT function SHOULD provide common router services such as DHCP of [RFC1918] addresses , DHCPv6, and DNS service/A router implementing a CLAT function SHOULD also provide common CPE router functions, such as DHCP of [RFC1918] addresses, DHCPv6, and DNS services/ s/translation of DNS request/translation of DNS requests/ Section 7.8. Suggest this is pretty irrelevant. The introduction already states that inbound traffic is not supported. Section 8. s/Internet access provider/Internet Service Provider/ [for consistency] s/without any deep packet inspection for processing the inner IPv4/without performing deep packet inspection that processes the inner IPv4/ From bs7652@att.com Mon May 14 07:01:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E617E21F871D for ; Mon, 14 May 2012 07:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.789 X-Spam-Level: X-Spam-Status: No, score=-105.789 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN15qMMr51J8 for ; Mon, 14 May 2012 07:01:45 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6F21F86AF for ; Mon, 14 May 2012 07:01:44 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 84011bf4.0.175358.00-444.463620.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 14 May 2012 14:01:44 +0000 (UTC) X-MXL-Hash: 4fb1104870c5a317-5892cedbedb4a36046efa5f23ded62440509f62c 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 q4EE1hBj028573 for ; Mon, 14 May 2012 10:01:44 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4EE1bCB028204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 May 2012 10:01:39 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by sflint04.pst.cso.att.com (RSA Interceptor) for ; Mon, 14 May 2012 10:01:23 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.01.0355.002; Mon, 14 May 2012 10:01:22 -0400 From: "STARK, BARBARA H" To: IPv6 Operations Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: AQHNL9iVJJiLXXqaqE6qTXDhLa92FZbFwpYAgAMq8oCAAIeTgIAAD/UA///GUOA= Date: Mon, 14 May 2012 14:01:21 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110FC0F5@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.106.38] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6110FC0F5GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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=1.0 c=1 a=9UbHitx0bv4A:10 a=Kb13YMUcZewA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=s6] X-AnalysisOut: [ztLir2RgOj6qsFtWAA:9 a=tRzxCbunaxYdTWiypjoA:7 a=CjuIK1q_8u] X-AnalysisOut: [gA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Jj4X1Y9Whxe1hO4o] X-AnalysisOut: [vBsA:9 a=5mXq3ZwSA_daCaVNWSMA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L] X-AnalysisOut: [4-1S4A:10 a=hTZeC7Yk6K0A:10] Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 14:01:47 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6110FC0F5GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some very skillful router developers have told me that: 1. They do not consider NAT to be necessarily stateful. They do not c= onsider a simple NAT table to be a maintainer of state, so much as a mainta= iner of information needed to do *static* packet filtering. 2. If we exclude a simple NAT table from the definition of "stateful"= , then not all CE routers today support stateful inspection or firewalling I do know that there will exist some very simple routers that do 6rd or nat= ive IPv6 with IPv4. It is my understanding they will not support stateful p= acket inspection or firewalling. They will support NAT for IPv4. They will = not do simple-security (RFC 6092), which would require true stateful inspec= tion (I mention this only because the biggest reason for not doing RFC 6092= is that it would require stateful inspection on a device that does not cur= rently support stateful inspection). The 6rd implementation will be able to= send all IPv6 traffic to the 6rd BR. Given my understanding of this (which is admittedly limited), it seems to m= e that if MSS truly requires support of stateful inspection, then I would p= refer that *if* this MSS requirement is added, it should be only in the con= text of DS-Lite. Barbara >It should not go into the general requirements section, because inspecting= every SYN packet has a performance cost, and >is unnecessary for native IP= v6 (which is what we're primarily designing for here. The CPE is a device that already supports a stateful firewall that ends up = inspecting every packet and parsing the packet to maintain state. It's no= big deal for such a CPE to edit MSS statelessly for packets traversing the= CPE. The CPE also adds the MSS option when originating/terminating any T= CP client connection. If a knob is needed on the CPE to not do dynamic M= SS editing, that be fine too. In IPv4, you always have to do stateful inspection because of NAT. In IPv6,= not necessarily. My CPE will do 480 Mbps with the firewall off and 280 Mbp= s with the firewall on. I'd like to avoid the performance hit, please. --_000_2D09D61DDFA73D4C884805CC7865E6110FC0F5GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some very skillful router developers ha= ve told me that:

1= .   &= nbsp;   They do not consider NAT to be = necessarily stateful. They do not consider a simple NAT table to be a maint= ainer of state, so much as a maintainer of information needed to do *static* packet filtering.

2= .   &= nbsp;   If we exclude a simple NAT tabl= e from the definition of “stateful”, then not all CE routers to= day support stateful inspection or firewalling

 

I do know that there will exist some ve= ry simple routers that do 6rd or native IPv6 with IPv4. It is my understand= ing they will not support stateful packet inspection or firewalling. They will support NAT for IPv4. They will not do simple-secur= ity (RFC 6092), which would require true stateful inspection (I mention thi= s only because the biggest reason for not doing RFC 6092 is that it would r= equire stateful inspection on a device that does not currently support stateful inspection). The 6rd imple= mentation will be able to send all IPv6 traffic to the 6rd BR.

 

Given my understanding of this (which i= s admittedly limited), it seems to me that if MSS truly requires support of= stateful inspection, then I would prefer that *if* this MSS requirement is added, it should be only in the context of DS-Lite= .

Barbara

= >It should no= t go into the general requirements section, because inspecting every SYN packet has a performance cost, and >is unnecessary for native IPv6 (which is what we're primar= ily designing for here.

The CPE is a device that already suppor= ts a stateful firewall that ends up inspecting every packet and parsing the packet to maintain state.   It’s no big de= al for such a CPE to edit MSS statelessly for packets traversing the CPE.&n= bsp;  The CPE also adds the MSS option when originating/terminating an= y TCP client connection.    If a knob is needed on the CPE to not do dynamic MSS editing, that be fine too.

In IPv4, you always have to do stateful inspection b= ecause of NAT. In IPv6, not necessarily. My CPE will do 480 Mbps with = the firewall off and 280 Mbps with the firewall on. I'd like to avoid the p= erformance hit, please.

--_000_2D09D61DDFA73D4C884805CC7865E6110FC0F5GAALPA1MSGUSR9NIT_-- From gert@space.net Mon May 14 07:28:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E421F850C for ; Mon, 14 May 2012 07:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QZ4M1UrAXTC for ; Mon, 14 May 2012 07:28:23 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA1021F84FF for ; Mon, 14 May 2012 07:28:22 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 98B82F8B0A for ; Mon, 14 May 2012 16:28:21 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 823BEF8AF9 for ; Mon, 14 May 2012 16:28:21 +0200 (CEST) Received: (qmail 61792 invoked by uid 1007); 14 May 2012 16:28:21 +0200 Date: Mon, 14 May 2012 16:28:21 +0200 From: Gert Doering To: "STARK, BARBARA H" Message-ID: <20120514142821.GX84425@Space.Net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110FC0F5@GAALPA1MSGUSR9N.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110FC0F5@GAALPA1MSGUSR9N.ITServices.sbc.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 14:28:24 -0000 Hi, On Mon, May 14, 2012 at 02:01:21PM +0000, STARK, BARBARA H wrote: > Some very skillful router developers have told me that: > > 1. They do not consider NAT to be necessarily stateful. They do not consider a simple NAT table to be a maintainer of state, so much as a maintainer of information needed to do *static* packet filtering. > > 2. If we exclude a simple NAT table from the definition of "stateful", then not all CE routers today support stateful inspection or firewalling This is... weird. Even if the table is simple, it needs to be maintained, and new SYN packets need to add an entry to the NAT table - so the box needs to look out for SYN anyway, and that's the context we're talking about. "If this is a SYN, go in and change the MSS to whatever makes sense". Naming things differently and then declaring "oh, we have nothing with that name" is a good way to product marketing, but not so suitable for IETF... Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From shemant@cisco.com Mon May 14 07:34:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7347421F87DF for ; Mon, 14 May 2012 07:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lT70eSBni4w for ; Mon, 14 May 2012 07:34:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AC6E521F86B1 for ; Mon, 14 May 2012 07:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4372; q=dns/txt; s=iport; t=1337006075; x=1338215675; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Rk2BUcYbiZdMUu6jJLWcmFA+o1FdjGsM9K+h+wTZFoA=; b=h1BmREGAYVzPzl9tWtxlq31Aksjgn0b3pF1AW8mSICmkfUQ/y3kE/yJT C/VhGDspkTUP91i70AoFRzCp0wn/AikMxf7x1LLUu6xbF+693cTEQf9IB 9MyfCP4ouiFXw30I7NRAVgG6CReNwgb6iue3HxpXYoaebPsbPaI3vciCX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAYXsU+tJXG9/2dsb2JhbABEgkaxLYEHghUBAQEEEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQTCBqHbJpSn22LGoUlYwSIZJtwgWmDBw X-IronPort-AV: E=Sophos;i="4.75,586,1330905600"; d="scan'208,217";a="83032103" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 14 May 2012 14:34:35 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4EEYZwN000951; Mon, 14 May 2012 14:34:35 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 09:34:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD31DE.AE950A16" Date: Mon, 14 May 2012 09:34:33 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C496@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0x0OaELDYofzvgQLyDdtqjgYpuOAADa5xw References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" X-OriginalArrivalTime: 14 May 2012 14:34:34.0976 (UTC) FILETIME=[AEDBE600:01CD31DE] Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 14:34:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD31DE.AE950A16 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Monday, May 14, 2012 8:56 AM To: Hemant Singh (shemant) Cc: Cameron Byrne; IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu =20 =20 >In IPv4, you always have to do stateful inspection because of NAT. In IPv6, not necessarily. My CPE will do 480 Mbps with the firewall off and 280 Mbps with the firewall on. I'd like to avoid the >performance hit, please. =20 Accepted. I will send out proposed text shortly to the mailer. =20 Hemant ------_=_NextPart_001_01CD31DE.AE950A16 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= = Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Monday, May = 14, 2012 8:56 AM
To: Hemant Singh (shemant)
Cc: = Cameron Byrne; IPv6 Operations
Subject: Re: [v6ops] 6204 bis = and mtu

 

 

>In IPv4, you = always have to do stateful inspection because of NAT. In IPv6, not = necessarily. My CPE will do 480 Mbps with the firewall off and 280 = Mbps with the firewall on. I'd like to avoid the >performance hit, please.

 

Accepted.  I will send out proposed text shortly to the = mailer.

 

Hemant

------_=_NextPart_001_01CD31DE.AE950A16-- From despres.remi@laposte.net Mon May 14 07:38:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864F921F87FF for ; Mon, 14 May 2012 07:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVCBZhq5Y91J for ; Mon, 14 May 2012 07:38:12 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 707C921F87FC for ; Mon, 14 May 2012 07:38:10 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 31E0E940187; Mon, 14 May 2012 16:38:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-31-69313526 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110FC0F5@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Mon, 14 May 2012 16:38:02 +0200 Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C405@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110FC0F5@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 14:38:13 -0000 --Apple-Mail-31-69313526 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Barbara, Le 2012-05-14 =E0 16:01, STARK, BARBARA H a =E9crit : > ... Given my understanding of this (which is admittedly limited), it = seems to me that if MSS truly requires support of stateful inspection, Adjusting MSS in SYN TCP packets requires packet inspection at layer 4, = but NOT a stateful inspection. > then I would prefer that *if* this MSS requirement is added, it should = be only in the context of DS-Lite. It can therefore safely be authorized, as a nice-to-have feature, = wherever a local MTU is known to be lower than that needed by the TCP = advertised MSS. Regards, RD =20 > Barbara > >It should not go into the general requirements section, because = inspecting every SYN packet has a performance cost, and >is unnecessary = for native IPv6 (which is what we're primarily designing for here. > The CPE is a device that already supports a stateful firewall that = ends up inspecting every packet and parsing the packet to maintain = state. It=92s no big deal for such a CPE to edit MSS statelessly for = packets traversing the CPE. The CPE also adds the MSS option when = originating/terminating any TCP client connection. If a knob is = needed on the CPE to not do dynamic MSS editing, that be fine too. > In IPv4, you always have to do stateful inspection because of NAT. In = IPv6, not necessarily. My CPE will do 480 Mbps with the firewall off and = 280 Mbps with the firewall on. I'd like to avoid the performance hit, = please. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-31-69313526 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
... Given my understanding of this (which is = admittedly limited), it seems to me that if MSS truly requires support = of stateful inspection, =

Adjusting= MSS in SYN TCP packets requires packet inspection at layer 4, but NOT a = stateful inspection.


then I would prefer that *if* this MSS = requirement is added, it should be only in the context of = DS-Lite.

<= div>It can therefore safely be authorized, as a nice-to-have = feature, wherever a local MTU is known to be lower than that needed by = the TCP advertised = MSS.

Regards,
RD
<= br>
 

>It should not go into the general requirements section, because = inspecting every SYN packet has a performance cost, and >is unnecessary for native IPv6 = (which is what we're primarily designing for = here.
The = CPE is a device that already supports a stateful firewall that ends up = inspecting every packet and parsing the packet to maintain state.  =  It=92s no big deal for such a CPE to edit MSS statelessly for = packets traversing the CPE.   The CPE also adds the MSS option = when originating/terminating any TCP client connection.  =   If a knob is needed on the CPE to not do dynamic MSS = editing, that be fine too.In IPv4, you = always have to do stateful inspection because of NAT. In IPv6, not = necessarily. My CPE will do 480 Mbps with the firewall off and 280 = Mbps with the firewall on. I'd like to avoid the performance hit, = please.
__________________________= _____________________
v6ops mailing list
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail-31-69313526-- From shemant@cisco.com Mon May 14 08:13:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7159F21F87D3 for ; Mon, 14 May 2012 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri7z7PJsRVF8 for ; Mon, 14 May 2012 08:13:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 75DFC21F87CB for ; Mon, 14 May 2012 08:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9331; q=dns/txt; s=iport; t=1337008405; x=1338218005; h=mime-version:subject:date:message-id:from:to; bh=nvVn0xwHsWei4nblFeFshQNlMS6pw4KH1fuN3UqhFc0=; b=IzzPh3zbxpFqPpI2ToZM8Y845WpEnmeZ/AvrAFeeKBT5SJ6gjCM8gdJ6 NiwWHD/abMoUtIVo70HQeeXO/K7TNqGLRat4lxlv7YQGokXo01GKvENg8 ofyeH5wvjdUIQKMi/DIzhx/f/lhbNPWh98ToueO+OIWy+e8TjRsI6thgy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHIgsU+tJXG8/2dsb2JhbABEgkaxLYEHghcBBBIBCREDWwEqBhgHVwEEGxqHbJk6gSifcpA/YwSIZJtwgWmDBw X-IronPort-AV: E=Sophos;i="4.75,586,1330905600"; d="scan'208,217";a="83049809" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 14 May 2012 15:13:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4EFDOv2004531 for ; Mon, 14 May 2012 15:13:24 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 10:13:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD31E4.1B41FF0E" Date: Mon, 14 May 2012 10:13:23 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: proposed TCP MSS text for rfc6204bis Thread-Index: Ac0x5Br2+j9mNxDaQuuqarxLphgLSA== From: "Hemant Singh (shemant)" To: "IPv6 Operations" X-OriginalArrivalTime: 14 May 2012 15:13:24.0770 (UTC) FILETIME=[1B864020:01CD31E4] Subject: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 15:13:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD31E4.1B41FF0E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [The CPE router MUST support a TCP MSS Adjust feature on packets traversing the CPE router. By default, the TCP MSS Adjust feature is turned off. ]=20 =20 Some thoughts below on why the above text. =20 The TCP MSS Adjust is not needed for TCP packets sourced or destined to the CPE because the number of such packets at the CPE will be very small. Additionally, we (Wes and I) deliberately left out qualifying the feature for IPv4 or IPv6 because the feature should be supported for both since the CPE also supports 6rd. We have left out specifying any default value for the MSS because there are several values since the MSS is a function of the protocols being used. Note IPv4 CPE routers already support a TCP MSS Adjust knob. Further, the DS-Lite AFTR and the 6rd BR in the SP domain sit between the home TCP client and a TCP server on the Internet. Thus the AFTR and the BR can perform TCP MSS Adjust. It's only for 6rd where the CPE's talk without going through the BR, the CPE has to invoke the TCP MSS Adjust. =20 =20 The problems that the above text alleviates are: =20 (a) Any of native IPv6 and tunneled technologies such as DS-Lite and 6rd can cause ICMPv6 errors for packet too big to the source. Even when the CPE issues the ICMPv6 error to the host connected to the CPE, the Internet access of the host is delayed which is not good. Additionally, what if the CPE passes the host packet to the Internet and one router on the Internet issues the ICMPv6 error with packet too big but a node in the path back blocks the ICMPv6 error. Now the Internet connectivity is really delayed for the host. This summarizes that we do have problems to fix. (b) DS-Lite is an additional problem. Since DS-Lite mandates that the CPE and the AFTR perform fragmentation and reassembly, we have a nasty problem. Reassembly of tunneled encapsulated packets is very complex because the receiver of the fragmented packet has to reassemble before decapsulation. Thus the received needs more memory and a general purpose cpu. If I want to choke a DS-Lite deployment at the AFTR and the CPE, I will generate packets close to 1500 bytes and force tunnel fragmentation. Thus the DS-Lite problem is an attack vector that Daniel Rosen pointed out too. =20 Further, PMTUD is not practical to deploy so the TCP MSS Adjust is still a usable choice. =20 =20 Thanks, =20 Hemant =20 =20 =20 =20 ------_=_NextPart_001_01CD31E4.1B41FF0E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[The = CPE router MUST support a TCP MSS Adjust feature on packets traversing = the CPE router.  By default, the TCP MSS Adjust feature is turned = off. ]

 

Some thoughts below on why the above = text.

 

The TCP MSS Adjust is not needed for TCP packets = sourced or destined to the CPE because the number of such packets at the = CPE will be very small.  Additionally, we (Wes and I) deliberately = left out qualifying the feature for IPv4 or IPv6 because the feature = should be supported for both since the CPE also supports = 6rd.   We have left out specifying any default value for the = MSS because there are several values since the MSS is a function of the = protocols being used.   Note IPv4 CPE routers already support = a TCP MSS Adjust knob.    Further, the DS-Lite AFTR and = the 6rd BR in the SP domain sit between the home TCP client and a TCP = server on the Internet.  Thus the AFTR and the BR can perform TCP = MSS Adjust.  It’s only for 6rd  where the CPE’s = talk without going through the BR, the CPE has to invoke the TCP MSS = Adjust. 

 

The problems = that the above text alleviates are:

 

(a)    = Any of native IPv6  and tunneled = technologies such as DS-Lite and 6rd can cause ICMPv6 errors for packet = too big to the source.   Even when the CPE issues the ICMPv6 = error to the host connected to the CPE, the Internet access of the host = is delayed which is not good.   Additionally, what if the CPE = passes the host packet to the Internet and one router on the Internet = issues the ICMPv6 error with packet too big but a node in the path back = blocks the ICMPv6 error.   Now the Internet connectivity is = really delayed for the host.   This summarizes that we do have = problems to fix.

(b)    = DS-Lite is an additional problem.   = Since DS-Lite mandates that the CPE and the AFTR perform fragmentation = and reassembly, we have a nasty problem.   Reassembly of = tunneled encapsulated packets is very complex because the receiver of = the fragmented packet has to reassemble before = decapsulation.   Thus the received needs more memory and a = general purpose cpu.  If I want to choke a DS-Lite deployment at = the AFTR and the CPE, I will generate packets close to 1500 bytes and = force tunnel fragmentation.   Thus the DS-Lite problem is an = attack vector that Daniel Rosen pointed out too.

 

Further, = PMTUD is not practical to deploy so the TCP MSS Adjust is still a usable = choice.    

 

Thanks,

 

Hemant =  

 

 

 

=

------_=_NextPart_001_01CD31E4.1B41FF0E-- From shemant@cisco.com Mon May 14 08:26:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CBE21F876A for ; Mon, 14 May 2012 08:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYtVhUNS2sux for ; Mon, 14 May 2012 08:26:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F263F21F86B8 for ; Mon, 14 May 2012 08:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4968; q=dns/txt; s=iport; t=1337009214; x=1338218814; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Y0zftmtEkvtP42wUvmQR/cSax/vmHuI6gKB9X/f2fF0=; b=FS8uuGWK+Rw/UEpXmBp8Ko4HJqItkoIJgelFKJkELur3ugxG+Kcz+lZL i51i764kWEAaDs17fxW7swdhPfCGV2L41s/lGgsDn85QQ2kxoq1bkUq84 FQuyRmc7GdNC87EqkQPUsYEKudwkBOjFhj+xPC6jZ/kAdMxqs/v/DKuhi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAAksU+tJXHB/2dsb2JhbABEgkaxLYEHghUBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHbJpvn3KLGoUlYwSIZJtwgWmDBw X-IronPort-AV: E=Sophos;i="4.75,586,1330905600"; d="scan'208,217";a="83037389" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 14 May 2012 15:26:34 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q4EFQYmq014044; Mon, 14 May 2012 15:26:34 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 10:26:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD31E5.F2075CBE" Date: Mon, 14 May 2012 10:26:33 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4F3@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0x0T/ajKM+i5ETROu8Rk65TpRLLAAFBvhw References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com><20120514070921.GA6906@srv03.cluenet.de> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" , X-OriginalArrivalTime: 14 May 2012 15:26:34.0712 (UTC) FILETIME=[F25DD580:01CD31E5] Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 15:26:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD31E5.F2075CBE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti Sent: Monday, May 14, 2012 8:58 AM To: v6ops@ietf.org Subject: Re: [v6ops] 6204 bis and mtu =20 >PLEASE don't spread the idea of playing with the LAN MTU to cope for any >WAN interface related issues. I've just managed to convince one CPE >vendor to NOT arbitrarily mock around with the LAN MTU. Agree. However, the SP deploying DS-Lite knows DS-Lite is being deployed with, say, the PPPOE protocol. So the SP totally knows the effective MTU for PPPOE over DS-Lite. Thus it makes sense that the SP signals the effective MTU in the IPv6 ND RA and the CPE uses the MTU value ONLY for the TCP MSS. 6rd cannot use the IPv6 ND RA because 6rd tunnels IPv6 traffic in IPv4. =20 Hemant ------_=_NextPart_001_01CD31E5.F2075CBE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Lorenzo Colitti
Sent: Monday, May 14, 2012 8:58 = AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6204 bis = and mtu

 

>PLEASE don't spread the idea of playing with the LAN MTU to cope = for any
>WAN interface = related issues. I've just managed to convince one CPE
>vendor to NOT arbitrarily mock around = with the LAN MTU.

Agree.  However, the SP deploying DS-Lite knows DS-Lite is being = deployed with, say, the PPPOE protocol.   So the SP totally = knows the effective MTU for PPPOE over DS-Lite.  Thus it makes = sense that the SP signals the effective MTU in the IPv6 ND RA and the = CPE uses the MTU value ONLY for the TCP MSS.   6rd cannot use = the IPv6 ND RA because 6rd tunnels IPv6 traffic in = IPv4.

 

Hemant



------_=_NextPart_001_01CD31E5.F2075CBE-- From cb.list6@gmail.com Mon May 14 08:29:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D200921F87CB for ; Mon, 14 May 2012 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzXbU4ANPqDZ for ; Mon, 14 May 2012 08:29:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D735D21F87CA for ; Mon, 14 May 2012 08:29:18 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so9243310obb.31 for ; Mon, 14 May 2012 08:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/LXlESKghbMIJdAGYifFdMxY6fVUEcw5fdHL/f/N1Cs=; b=qhFBoO6iOdgv5wjUp63mr0Rjuaarq9+08XXJOFNEWdAHoA/NAVkylrJgpFRXI2Ivz2 RRHHz/T8JoSRjhNXaqoCJU0BIG9brDUNdlBLJIpHGxyFuZI/I7t8+pleYlMs6yn1dY4k a/BZpDs+jYzzGR2i35rWvzZnmELFsUpeUXG+jQ7VRKHW3h37vaYJPrlrUwlC8JlBLe2t qkAiFty8z1BvkBEQvPDoKd89gSZvypX+VJmPGk7DpN+U5O0E5cQJce+0tY3wp/nHw+aE jT66gvhKC5NHwiOh9kGshSz6ljZal95eWS3fHZ5yf3uM21BAkHS++SI9HdQ7sH5qsXUc 6vwg== MIME-Version: 1.0 Received: by 10.182.197.65 with SMTP id is1mr4269476obc.27.1337009358497; Mon, 14 May 2012 08:29:18 -0700 (PDT) Received: by 10.182.36.38 with HTTP; Mon, 14 May 2012 08:29:18 -0700 (PDT) Date: Mon, 14 May 2012 08:29:18 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] CGN vs Native IPv6 latency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 15:29:19 -0000 Hi, I sometimes hear folks say that CGN adds latency or otherwise makes the network slower, and this fact will mean that IPv6 will take more traffic than the slower CGN IPv4 path. I do not believe CGN adds any meaningful latency when the CGN path and IPv6 are ostensibly the same for the internal network (something an access network provider controls). Sometimes, on the external network (the internet), the IPv6 peering is less robust and results in longer paths and therefore higher latency and lower performance for IPv6. Here is some data i casually collect from my phone doing speedtest at ipv6-test.com. Yes, i know these test are flawed in many ways, but this is just a casual observation. The test was done using the IPv6-only connection across an HSPA+ mobile network. The IPv6 path is native end to end. The "IPv4 path" is IPv6 from the Samsung handset to a NAT64 (CGN) and then IPv4 to the test server. This is just a casual test using production and easily available elements. IPv4 / IPv6 speeds Mbit/s 10.2 /9.07 http://img2.ipv6-test.com/speedtest/result/2012/05/14/0b6984f7f589c0fdd10bce5bdaf7b80f.png 11.8/10.8 http://img2.ipv6-test.com/speedtest/result/2012/05/14/898322b8348a47dfe31d944bf3d8b154.png 11.8/12.0 http://img2.ipv6-test.com/speedtest/result/2012/05/14/ae2cb534d9d5e74020191d072f127456.png As you can see, no noticeable difference in this casual observation. I am sure someone with time and precision gear can show that CGN addes ~1ms of latency, but that is hardly impactful on today's internet Does anyone have data showing CGN harms network performance from a speed perspective? Perhaps in such a way that it may impact a happy eyeballs implementations that may do a "straight race" such as Apple's? CB From lee@asgard.org Mon May 14 08:34:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66AB21F87DB for ; Mon, 14 May 2012 08:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQJqBzaxQsKX for ; Mon, 14 May 2012 08:34:08 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 93F5E21F87D0 for ; Mon, 14 May 2012 08:34:08 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q4EFY26t012087 for ; Mon, 14 May 2012 11:34:07 -0400 Authentication-Results: cm-omr10 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.167] ([204.235.115.167:24433] helo=HDC00042402) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B6/C0-22157-AE521BF4; Mon, 14 May 2012 11:34:02 -0400 From: "Lee Howard" To: "'Cameron Byrne'" , "'Hemant Singh \(shemant\)'" References: <0a9701cd2ed1$ba0932e0$2e1b98a0$@com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A017A3@XMB-RCD-109.cisco.com> In-Reply-To: Date: Mon, 14 May 2012 11:34:02 -0400 Message-ID: <007e01cd31e6$fd5026e0$f7f074a0$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF0TdxzJtCzHmL6go7ES4mEl3plRgDGeNr7Ac3j2MoBh1IhxwGcZOUFl01xRjA= Content-Language: en-us Cc: 'IPv6 Operations' , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 15:34:09 -0000 > > > > -----Original Message----- > > From: Cameron Byrne [mailto:cb.list6@gmail.com] > > Sent: Friday, May 11, 2012 11:22 AM > > To: Chris Donley > > Cc: Dan Wing (dwing); STARK, BARBARA H; Ole Tr=F8an; Hans Liu; IPv6 > > Operations; draft-ietf-v6ops-6204bis@tools.ietf.org > > Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd > > sunsetting requirements (version 3)] > > > >>If this issue is systemic for DOCSIS, and MSS rewrite is a known and > >>common solution, should 6204bis include language about MSS rewrite? > > > > The DS-Lite RFC in RFC 6333 already did not include the MSS rewrite > > because the rewrite is considered a hack due to a layer violation = (as > > also mentioned by Dan Wing) for this thread.=A0 Thus if RFC 6333 = does > > not mention the MSS rewrite, rfc6204bis should not either. > > > Neither of those documents are v6ops, and they do not need to serve = the operator > community in the same way v6ops does. Fair enough. Would the operator who has a problem we need to solve = please raise their hand? Lee From C.Donley@cablelabs.com Mon May 14 08:35:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41E221F87E5 for ; Mon, 14 May 2012 08:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.009 X-Spam-Level: X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa18pubAw25c for ; Mon, 14 May 2012 08:35:31 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2E121F87DB for ; Mon, 14 May 2012 08:35:31 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q4EFZTk0026829; Mon, 14 May 2012 09:35:29 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 14 May 2012 09:35:29 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 14 May 2012 09:35:30 -0600 From: Chris Donley To: Fred Baker , Hemant Singh Date: Mon, 14 May 2012 09:35:26 -0600 Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: Ac0x5zD8dSXd//b/TomonVgCujhCLA== Message-ID: In-Reply-To: <62129DB3-B653-4715-BD1B-41F5156D5E81@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD67A9F516F2cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 15:35:32 -0000 --_000_CBD67A9F516F2cdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1. I had really hoped to avoid a long discussion on DS-Lite, but since Pandora= 's box is open.... Yes, we've seen MTU issues in our testing, but it's not universal - some ho= st operating systems offer better throughput than others through DS-Lite. Y= es, the DOCSIS MTU is set to 1522, but most cable operators are not plannin= g to use DS-Lite. According to some of the comments on the list, it sounds= like service providers who are planning to use DS-Lite have the ability to= change the MTU or to enable MSS rewrite on their (or their subscribers') r= outers. Therefore, please don't mandate extra cost and complexity for all home rout= ers to solve a problem for a small percentage of hosts attached to DOCSIS n= etworks that by and large won't be running DS-Lite. I don't think we have enough information to make significant guidance for D= S-Lite in 6204bis. If someone wants to spend some time researching DS-Lite= operations and document the findings in a later document, then great, but = please don=92t rush in new requirements to 6204bis until there's some opera= tional experience that such guidance won't cause more problems. Chris On 5/12/12 11:09 AM, "Fred Baker" > w= rote: On May 11, 2012, at 8:30 PM, Hemant Singh (shemant) wrote: The CPE router MUST support adjusting the MSS value of the TCP SYN packets. chair hat off - two points. One, you were the guy complaining about 6rd sunset as adding an infinite st= ring of new requirements when it in fact added a very finite set of new req= uirements. This seems in fact to be more in line with "an undelimited set o= f new requirements - and as noted, it is a layer violation. Two, this is a feature I use on my home router. It is not specific to ds-li= te, it is needed for any form of tunneling, due to the lack of deployment o= f RFC 4821 and the fact that filtering of ICMP is common. It prevents the u= se of IPsec (it can be done before placing traffic into an IPsec tunnel, bu= t not on traffic that has already been signed), and doesn't work at all on = IPsec-encrypted traffic. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_CBD67A9F516F2cdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1.


I = had really hoped to avoid a long discussion on DS-Lite, but since Pandora's= box is open....

Yes, we've seen MTU issues in ou= r testing, but it's not universal - some host operating systems offer bette= r throughput than others through DS-Lite. Yes, the DOCSIS MTU is set to 152= 2, but most cable operators are not planning to use DS-Lite.  Accordin= g to some of the comments on the list, it sounds like service providers who= are planning to use DS-Lite have the ability to change the MTU or to enabl= e MSS rewrite on their (or their subscribers') routers.

Therefore, please don't mandate extra cost and complexity for all ho= me routers to solve a problem for a small percentage of hosts attached to D= OCSIS networks that by and large won't be running DS-Lite.  

I don't think we have enough information = to make significant guidance for DS-Lite in 6204bis.  If someone wants= to spend some time researching DS-Lite operations and document the finding= s in a later document, then great, but please don=92t rush in new requireme= nts to 6204bis until there's some operational experience that such guidance= won't cause more problems.

Chris



On 5/12/12 11:09 AM, &q= uot;Fred Baker" <fred@cisco.com> wrote:



chair hat off - two points.



--_000_CBD67A9F516F2cdonleycablelabscom_-- From victor.kuarsingh@gmail.com Mon May 14 09:08:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF621F8819 for ; Mon, 14 May 2012 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tm8aS3sZLCT for ; Mon, 14 May 2012 09:08:53 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 339B321F8816 for ; Mon, 14 May 2012 09:08:53 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so1587970wib.13 for ; Mon, 14 May 2012 09:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=ZDQ1axmqCoVYUKweRH8/5G3xLU2/kVwQqF+MdC5gisM=; b=kiYLUmGM1AZYIs3ST7ajVDhVifDLV2R5lIYYB+nuD75KEn+JuebJWr1G7SkGXHKMtp 6a1hebuKVyTmEZx7P4Z+bbx456qucAsOtVwzQM3A/0js52388EDXa//1h2nhtgznJoW0 7ZkwlBYnzVMa/D3uoEDnpFIPtxpOGlyxa/tx4lc//o4KcSYeiO/AwWgQAzzHhNsZumiS UAc/bYEx6PAdv/hu92tRqULcjLsDA0BMz4cHJHr6W8LF1KhAh2ZKHyWAcooo4e5inip/ mj0LC6llCDd3ZzJ6NPsYzr0CSYMpAvsshRYhpl34FziAXfH8tCcyJZRUf2qmvdhNdSRZ yXLA== Received: by 10.50.40.193 with SMTP id z1mr4654302igk.0.1337011731715; Mon, 14 May 2012 09:08:51 -0700 (PDT) Received: from [130.63.102.10] (airmarshal-v80-100-553.airyork.yorku.ca. [130.63.102.10]) by mx.google.com with ESMTPS id yg9sm10717811igb.15.2012.05.14.09.08.47 (version=SSLv3 cipher=OTHER); Mon, 14 May 2012 09:08:50 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 14 May 2012 12:08:43 -0400 From: Victor Kuarsingh To: Chris Donley , Fred Baker , Hemant Singh Message-ID: Thread-Topic: [v6ops] 6204 bis and mtu In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3419842129_1238678" Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 16:08:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3419842129_1238678 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 1++, >Therefore, please don't mandate extra cost and complexity for all home rou= ters to solve a problem for a small >percentage of hosts attached to DOCSIS netw= orks that by and large won't be running DS-Lite. >I don't think we have enough information to make significant guidance for DS-Lite in 6204bis. If someone wants >to spend some time researching DS-Li= te operations and document the findings in a later document, then great, but >please don=B9t rush in new requirements to 6204bis until there's some operat= ional experience that such guidance >won't cause more problems. >Chris I will tend to agree with Chris here. My understanding was we are trying t= o capture the common requirements across the board in 6402bis (incrementally to 6204). It seems that this "fix" is needed in some cases depending on the mode of operation by the operator. [Total opinion here].. The MSS rewrite option seems to add yet more complexity to the operator deployment (which is getting complex enough as i= t is). Some operators may also have challenges if they are perceived to artificially be doing "system-in-the-middle" rewriting of customer traffic (beyond what is necessary). Bogging down the document with details that only serve a sub-set of all cases seems to be overextending the object of the document. The most use this document has for me (and likely others like me) is that it will serve the operators as the baseline across the board. If operators need functionality above and beyond this document, then would that not be something they can ask for from their vendor? My feedback to the document contributors previously was that it would be counter intuitive to have an RFC which I then need to go to a vendor and say "support RFCxxx, except for sections x, y ,z.". I prefer "support RFCxxx and here are the extra things I need for my deployment". This second approach is much more sound IMHO. Also, previous comments on fixing PMUTD are valid in my opinion. It's time to fix the network as we need this for IPv6 anyway. Regards, Victor K On 5/12/12 11:09 AM, "Fred Baker" wrote: >=20 > On May 11, 2012, at 8:30 PM, Hemant Singh (shemant) wrote: >=20 >> The CPE router MUST support adjusting the MSS value of the TCP SYN pack= ets. >> =20 >=20 >=20 > chair hat off - two points. >=20 > One, you were the guy complaining about 6rd sunset as adding an infinite > string of new requirements when it in fact added a very finite set of new > requirements. This seems in fact to be more in line with "an undelimited = set > of new requirements - and as noted, it is a layer violation. >=20 > Two, this is a feature I use on my home router. It is not specific to ds-= lite, > it is needed for any form of tunneling, due to the lack of deployment of = RFC > 4821 and the fact that filtering of ICMP is common. It prevents the use o= f > IPsec (it can be done before placing traffic into an IPsec tunnel, but no= t on > traffic that has already been signed), and doesn't work at all on > IPsec-encrypted traffic. > _______________________________________________ > 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 --B_3419842129_1238678 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
1++,


>Therefore, please don't mandate extra cost and= complexity for all home routers to solve a problem for a small = &g= t;percentage of hosts attached to DOCSIS networks that by and large won= 't be running DS-Lite.  

>= I = don't think we have enough information to make significant guidance for DS-L= ite in 6204bis.  If someone wants >to spend some time= researching DS-Lite operations and document the findings in a later documen= t, then great, but >please don’t rush in new require= ments to 6204bis until there's some operational experience that such guidanc= e >won't cause more problems.

= >Chris

I will tend to agree = with Chris here.  My understanding was we are trying to capture the com= mon requirements across the board in 6402bis (incrementally to 6204). It see= ms that this "fix" is needed in some cases depending on the mode of operatio= n by the operator.

[Total opinion here].. The MSS r= ewrite option seems to add yet more complexity to the operator deployment (w= hich is getting complex enough as it is).  Some operators may also have= challenges if they are perceived to artificially be doing "system-in-the-mi= ddle" rewriting of customer traffic (beyond what is necessary).
Bogging down the document with details that only serve a sub-se= t of all cases seems to be overextending the object of the document.  T= he most use this document has for me (and likely others like me) is that it = will serve the operators as the baseline across the board.

If operators need functionality above and beyond this document, then= would that not be something they can ask for from their vendor?  My fe= edback to the document contributors previously was that it would be counter = intuitive to have an RFC which I then need to go to a vendor and say "suppor= t RFCxxx, except for sections x, y ,z.".  I prefer "support RFCxxx and = here are the extra things I need for my deployment".  This second appro= ach is much more sound IMHO.

Also, previous comment= s on fixing PMUTD are valid in my opinion.  It's time to fix the networ= k as we need this for IPv6 anyway.

Regards,

Victor K





On 5/12/12 11:09 AM, = "Fred Baker" <fred@cisco.com> wrot= e:

= On May 11, 2012, at 8:30 PM, Hemant Singh (shemant) wrote:

The CPE router MUST = support adjusting the MSS value of the TCP SYN packets.


chair hat off - two points.

One, you were the guy complaining about 6rd sunset as = adding an infinite string of new requirements when it in fact added a very f= inite set of new requirements. This seems in fact to be more in line with "a= n undelimited set of new requirements - and as noted, it is a layer violatio= n.

Two, this is a feature I use on my home router. = It is not specific to ds-lite, it is needed for any form of tunneling, due t= o the lack of deployment of RFC 4821 and the fact that filtering of ICMP is = common. It prevents the use of IPsec (it can be done before placing traffic = into an IPsec tunnel, but not on traffic that has already been signed), and = doesn't work at all on IPsec-encrypted traffic.
__________________= _____________________________
v6ops mailing list

_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3419842129_1238678-- From lee@asgard.org Mon May 14 09:10:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E745621F8820 for ; Mon, 14 May 2012 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 G7n7y5JRkC5X for ; Mon, 14 May 2012 09:10:53 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 54BB121F8816 for ; Mon, 14 May 2012 09:10:53 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q4EGAp8w026802 for ; Mon, 14 May 2012 12:10:52 -0400 Authentication-Results: cm-omr1 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.167] ([204.235.115.167:19077] helo=HDC00042402) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0C/8F-23732-B8E21BF4; Mon, 14 May 2012 12:10:51 -0400 From: "Lee Howard" To: "'Cameron Byrne'" , "'IPv6 Ops WG'" References: In-Reply-To: Date: Mon, 14 May 2012 12:10:50 -0400 Message-ID: <009101cd31ec$21d6a390$6583eab0$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGe7ZHALNq+XnC4LUTpReKjwRzsoJcl+tIA Content-Language: en-us Subject: Re: [v6ops] CGN vs Native IPv6 latency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 16:10:54 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Cameron > Byrne > Sent: Monday, May 14, 2012 11:29 AM > To: IPv6 Ops WG > Subject: [v6ops] CGN vs Native IPv6 latency > > Hi, > > I sometimes hear folks say that CGN adds latency or otherwise makes the network slower, > and this fact will mean that IPv6 will take more traffic than the slower CGN IPv4 path. > > I do not believe CGN adds any meaningful latency when the CGN path and > IPv6 are ostensibly the same for the internal network Is that a universal architectural assumption? That implies running CGN on your existing routers, which may not have the capacity. So one could upgrade, or add additional devices in network hubs. Or shunt traffic to a data center for the CGN. The latter would add a couple of milliseconds. > Sometimes, on the external network (the internet), the IPv6 peering is less robust > and results in longer paths and therefore higher latency and lower performance for IPv6. Also true. > Does anyone have data showing CGN harms network performance from a speed > perspective? Perhaps in such a way that it may impact a happy eyeballs implementations > that may do a "straight race" such as Apple's? I think Apple's implementation notices microseconds, which might change your results. Thanks for sharing your results though; this is constructive conversation to have. Lee > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Mon May 14 09:25:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DE09E800C for ; Mon, 14 May 2012 09:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcW38jQXZKt9 for ; Mon, 14 May 2012 09:25:28 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF079E800B for ; Mon, 14 May 2012 09:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=13851; q=dns/txt; s=iport; t=1337012728; x=1338222328; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=WfurKQt0kXgPf3YQeqBX6sCrRMrE9JZYQN7N9pnqb/c=; b=l73tTgM50ipDkJWYs3I0XXI0oETpThV0KT7c6//giaPA2b8mhnD3FHbr SfmPSVr/uXWZ9Y1FyWimOTjw378nkypXQuasRupHBt4sEz0w+DWrUMezu HtEwOwKxKFdPy0NqxeIAEbdaiKFBYNe6VsMZl+S9WMQg/EbeGUIUZPtou c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANIwsU+tJXG9/2dsb2JhbABEgkaxLIEHghUBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBMHh2yadp92ixqFJWMEiGSbcIFpgweBQQ X-IronPort-AV: E=Sophos;i="4.75,586,1330905600"; d="scan'208,217";a="83071789" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 14 May 2012 16:25:27 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4EGPRQH008819 for ; Mon, 14 May 2012 16:25:27 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 11:25:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD31EE.2B8FD52A" Date: Mon, 14 May 2012 11:25:25 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C549@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0x5Br2+j9mNxDaQuuqarxLphgLSAACPfiw References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "IPv6 Operations" X-OriginalArrivalTime: 14 May 2012 16:25:26.0999 (UTC) FILETIME=[2BC60E70:01CD31EE] Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 16:25:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD31EE.2B8FD52A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chris and Victor, =20 Did you read this email before replying? The issue is not just DS-Lite specific and the problem is real for any of DS-Lite, 6rd, and native IPv6/IPv4. The network for native IPv6 can easily include one IPv6 router in the path that issues an ICMPv6 error with packet too big for any packet size > 1280. Now what does the native IPv6 cable deployment do? PMTUD is not a viable solution. So how else are the problems solved unless the TCP MSS Adjust is used at the BR, AFTR, or the CPE? Additionally, the proposed text mandates that the TCP MSS Adjust feature is turned off by default. =20 Further, what are cable operators saying for IPv4 CPE routers deployed already that support the TCP MSS Adjust feature and the CPEs are tweaking the value? Cable, specifically does not use PPPOE or rarely and thus issues for PPPOE and MTU are not even seen in cable deployment. See the email from Randy Bush who says his home PPPOE deployment has down-tuned. =20 =20 Regards, =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Monday, May 14, 2012 11:13 AM To: IPv6 Operations Subject: [v6ops] proposed TCP MSS text for rfc6204bis =20 [The CPE router MUST support a TCP MSS Adjust feature on packets traversing the CPE router. By default, the TCP MSS Adjust feature is turned off. ]=20 =20 Some thoughts below on why the above text. =20 The TCP MSS Adjust is not needed for TCP packets sourced or destined to the CPE because the number of such packets at the CPE will be very small. Additionally, we (Wes and I) deliberately left out qualifying the feature for IPv4 or IPv6 because the feature should be supported for both since the CPE also supports 6rd. We have left out specifying any default value for the MSS because there are several values since the MSS is a function of the protocols being used. Note IPv4 CPE routers already support a TCP MSS Adjust knob. Further, the DS-Lite AFTR and the 6rd BR in the SP domain sit between the home TCP client and a TCP server on the Internet. Thus the AFTR and the BR can perform TCP MSS Adjust. It's only for 6rd where the CPE's talk without going through the BR, the CPE has to invoke the TCP MSS Adjust. =20 =20 The problems that the above text alleviates are: =20 (a) Any of native IPv6 and tunneled technologies such as DS-Lite and 6rd can cause ICMPv6 errors for packet too big to the source. Even when the CPE issues the ICMPv6 error to the host connected to the CPE, the Internet access of the host is delayed which is not good. Additionally, what if the CPE passes the host packet to the Internet and one router on the Internet issues the ICMPv6 error with packet too big but a node in the path back blocks the ICMPv6 error. Now the Internet connectivity is really delayed for the host. This summarizes that we do have problems to fix. (b) DS-Lite is an additional problem. Since DS-Lite mandates that the CPE and the AFTR perform fragmentation and reassembly, we have a nasty problem. Reassembly of tunneled encapsulated packets is very complex because the receiver of the fragmented packet has to reassemble before decapsulation. Thus the received needs more memory and a general purpose cpu. If I want to choke a DS-Lite deployment at the AFTR and the CPE, I will generate packets close to 1500 bytes and force tunnel fragmentation. Thus the DS-Lite problem is an attack vector that Daniel Rosen pointed out too. =20 Further, PMTUD is not practical to deploy so the TCP MSS Adjust is still a usable choice. =20 =20 Thanks, =20 Hemant =20 =20 =20 =20 =20 ------_=_NextPart_001_01CD31EE.2B8FD52A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chris and Victor,

 

Did you read this email = before replying?  The issue is not just DS-Lite specific and the = problem is real for any of DS-Lite, 6rd, and native IPv6/IPv4.  The = network for native IPv6 can easily include one IPv6 router in the path = that issues an ICMPv6 error with packet too big for any packet size > = 1280.   Now what does the native IPv6 cable deployment = do?   PMTUD is not a viable solution.   So how else = are the problems solved unless the TCP MSS Adjust is used at the BR, = AFTR, or the CPE?  Additionally, the proposed text mandates that = the TCP MSS Adjust feature is turned off by = default.

 

Further, what are cable = operators saying for IPv4 CPE routers deployed already that support the = TCP MSS Adjust feature and the CPEs are tweaking the value?  Cable, = specifically does not use PPPOE or rarely and thus issues for PPPOE and = MTU are not even seen in cable deployment.  See the email from = Randy Bush who says his home PPPOE deployment has down-tuned.  =

 

Regards,

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Hemant Singh (shemant)
Sent: Monday, May 14, 2012 11:13 = AM
To: IPv6 Operations
Subject: [v6ops] proposed TCP = MSS text for rfc6204bis

 

[The CPE = router MUST support a TCP MSS Adjust feature on packets traversing the = CPE router.  By default, the TCP MSS Adjust feature is turned off. = ]

 

Some thoughts below on why the above = text.

 

The TCP MSS Adjust is not needed for TCP packets = sourced or destined to the CPE because the number of such packets at the = CPE will be very small.  Additionally, we (Wes and I) deliberately = left out qualifying the feature for IPv4 or IPv6 because the feature = should be supported for both since the CPE also supports = 6rd.   We have left out specifying any default value for the = MSS because there are several values since the MSS is a function of the = protocols being used.   Note IPv4 CPE routers already support = a TCP MSS Adjust knob.    Further, the DS-Lite AFTR and = the 6rd BR in the SP domain sit between the home TCP client and a TCP = server on the Internet.  Thus the AFTR and the BR can perform TCP = MSS Adjust.  It’s only for 6rd  where the CPE’s = talk without going through the BR, the CPE has to invoke the TCP MSS = Adjust. 

 

The problems = that the above text alleviates are:

 

(a)    = Any of native IPv6  and tunneled = technologies such as DS-Lite and 6rd can cause ICMPv6 errors for packet = too big to the source.   Even when the CPE issues the ICMPv6 = error to the host connected to the CPE, the Internet access of the host = is delayed which is not good.   Additionally, what if the CPE = passes the host packet to the Internet and one router on the Internet = issues the ICMPv6 error with packet too big but a node in the path back = blocks the ICMPv6 error.   Now the Internet connectivity is = really delayed for the host.   This summarizes that we do have = problems to fix.

(b)    = DS-Lite is an additional problem.   = Since DS-Lite mandates that the CPE and the AFTR perform fragmentation = and reassembly, we have a nasty problem.   Reassembly of = tunneled encapsulated packets is very complex because the receiver of = the fragmented packet has to reassemble before = decapsulation.   Thus the received needs more memory and a = general purpose cpu.  If I want to choke a DS-Lite deployment at = the AFTR and the CPE, I will generate packets close to 1500 bytes and = force tunnel fragmentation.   Thus the DS-Lite problem is an = attack vector that Daniel Rosen pointed out too.

 

Further, = PMTUD is not practical to deploy so the TCP MSS Adjust is still a usable = choice.    

 

Thanks,

 

Hemant =  

 

 

 

 

------_=_NextPart_001_01CD31EE.2B8FD52A-- From Tina.Tsou.Zouting@huawei.com Mon May 14 09:39:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3151821F87F7 for ; Mon, 14 May 2012 09:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syT0NLtMiaGj for ; Mon, 14 May 2012 09:39:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8D28B21F87F5 for ; Mon, 14 May 2012 09:39:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE28058; Mon, 14 May 2012 12:39:53 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 May 2012 09:37:31 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 14 May 2012 09:37:27 -0700 From: Tina TSOU To: Lee Howard Thread-Topic: [v6ops] CGN vs Native IPv6 latency Thread-Index: AQHNMeZfoWu0MRvNK0+5krSXUxv0zZbJ6c4A//+SFjY= Date: Mon, 14 May 2012 16:37:26 +0000 Message-ID: References: , <009101cd31ec$21d6a390$6583eab0$@asgard.org> In-Reply-To: <009101cd31ec$21d6a390$6583eab0$@asgard.org> Accept-Language: en-US, zh-CN 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 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] CGN vs Native IPv6 latency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 16:39:54 -0000 Sent from my iPad On May 14, 2012, at 9:11 AM, "Lee Howard" wrote: >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f > Cameron >> Byrne >> Sent: Monday, May 14, 2012 11:29 AM >> To: IPv6 Ops WG >> Subject: [v6ops] CGN vs Native IPv6 latency >>=20 >> Hi, >>=20 >> I sometimes hear folks say that CGN adds latency or otherwise makes the > network slower, >> and this fact will mean that IPv6 will take more traffic than the slower > CGN IPv4 path. >>=20 >> I do not believe CGN adds any meaningful latency when the CGN path and >> IPv6 are ostensibly the same for the internal network >=20 > Is that a universal architectural assumption? > That implies running CGN on your existing routers, which may not have the > capacity. So > one could upgrade, or add additional devices in network hubs. Or shunt > traffic to a data > center for the CGN. The latter would add a couple of milliseconds. >=20 >> Sometimes, on the external network (the internet), the IPv6 peering is > less robust >> and results in longer paths and therefore higher latency and lower > performance for IPv6. >=20 > Also true. >=20 >> Does anyone have data showing CGN harms network performance from a speed >> perspective? Perhaps in such a way that it may impact a happy eyeballs > implementations >> that may do a "straight race" such as Apple's? >=20 > I think Apple's implementation notices microseconds, which might change y= our > results. =20 >=20 > Thanks for sharing your results though; this is constructive conversation= to > have. Does iPAD support DHCPv6 already? I only see SLAAC supported. If anyone has= the information how to use iPAD for DHCPv6, ping me off-list, thank u. >=20 > Lee >=20 >=20 >>=20 >> CB >> _______________________________________________ >> 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 bs7652@att.com Mon May 14 09:49:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B5B21F882E for ; Mon, 14 May 2012 09:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.857 X-Spam-Level: X-Spam-Status: No, score=-103.857 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vum+nQ-IH6CT for ; Mon, 14 May 2012 09:49:21 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 5E47821F881C for ; Mon, 14 May 2012 09:49:21 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 19731bf4.2aaad0419940.364124.00-557.959932.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 14 May 2012 16:49:21 +0000 (UTC) X-MXL-Hash: 4fb13791682369e5-64fcb7e0cbbd82731a5ff5f36effd47fa68be8d7 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id b8731bf4.0.364086.00-365.959821.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 14 May 2012 16:49:16 +0000 (UTC) X-MXL-Hash: 4fb1378c449439e4-286d2569e30fb355af47c1613f2a921735c3d82c 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 q4EGnF4J010526; Mon, 14 May 2012 12:49:15 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4EGmxIq010111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 12:49:11 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 14 May 2012 12:48:47 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.01.0355.002; Mon, 14 May 2012 12:48:46 -0400 From: "STARK, BARBARA H" To: "Hemant Singh (shemant)" , IPv6 Operations Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0x5Br2+j9mNxDaQuuqarxLphgLSAACPfiwAAB9c0A= Date: Mon, 14 May 2012 16:48:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110FC53A@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C549@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C549@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.106.38] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6110FC53AGAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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=1.0 c=1 a=9UbHitx0bv4A:10 a=6DpfdDpQSUIA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=wMyLg9UG0QzMZcZDHkkA:9 a=oxCtvZIIQmstL-IisV] X-AnalysisOut: [UA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=6D5nLqAUDTdwFG4] X-AnalysisOut: [P:21 a=XiW9msxd64JuGWR5:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA] X-AnalysisOut: [:8 a=4U0FSvKa4_nFYW0GsgcA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S] X-AnalysisOut: [4A:10 a=hTZeC7Yk6K0A:10 a=2RWcza0D2YNy-htT:21 a=cljSete5On] X-AnalysisOut: [_WWnGz:21] Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 16:49:24 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6110FC53AGAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CE Routers that do PPPoE should already know what to do around MTU. We don'= t need an additional requirement on this for their sake. I'm not aware of a= ny new PPPoE-supporting CE routers that have trouble with MTU. Those days a= re long gone. I don't think we need a requirement on this topic. Especially for a mandato= ry function that is off by default. Telling a user with a retail-purchased = CE router to turn 6rd on if they want IPv6 is one thing. Telling them to lo= ok for some TCP MSS Adjust function and try turning it on if their connecti= on occasionally seems to have problems is very different. This doesn't soun= d useful to me. Barbara From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: Monday, May 14, 2012 12:25 PM To: Hemant Singh (shemant); IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis Chris and Victor, Did you read this email before replying? The issue is not just DS-Lite spe= cific and the problem is real for any of DS-Lite, 6rd, and native IPv6/IPv4= . The network for native IPv6 can easily include one IPv6 router in the pa= th that issues an ICMPv6 error with packet too big for any packet size > 12= 80. Now what does the native IPv6 cable deployment do? PMTUD is not a v= iable solution. So how else are the problems solved unless the TCP MSS Ad= just is used at the BR, AFTR, or the CPE? Additionally, the proposed text = mandates that the TCP MSS Adjust feature is turned off by default. Further, what are cable operators saying for IPv4 CPE routers deployed alre= ady that support the TCP MSS Adjust feature and the CPEs are tweaking the v= alue? Cable, specifically does not use PPPOE or rarely and thus issues for= PPPOE and MTU are not even seen in cable deployment. See the email from R= andy Bush who says his home PPPOE deployment has down-tuned. Regards, Hemant From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Heman= t Singh (shemant) Sent: Monday, May 14, 2012 11:13 AM To: IPv6 Operations Subject: [v6ops] proposed TCP MSS text for rfc6204bis [The CPE router MUST support a TCP MSS Adjust feature on packets traversing= the CPE router. By default, the TCP MSS Adjust feature is turned off. ] Some thoughts below on why the above text. The TCP MSS Adjust is not needed for TCP packets sourced or destined to the= CPE because the number of such packets at the CPE will be very small. Add= itionally, we (Wes and I) deliberately left out qualifying the feature for = IPv4 or IPv6 because the feature should be supported for both since the CPE= also supports 6rd. We have left out specifying any default value for the= MSS because there are several values since the MSS is a function of the pr= otocols being used. Note IPv4 CPE routers already support a TCP MSS Adjus= t knob. Further, the DS-Lite AFTR and the 6rd BR in the SP domain sit be= tween the home TCP client and a TCP server on the Internet. Thus the AFTR = and the BR can perform TCP MSS Adjust. It's only for 6rd where the CPE's = talk without going through the BR, the CPE has to invoke the TCP MSS Adjust= . The problems that the above text alleviates are: (a) Any of native IPv6 and tunneled technologies such as DS-Lite and 6r= d can cause ICMPv6 errors for packet too big to the source. Even when the= CPE issues the ICMPv6 error to the host connected to the CPE, the Internet= access of the host is delayed which is not good. Additionally, what if t= he CPE passes the host packet to the Internet and one router on the Interne= t issues the ICMPv6 error with packet too big but a node in the path back b= locks the ICMPv6 error. Now the Internet connectivity is really delayed f= or the host. This summarizes that we do have problems to fix. (b) DS-Lite is an additional problem. Since DS-Lite mandates that the C= PE and the AFTR perform fragmentation and reassembly, we have a nasty probl= em. Reassembly of tunneled encapsulated packets is very complex because t= he receiver of the fragmented packet has to reassemble before decapsulation= . Thus the received needs more memory and a general purpose cpu. If I wa= nt to choke a DS-Lite deployment at the AFTR and the CPE, I will generate p= ackets close to 1500 bytes and force tunnel fragmentation. Thus the DS-Li= te problem is an attack vector that Daniel Rosen pointed out too. Further, PMTUD is not practical to deploy so the TCP MSS Adjust is still a = usable choice. Thanks, Hemant --_000_2D09D61DDFA73D4C884805CC7865E6110FC53AGAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CE Routers that do PPPoE should already know what to= do around MTU. We don’t need an additional requirement on this for t= heir sake. I’m not aware of any new PPPoE-supporting CE routers that = have trouble with MTU. Those days are long gone.

 

I don’t think we need a requirement on this to= pic. Especially for a mandatory function that is off by default. Telling a = user with a retail-purchased CE router to turn 6rd on if they want IPv6 is = one thing. Telling them to look for some TCP MSS Adjust function and try turning it on if their connection occasion= ally seems to have problems is very different. This doesn’t sound use= ful to me.

Barbara

 

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant)
Sent: Monday, May 14, 2012 12:25 PM
To: Hemant Singh (shemant); IPv6 Operations
Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis=

 

Chris and Victor,=

 

Did you read this emai= l before replying?  The issue is not just DS-Lite specific and the pro= blem is real for any of DS-Lite, 6rd, and native IPv6/IPv4.  The netwo= rk for native IPv6 can easily include one IPv6 router in the path that issues an ICMPv6 error with packet too big for any= packet size > 1280.   Now what does the native IPv6 cable dep= loyment do?   PMTUD is not a viable solution.   So how = else are the problems solved unless the TCP MSS Adjust is used at the BR, AFTR, or the CPE?  Additionally, the proposed text mandates t= hat the TCP MSS Adjust feature is turned off by default.<= /p>

 

Further, what are cabl= e operators saying for IPv4 CPE routers deployed already that support the T= CP MSS Adjust feature and the CPEs are tweaking the value?  Cable, spe= cifically does not use PPPOE or rarely and thus issues for PPPOE and MTU are not even seen in cable deployment. = See the email from Randy Bush who says his home PPPOE deployment has down-= tuned. 

 

Regards,

 

Hemant

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shema= nt)
Sent: Monday, May 14, 2012 11:13 AM
To: IPv6 Operations
Subject: [v6ops] proposed TCP MSS text for rfc6204bis

 

[The CPE router MUST support a TCP MSS Adjust fea= ture on packets traversing the CPE router.  By default, the TCP MSS Ad= just feature is turned off. ]

 

Some thoughts below on why the above text.

 

The TCP MSS Adjust is not needed for TCP packets sou= rced or destined to the CPE because the number of such packets at the CPE w= ill be very small.  Additionally, we (Wes and I) deliberately left out= qualifying the feature for IPv4 or IPv6 because the feature should be supported for both since the CPE also suppor= ts 6rd.   We have left out specifying any default value for the M= SS because there are several values since the MSS is a function of the prot= ocols being used.   Note IPv4 CPE routers already support a TCP MSS Adjust knob.    Further, the DS-L= ite AFTR and the 6rd BR in the SP domain sit between the home TCP client an= d a TCP server on the Internet.  Thus the AFTR and the BR can perform = TCP MSS Adjust.  It’s only for 6rd  where the CPE’s talk without going through the BR, the CPE has to invoke the TCP MSS Adjus= t. 

 

The problems that the above text alleviates are:

 

(a)    Any of native IPv6  and tunneled techno= logies such as DS-Lite and 6rd can cause ICMPv6 errors for packet too big t= o the source.   Even when the CPE issues the ICMPv6 error to the = host connected to the CPE, the Internet access of the host is delayed which is not good.   Additionally, what i= f the CPE passes the host packet to the Internet and one router on the Inte= rnet issues the ICMPv6 error with packet too big but a node in the path bac= k blocks the ICMPv6 error.   Now the Internet connectivity is really delayed for the host.   This summarizes t= hat we do have problems to fix.

(b)   DS-Lite is an additional problem.   Since= DS-Lite mandates that the CPE and the AFTR perform fragmentation and reass= embly, we have a nasty problem.   Reassembly of tunneled encapsul= ated packets is very complex because the receiver of the fragmented packet has to reassemble before decapsulation.   = Thus the received needs more memory and a general purpose cpu.  If I w= ant to choke a DS-Lite deployment at the AFTR and the CPE, I will generate = packets close to 1500 bytes and force tunnel fragmentation.   Thus the DS-Lite problem is an attack vector that Daniel Rosen pointed out= too.

 

Further, PMTUD is not practical to deploy so the TCP= MSS Adjust is still a usable choice.    

 

Thanks,

 

Hemant  

 

 

 

 

--_000_2D09D61DDFA73D4C884805CC7865E6110FC53AGAALPA1MSGUSR9NIT_-- From nick@inex.ie Mon May 14 09:53:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F58221F881C for ; Mon, 14 May 2012 09:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLsiocD5MS-c for ; Mon, 14 May 2012 09:53:49 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 747FC21F8818 for ; Mon, 14 May 2012 09:53:49 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q4EGr86R031377 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 May 2012 17:53:08 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FB13897.2090908@inex.ie> Date: Mon, 14 May 2012 17:53:43 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Fernando Gont References: <20120511183001.26924.33901.idtracker@ietfa.amsl.com> <4FAD61B4.2000301@si6networks.com> In-Reply-To: <4FAD61B4.2000301@si6networks.com> X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-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, 14 May 2012 16:53:50 -0000 On 11/05/2012 20:00, Fernando Gont wrote: > Folks (Bjoern, James & Nick), > > COuld youuuble-check/confirm that this version addresses the issues you > raised during the WGLC? yep, looks good to me. Nick > Thanks! > > Best regards, > Fernando > > > > > On 05/11/2012 03:30 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Operations Working >> Group of the IETF. >> >> Title : Implementation Advice for IPv6 Router Advertisement >> Guard (RA-Guard) Author(s) : Fernando Gont Filename : >> draft-ietf-v6ops-ra-guard-implementation-03.txt Pages : 18 >> Date : 2012-05-11 >> >> The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly >> employed to mitigate attack vectors based on forged ICMPv6 Router >> Advertisement messages. Many existing IPv6 deployments rely on RA- >> Guard as the first line of defense against the aforementioned attack >> vectors. However, some implementations of RA-Guard have been found >> to be prone to circumvention by employing IPv6 Extension Headers. >> This document describes the evasion techniques that affect the >> aforementioned implementations, and provides advice on the >> implementation of RA-Guard, such that the RA-Guard evasion vectors >> are eliminated. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-03.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ >> >> _______________________________________________ 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 C.Donley@cablelabs.com Mon May 14 09:55:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D654421F8842 for ; Mon, 14 May 2012 09:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsBBr9ubzTzO for ; Mon, 14 May 2012 09:55:14 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id E598321F8841 for ; Mon, 14 May 2012 09:55:13 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q4EGtCku006347; Mon, 14 May 2012 10:55:12 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 14 May 2012 10:55:12 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 14 May 2012 10:55:12 -0600 From: Chris Donley To: "Hemant Singh (shemant)" , IPv6 Operations Date: Mon, 14 May 2012 10:55:09 -0600 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0x8lNkDpOlXTQJTr6oCtXlGKeq8A== Message-ID: In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C549@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD693A951795cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 16:55:14 -0000 --_000_CBD693A951795cdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hemant, I'm not saying preclude MSS rewrite, I'm just saying don't mandate it. Chris From: Hemant Singh > Date: Mon, 14 May 2012 10:25:25 -0600 To: Hemant Singh >, IPv6 Operat= ions > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis Chris and Victor, Did you read this email before replying? The issue is not just DS-Lite spe= cific and the problem is real for any of DS-Lite, 6rd, and native IPv6/IPv4= . The network for native IPv6 can easily include one IPv6 router in the pa= th that issues an ICMPv6 error with packet too big for any packet size > 12= 80. Now what does the native IPv6 cable deployment do? PMTUD is not a v= iable solution. So how else are the problems solved unless the TCP MSS Ad= just is used at the BR, AFTR, or the CPE? Additionally, the proposed text = mandates that the TCP MSS Adjust feature is turned off by default. Further, what are cable operators saying for IPv4 CPE routers deployed alre= ady that support the TCP MSS Adjust feature and the CPEs are tweaking the v= alue? Cable, specifically does not use PPPOE or rarely and thus issues for= PPPOE and MTU are not even seen in cable deployment. See the email from R= andy Bush who says his home PPPOE deployment has down-tuned. Regards, Hemant From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Monday, May 14, 2012 11:13 AM To: IPv6 Operations Subject: [v6ops] proposed TCP MSS text for rfc6204bis [The CPE router MUST support a TCP MSS Adjust feature on packets traversing= the CPE router. By default, the TCP MSS Adjust feature is turned off. ] Some thoughts below on why the above text. The TCP MSS Adjust is not needed for TCP packets sourced or destined to the= CPE because the number of such packets at the CPE will be very small. Add= itionally, we (Wes and I) deliberately left out qualifying the feature for = IPv4 or IPv6 because the feature should be supported for both since the CPE= also supports 6rd. We have left out specifying any default value for the= MSS because there are several values since the MSS is a function of the pr= otocols being used. Note IPv4 CPE routers already support a TCP MSS Adjus= t knob. Further, the DS-Lite AFTR and the 6rd BR in the SP domain sit be= tween the home TCP client and a TCP server on the Internet. Thus the AFTR = and the BR can perform TCP MSS Adjust. It=92s only for 6rd where the CPE= =92s talk without going through the BR, the CPE has to invoke the TCP MSS A= djust. The problems that the above text alleviates are: (a) Any of native IPv6 and tunneled technologies such as DS-Lite and 6r= d can cause ICMPv6 errors for packet too big to the source. Even when the= CPE issues the ICMPv6 error to the host connected to the CPE, the Internet= access of the host is delayed which is not good. Additionally, what if t= he CPE passes the host packet to the Internet and one router on the Interne= t issues the ICMPv6 error with packet too big but a node in the path back b= locks the ICMPv6 error. Now the Internet connectivity is really delayed f= or the host. This summarizes that we do have problems to fix. (b) DS-Lite is an additional problem. Since DS-Lite mandates that the = CPE and the AFTR perform fragmentation and reassembly, we have a nasty prob= lem. Reassembly of tunneled encapsulated packets is very complex because = the receiver of the fragmented packet has to reassemble before decapsulatio= n. Thus the received needs more memory and a general purpose cpu. If I w= ant to choke a DS-Lite deployment at the AFTR and the CPE, I will generate = packets close to 1500 bytes and force tunnel fragmentation. Thus the DS-L= ite problem is an attack vector that Daniel Rosen pointed out too. Further, PMTUD is not practical to deploy so the TCP MSS Adjust is still a = usable choice. Thanks, Hemant --_000_CBD693A951795cdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hemant,
I'm not saying preclude MSS rewrite, I'm just saying don't mand= ate it.  

Chris
<= div>
From: Hemant Si= ngh <shemant@cisco.com>
<= span style=3D"font-weight:bold">Date: Mon, 14 May 2012 10:25:25 -06= 00
To: Hemant Singh <shemant@cisco.com>, IPv6 Operations &l= t;v6ops@ietf.org>
Subject: Re: [v6ops] proposed TCP MSS text fo= r rfc6204bis

Chris and Victor,

 

Did you read this email before re= plying?  The issue is not just DS-Lite specific and the problem is rea= l for any of DS-Lite, 6rd, and native IPv6/IPv4.  The network for nati= ve IPv6 can easily include one IPv6 router in the path that issues an ICMPv= 6 error with packet too big for any packet size > 1280.   Now = what does the native IPv6 cable deployment do?   PMTUD is not a v= iable solution.   So how else are the problems solved unless the = TCP MSS Adjust is used at the BR, AFTR, or the CPE?  Additionally, the= proposed text mandates that the TCP MSS Adjust feature is turned off by de= fault.

 

Further, what are cable operators saying for IPv4 CPE routers d= eployed already that support the TCP MSS Adjust feature and the CPEs are tw= eaking the value?  Cable, specifically does not use PPPOE or rarely an= d thus issues for PPPOE and MTU are not even seen in cable deployment. = ; See the email from Randy Bush who says his home PPPOE deployment has down= -tuned. 

 

Regards,

 

Hemant

 

From: v6ops-bounces@ietf.org [mail= to:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant)Sent: Monday, May 14, 2012 11:13 AM
To: IPv6 Operations<= br>Subject: [v6ops] proposed TCP MSS text for rfc6204bis<= /span>

 

[The CPE router MUST support a TCP MSS Adjust feature on = packets traversing the CPE router.  By default, the TCP MSS Adjust fea= ture is turned off. ]

 =

Some thoughts below on why the above text.=

 

The TCP MSS Adjust is not needed for TCP packets sourced or destined= to the CPE because the number of such packets at the CPE will be very smal= l.  Additionally, we (Wes and I) deliberately left out qualifying the = feature for IPv4 or IPv6 because the feature should be supported for both s= ince the CPE also supports 6rd.   We have left out specifying any= default value for the MSS because there are several values since the MSS i= s a function of the protocols being used.   Note IPv4 CPE routers= already support a TCP MSS Adjust knob.    Further, the DS-L= ite AFTR and the 6rd BR in the SP domain sit between the home TCP client an= d a TCP server on the Internet.  Thus the AFTR and the BR can perform = TCP MSS Adjust.  It=92s only for 6rd  where the CPE=92s talk with= out going through the BR, the CPE has to invoke the TCP MSS Adjust.  <= o:p>

 

The problems that the above text alleviates are:

 

(a)    Any of nativ= e IPv6  and tunneled technologies such as DS-Lite and 6rd can caus= e ICMPv6 errors for packet too big to the source.   Even when the= CPE issues the ICMPv6 error to the host connected to the CPE, the Internet= access of the host is delayed which is not good.   Additionally,= what if the CPE passes the host packet to the Internet and one router on t= he Internet issues the ICMPv6 error with packet too big but a node in the p= ath back blocks the ICMPv6 error.   Now the Internet connectivity= is really delayed for the host.   This summarizes that we do hav= e problems to fix.

(b)    DS-Lite is an addition= al problem.   Since DS-Lite mandates that the CPE and the AFTR pe= rform fragmentation and reassembly, we have a nasty problem.   Re= assembly of tunneled encapsulated packets is very complex because the recei= ver of the fragmented packet has to reassemble before decapsulation. &= nbsp; Thus the received needs more memory and a general purpose cpu.  = If I want to choke a DS-Lite deployment at the AFTR and the CPE, I will gen= erate packets close to 1500 bytes and force tunnel fragmentation. &nbs= p; Thus the DS-Lite problem is an attack vector that Daniel Rosen pointed o= ut too.

 

Further, PMTUD is not practical to deploy so the TCP MSS Adj= ust is still a usable choice.    

 

Thanks,

 

Hemant=  

 

 

 

 

<= /body> --_000_CBD693A951795cdonleycablelabscom_-- From despres.remi@laposte.net Mon May 14 10:09:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0F121F88C0 for ; Mon, 14 May 2012 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSM6l7nmDaxH for ; Mon, 14 May 2012 10:09:04 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8A53721F88C1 for ; Mon, 14 May 2012 10:09:01 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8A3DD9400C4; Mon, 14 May 2012 19:08:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-32-78366037 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 14 May 2012 19:08:55 +0200 Message-Id: References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 17:09:04 -0000 --Apple-Mail-32-78366037 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-05-14 =E0 18:08, Victor Kuarsingh a =E9crit : > 1++, >=20 >=20 > >Therefore, please don't mandate extra cost and complexity for all = home routers to solve a problem for a small >percentage of hosts = attached to DOCSIS networks that by and large won't be running DS-Lite. Adding some complexity (in the case of MSS rewrite, very limited) to = avoid leaving some customers with a problem, is in general good practice = (IMHO).=20 ...=20 > My feedback to the document contributors previously was that it would = be counter intuitive to have an RFC which I then need to go to a vendor = and say "support RFCxxx, except for sections x, y ,z.". I prefer = "support RFCxxx and here are the extra things I need for my deployment". = This second approach is much more sound IMHO. Having MSS rewrite as a MAY would permit to at least document the = feature, with an explanation. This done, you can then say that you want it, or don't. Regards, RD > Also, previous comments on fixing PMUTD are valid in my opinion. It's = time to fix the network as we need this for IPv6 anyway. >=20 > Regards, >=20 > Victor K >=20 >=20 >=20 >=20 >=20 > On 5/12/12 11:09 AM, "Fred Baker" wrote: >=20 >>=20 >> On May 11, 2012, at 8:30 PM, Hemant Singh (shemant) wrote: >>=20 >>> The CPE router MUST support adjusting the MSS value of the TCP SYN = packets. >>=20 >>=20 >> chair hat off - two points. >>=20 >> One, you were the guy complaining about 6rd sunset as adding an = infinite string of new requirements when it in fact added a very finite = set of new requirements. This seems in fact to be more in line with "an = undelimited set of new requirements - and as noted, it is a layer = violation. >>=20 >> Two, this is a feature I use on my home router. It is not specific to = ds-lite, it is needed for any form of tunneling, due to the lack of = deployment of RFC 4821 and the fact that filtering of ICMP is common. It = prevents the use of IPsec (it can be done before placing traffic into an = IPsec tunnel, but not on traffic that has already been signed), and = doesn't work at all on IPsec-encrypted traffic. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ v6ops mailing list = v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-32-78366037 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


>Therefore, please don't mandate extra cost = and complexity for all home routers to solve a problem for a = small >percentage of hosts = attached to DOCSIS networks that by and large won't be running = DS-Lite.

Adding some complexity (in the case of MSS rewrite, very = limited) to avoid leaving some customers with a problem, is in general = good practice (IMHO). 
... 

My feedback to the document contributors = previously was that it would be counter intuitive to have an RFC which I = then need to go to a vendor and say "support RFCxxx, except for sections = x, y ,z.".  I prefer "support RFCxxx and here are the extra things = I need for my deployment".  This second approach is much more sound = IMHO.

Having MSS rewrite as = a MAY would permit to at least document the feature, with an = explanation.
This done, you can then say that you want it, or = don't.

Regards,
RD

=



Also, previous comments on fixing PMUTD are valid in my = opinion.  It's time to fix the network as we need this for IPv6 = anyway.

Regards,

Victor = K




On 5/12/12 11:09 AM, "Fred Baker" <fred@cisco.com> wrote:

On May 11, 2012, at 8:30 PM, Hemant = Singh (shemant) wrote:

The CPE = router MUST support adjusting the MSS value of the TCP SYN = packets.
=


chair hat off - = two points.

One, you were the guy complaining = about 6rd sunset as adding an infinite string of new requirements when = it in fact added a very finite set of new requirements. This seems in = fact to be more in line with "an undelimited set of new requirements - = and as noted, it is a layer violation.

Two, = this is a feature I use on my home router. It is not specific to = ds-lite, it is needed for any form of tunneling, due to the lack of = deployment of RFC 4821 and the fact that filtering of ICMP is common. It = prevents the use of IPsec (it can be done before placing traffic into an = IPsec tunnel, but not on traffic that has already been signed), and = doesn't work at all on IPsec-encrypted = traffic.
_______________________________________________
v6ops mailing list

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

= --Apple-Mail-32-78366037-- From wesley.george@twcable.com Mon May 14 10:20:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6251C21F88E2 for ; Mon, 14 May 2012 10:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HN+Z1WeGcym for ; Mon, 14 May 2012 10:20:52 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED4E21F88DF for ; Mon, 14 May 2012 10:20:52 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,588,1330923600"; d="scan'208";a="380706376" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 May 2012 13:20:34 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 14 May 2012 13:20:39 -0400 From: "George, Wes" To: Victor Kuarsingh , "v6ops@ietf.org" Date: Mon, 14 May 2012 13:20:38 -0400 Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC Thread-Index: Ac0xNTSEsQLIT8g7Tt2JH/gADKsiiwAvwpvA Message-ID: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:20:53 -0000 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of V= ictor Kuarsingh Sent: Sunday, May 13, 2012 2:21 PM To: v6ops@ietf.org Cc: v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 W= GLC As of now, we still have not changed the tone of the document from the "dep= loy IPv6" and "consider IPv4". Also, there had been some comments from one= of the contributors that would have put stronger language round IPv6-only = methods of operation (to the CPE) which would have operators potentially al= low IPv4 to suffer in performance to promote IPv6 operation - this has not = yet been included. My personal opinion is that making IPv4 operate worse on purpose when given= other options is counterintuitive to the job of an operator. Other opinion= s welcome. [WEG] Victor - as one of the people who has been advocating a serious discu= ssion of IPv6-only, I think that there are two points to make: 1) IPv6-only has the potential to be simpler than dual-stack because you're= not dealing with duplicate network management/scale, etc. Even if the topo= logy is 100% the same between the two, you're still dealing with two separa= te protocols across your configuration, your route storage/convergence, you= r management, your troubleshooting. That is probably something to be minimi= zed where possible, and I think it's realistic to start recommending that s= ince IPv6 is the desired end state, if there's a preference for single stac= k, it makes sense for IPv6 to be the preferred stack over IPv4, even if som= e parts of the transition happen over a fairly long time. 2) I am certainly not advocating making IPv4 worse, and I think that the dr= aft is pretty good at walking the line here - there's a need to keep IPv4 s= ervices working as well as they can for as long as possible to keep legacy = customers happy. That doesn't prevent you from also making sure that you're= making forward progress towards IPv6 (and eventually reducing the amount o= f the network that is using IPv4). I think this draft is ready to progress if you believe that you've covered = the comments above. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Mon May 14 11:28:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5A821F8835 for ; Mon, 14 May 2012 11:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M2TQRRt-pX6 for ; Mon, 14 May 2012 11:28:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F220A21F882F for ; Mon, 14 May 2012 11:28:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SU00X-000Alq-UV; Mon, 14 May 2012 18:28:34 +0000 Date: Mon, 14 May 2012 08:28:32 -1000 Message-ID: From: Randy Bush To: Gert Doering In-Reply-To: <20120514090036.GK84425@Space.Net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> <20120514090036.GK84425@Space.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 18:28:36 -0000 > On Mon, May 14, 2012 at 09:09:21AM +0200, Daniel Roesen wrote: >> PLEASE don't spread the idea of playing with the LAN MTU to cope for any >> WAN interface related issues. I've just managed to convince one CPE >> vendor to NOT arbitrarily mock around with the LAN MTU. >> >> Proper PMTUD behaviour is what is being asked for. Not workarounds >> bouncing around with the LAN MTU. > > Seconded. we all worship at the shrine of pmtud, but ... the problem with PMTUD is the P. in this case, it is bounded within the operator's controlled topology. but the reason they are using ds-lite, or 6rd, or whatever is that, while they own the topology, there are devices in the path which are 'broken'. do we wanna bet there are not devices with broken support of pmtud? randy From fred@cisco.com Mon May 14 11:34:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED96121F8897 for ; Mon, 14 May 2012 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.099 X-Spam-Level: X-Spam-Status: No, score=-108.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2o-eM6lglJh for ; Mon, 14 May 2012 11:34:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2242721F8896 for ; Mon, 14 May 2012 11:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2103; q=dns/txt; s=iport; t=1337020483; x=1338230083; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=uGRLb57DP7YEkjZzZsEylDdjceNZ31vLW7U7mXCM4eY=; b=mWHSfu8xFzYgN5nNG7JgwGII2KF+82kuXyBZLUS5SERz3DG78z9BI0vC 8PTElzK313bAC1SGYBdmeZIF5aIxgirVHkhqqZiD6jN9znEhGjWKNw5jL AgDWLuGDrB0/MrY6lN1FS9dYT5caKuduCoJvYIHKWKNtwLwTYhSYe4vUg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAxPsU+tJXG8/2dsb2JhbABEs3SBB4IVAQEBBBIBJz8QCw4KLlcGNYdsmnqfdIsahR1jBIhkjRmFdYhigWmDCQ X-IronPort-AV: E=Sophos;i="4.75,588,1330905600"; d="scan'208";a="83078055" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 14 May 2012 18:34:37 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4EIYaHn019923; Mon, 14 May 2012 18:34:36 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 14 May 2012 11:34:36 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 14 May 2012 11:34:36 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 14 May 2012 11:34:15 -0700 Message-Id: <273332DD-C037-462B-BEB2-CDA9A937C760@cisco.com> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] CGN vs Native IPv6 latency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 18:34:44 -0000 On May 14, 2012, at 8:29 AM, Cameron Byrne wrote: > Does anyone have data showing CGN harms network performance from a = speed perspective? Perhaps in such a way that it may impact a happy = eyeballs implementations that may do a "straight race" such as Apple's? I personally would be very surprised to see CGN having an impact that is = predictable and significant on an end to end basis. An RTT is composed of the sum of the queuing delay, processing delay, = serialization delay, and propagation delay on each hop end to end. For = the most part, queuing delays will be nominal as bandwidth significantly = exceeds demand; there will usually be one or two hops that act as a = bottleneck, but most are undersubscribed. Processing delays tend to be = nominal as well, and serialization and propagation delays are governed = by the physical layer technology and physics. The argument has to be = either that the CGN is located "somewhere else" and therefore = experiences a different propagation delay (which might be better or = worse than some other path), or that it involves more header reading and = writing.=20 The latter, it certainly does. Now, what does that constitute? Finding = numbers that are public is of course an interesting problem, but I think = we can all agree that available CGN products all maintain "gigabits" of = throughput. If so, that translates to an order of magnitude of = "millions" of packets per second, which inverted means "millionths" of a = second per packet. If we were talking about tens-to-hundreds of = milliseconds, it would be something a user would notice; if it's on the = order of magnitude of milliseconds-to-tens-of-milliseconds, we're on the = same order of magnitude as normal queuing delay variation. And "millionths" isn't even "milliseconds". It's microseconds or = portions thereof.=20 Yes, the execution process of any translation is a bigger deal than a = simple forwarding decision. Having written code that does both, I would = be hard pressed to describe that in larger terms than "a subroutine".= From rajiva@cisco.com Mon May 14 11:53:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCD021F8880 for ; Mon, 14 May 2012 11:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.955 X-Spam-Level: X-Spam-Status: No, score=-9.955 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrqDfFlU8Jmj for ; Mon, 14 May 2012 11:53:05 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id EE72C21F8826 for ; Mon, 14 May 2012 11:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2376; q=dns/txt; s=iport; t=1337021582; x=1338231182; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=3HxbH0uVsedYBK4bLUqmE9iXgeO63H39MFKGvOyuZ8A=; b=HYCd7YHlKK8ZAXi6Iytr59+I35ofjTcqY1PeVfqrsmkwJ9Pyna6YImCn kiU6GyzjY5LAK8U31CVNBdzGL3TsbZDzzL943J0QNRZ0jBxBWhZ/fJ9KK 4yBRBriTyN6iT7X7ZMyQtAM1vcPzRfGss4/NoTLZKpFsMLy6nr0PAcJEN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPJTsU+rRDoJ/2dsb2JhbABEs3SBB4IVAQEBAwEBAQEPAR0KNBAHBAIBCBEEAQELBhcBBgEmHwkIAgQBEggah2cEAQuaaJ9xBIsahR1jBIhkm3CBaYMH X-IronPort-AV: E=Sophos;i="4.75,588,1330905600"; d="scan'208";a="44662465" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 14 May 2012 18:53:02 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4EIr1gn014157; Mon, 14 May 2012 18:53:01 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 13:53:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 13:53:00 -0500 Message-ID: In-Reply-To: <009101cd31ec$21d6a390$6583eab0$@asgard.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] CGN vs Native IPv6 latency Thread-Index: AQGe7ZHALNq+XnC4LUTpReKjwRzsoJcl+tIAgAAu5bA= References: <009101cd31ec$21d6a390$6583eab0$@asgard.org> From: "Rajiv Asati (rajiva)" To: "Lee Howard" , "Cameron Byrne" , "IPv6 Ops WG" X-OriginalArrivalTime: 14 May 2012 18:53:01.0610 (UTC) FILETIME=[C98878A0:01CD3202] Subject: Re: [v6ops] CGN vs Native IPv6 latency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 18:53:06 -0000 > I think Apple's implementation notices microseconds, This begs the beaten-up question - should the happy eyeball algorithm tolerate few 100s of usec to still favor IPv6? Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Lee Howard > Sent: Monday, May 14, 2012 12:11 PM > To: 'Cameron Byrne'; 'IPv6 Ops WG' > Subject: Re: [v6ops] CGN vs Native IPv6 latency >=20 >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > > Of > Cameron > > Byrne > > Sent: Monday, May 14, 2012 11:29 AM > > To: IPv6 Ops WG > > Subject: [v6ops] CGN vs Native IPv6 latency > > > > Hi, > > > > I sometimes hear folks say that CGN adds latency or otherwise makes > > the > network slower, > > and this fact will mean that IPv6 will take more traffic than the > > slower > CGN IPv4 path. > > > > I do not believe CGN adds any meaningful latency when the CGN path and > > IPv6 are ostensibly the same for the internal network >=20 > Is that a universal architectural assumption? > That implies running CGN on your existing routers, which may not have the > capacity. So one could upgrade, or add additional devices in network hubs. > Or shunt traffic to a data center for the CGN. The latter would add a couple > of milliseconds. >=20 > > Sometimes, on the external network (the internet), the IPv6 peering is > less robust > > and results in longer paths and therefore higher latency and lower > performance for IPv6. >=20 > Also true. >=20 > > Does anyone have data showing CGN harms network performance from a > > speed perspective? Perhaps in such a way that it may impact a happy > > eyeballs > implementations > > that may do a "straight race" such as Apple's? >=20 > I think Apple's implementation notices microseconds, which might change > your results. >=20 > Thanks for sharing your results though; this is constructive conversation to > have. >=20 > Lee >=20 >=20 > > > > CB > > _______________________________________________ > > 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 rajiva@cisco.com Mon May 14 11:54:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB721F88D4 for ; Mon, 14 May 2012 11:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.958 X-Spam-Level: X-Spam-Status: No, score=-9.958 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dCMI1qS6S5G for ; Mon, 14 May 2012 11:54:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8479021F88C0 for ; Mon, 14 May 2012 11:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2451; q=dns/txt; s=iport; t=1337021650; x=1338231250; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=SFMvN0RFfIIfJ7XTPLmQeeNmzXPcrAlQAiyo90BY7xU=; b=EqEoyn4+rbNxHpZrLyrhMcNeQARIby8kLgUrFWIgGeblBqgNv+1J59jo /xz3naf84sSZWgJy8L2eFOvr5Z93Nlqs/vFq16fk3OnKtsXxWg1k3Npjh BWgfwWCrJ+I4hY8CgE5EuzTtO/BQOWtmFi9szTntbNOZe0cMZr/qYlJ5z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGpUsU+tJV2a/2dsb2JhbABEs3SBB4IVAQEBBAEBAQ8BHQo0FwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggah2wLmmifdIsahR1jBIhkjiqNRoFpgwc X-IronPort-AV: E=Sophos;i="4.75,588,1330905600"; d="scan'208";a="82907193" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 14 May 2012 18:54:10 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4EIsAMO018944; Mon, 14 May 2012 18:54:10 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 13:54:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 13:54:09 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] CGN vs Native IPv6 latency Thread-Index: Ac0x5looG/uJZ9GdRcegDaqSnMjTxQAG7nuw References: From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" , "IPv6 Ops WG" X-OriginalArrivalTime: 14 May 2012 18:54:09.0843 (UTC) FILETIME=[F2340030:01CD3202] Subject: Re: [v6ops] CGN vs Native IPv6 latency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 18:54:11 -0000 Are there any public/free servers for latency measurement similar to that of speed measurement? That would be helpful here. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Cameron Byrne > Sent: Monday, May 14, 2012 11:29 AM > To: IPv6 Ops WG > Subject: [v6ops] CGN vs Native IPv6 latency >=20 > Hi, >=20 > I sometimes hear folks say that CGN adds latency or otherwise makes the > network slower, and this fact will mean that IPv6 will take more traffic than > the slower CGN IPv4 path. >=20 > I do not believe CGN adds any meaningful latency when the CGN path and > IPv6 are ostensibly the same for the internal network (something an access > network provider controls). Sometimes, on the external network (the > internet), the IPv6 peering is less robust and results in longer paths and > therefore higher latency and lower performance for IPv6. >=20 > Here is some data i casually collect from my phone doing speedtest at > ipv6-test.com. Yes, i know these test are flawed in many ways, but > this is just a casual observation. The test was done using the IPv6-only > connection across an HSPA+ mobile network. The IPv6 path is native end to > end. The "IPv4 path" is IPv6 from the Samsung handset to a NAT64 (CGN) > and then IPv4 to the test server. This is just a casual test using production > and easily available elements. >=20 > IPv4 / IPv6 speeds Mbit/s >=20 > 10.2 /9.07 > http://img2.ipv6- > test.com/speedtest/result/2012/05/14/0b6984f7f589c0fdd10bce5bdaf7b80f. > png >=20 > 11.8/10.8 > http://img2.ipv6- > test.com/speedtest/result/2012/05/14/898322b8348a47dfe31d944bf3d8b15 > 4.png >=20 > 11.8/12.0 > http://img2.ipv6- > test.com/speedtest/result/2012/05/14/ae2cb534d9d5e74020191d072f12745 > 6.png >=20 > As you can see, no noticeable difference in this casual observation. > I am sure someone with time and precision gear can show that CGN addes > ~1ms of latency, but that is hardly impactful on today's internet >=20 > Does anyone have data showing CGN harms network performance from a > speed perspective? Perhaps in such a way that it may impact a happy > eyeballs implementations that may do a "straight race" such as Apple's? >=20 > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Mon May 14 12:32:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFE221F8848 for ; Mon, 14 May 2012 12:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xjy5kKRDfXv9 for ; Mon, 14 May 2012 12:32:48 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0021F8748 for ; Mon, 14 May 2012 12:32:48 -0700 (PDT) Received: by dacx6 with SMTP id x6so6535266dac.31 for ; Mon, 14 May 2012 12:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=laW38AoMDmMtCBPa0nAzOv9pCP+CVLPAgrab/GeVqOU=; b=XxD6kzvh523hk+AyD8fGk8Hh7RRDXpebQqqBM9uOHrGFe19R8d0zAm/EeMuFnFvxVe 7PcX5GTrw+2UzrOcAEo/xaOXIkEfBXN0kVnpIwL8TCnKr8jMCXeDlS0Zxz3tYqY7SGEg wXji5+Lq6ehzV7nyihXTUjTh6a4y5EPV/woy5zFXRFJzHaq1uUsemckieX7rWkoJT+OS 7R9XsD7haKr61q/B/7c8uiD0zF8fVmIROUhJqHCTlBfg+0zbK9D88GRURkFEAq8nV8F1 ARvVS4+YORmUXXMvc3w/htWVUD3J5/eB5GSRW8pxBE/BxhiUvVRGppIFza05ivotv2rA CljA== MIME-Version: 1.0 Received: by 10.68.223.234 with SMTP id qx10mr25650154pbc.154.1337023968467; Mon, 14 May 2012 12:32:48 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Mon, 14 May 2012 12:32:48 -0700 (PDT) In-Reply-To: <4FB10D4B.60009@globis.net> References: <4FB10D4B.60009@globis.net> Date: Mon, 14 May 2012 12:32:48 -0700 Message-ID: From: Cameron Byrne To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 19:32:49 -0000 Ray, Thanks for the detailed review. In line. On Mon, May 14, 2012 at 6:48 AM, Ray Hunter wrote: > I have read this draft. > > I do not pretend to be an expert in this particular field so I'm reviewin= g > it more from a general network operator viewpoint. > > Question 1: > > If a dual stack IPv4+IPv6 client node is communicating to an IPv4 only > server, is the translation path native IPv4 on the client -> 464 -> nativ= e > IPv4 on the server preferable over the translation path native IPv6 on th= e > client -> NAT64 + DNS64 -> native IPv4 on the server? > > That may come down to 2 things: preferable in that it's technically bette= r, > or not preferable in that the operator wants to discourage use of IPv4. > If the client node is dual-stack the translation path will be dictated by the address family choice of the client. 464XLAT CLAT presents both address families as available. Most clients prefer IPv6 when available. With DNS64 in the network, IPv6 / AAAA is always available when asked for. > Question 2: > > If this is true, how do you handle synthesised AAAA records generated by > DNS64 on the PLAT that are needed for an IPv6 only client to communicate > with a IPv4 only server, but which would be disruptive to a dual stack > client communicating to the same IPv4 server? Re: Section 6.3.2 of RFC614= 7. > Would the CLAT have to selectively filter these synthesised AAAA answers > out, depending if it detected that the end client was single or dual stac= k? > 464XLAT is an architecture for an IPv6-only access network, and therefore Section 6.3.2 of RFC6147 does not apply. The CLAT does not do any DNS filtering. The 464 architecture treats traffic as defined here http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-03#section-7.3 > Question 3: > > ref /It is also possible to provide single IPv4/IPv6 translation service, > which will be needed in the future case of IPv6-only servers and peers to= be > reached from legacy IPv4-only hosts./ > > Likewise, would the CLAT or PLAT have to perform any special DNS translat= ion > to handle an IPv4 only client communicating with an IPv6 only server > (DNS46??) > No. > Question 4: > > Would it also be possible to transform IPv4 to IPv6 using RFC6145 for > transport across the IPv6 only edge network, and then perform the statele= ss > inverse transform of RFC6145 to get back your original IPv4 packet at the > physical location of the PLAT (with private IPv4 source address) before > sending this facsimile of the original packet into a standard stateful NA= T44 > device or other translation device? This would effectively be a two step > NAT64. > Yes, but that is not 464XLAT. 464XLAT is 6145 at the CLAT and 6146 at the = PLAT. > 1st motivation: Previous experience with Ethernet -> FDDI translation > bridging suggests to me it's relatively easy to translate outer frame/pac= ket > headers on a symmetrical path like client -> Ethernet -> FDDI -> Ethernet= -> > server , but very difficult to catch all the protocol layer violations an= d > name leaks in devices that perform single translations like client -> > Ethernet -> FDDI -> server. 2nd Motivation: Stateful NAT44 devices are > already abundant, cheap, and well understood. 3rd motivation: you could > deploy an ALG, proxy, or other higher layer alternative at the PLAT locat= ion > if NAT44 didn't work out for some specific protocols. > I don't align with those motivations. Thanks again for the review. CB > Thanks! > RayH > > > Nits & Spelling > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Section 1. > > s/deploy limited IPv4 access service to mobile/deploy a limited IPv4 acce= ss > service to mobile/ > > s/The 464XLAT IPv4 service is limited to application that function/The > 464XLAT IPv4 service is limited to applications that function/ > > s/in a client server model/in a client server model where the server has > been assigned a globally unique IPv4 address,/ > > > Section 3. > > s/ CLAT SHOULD perform router function to facilitate packets forwarding > through the stateless translation even if it is an end-node/ CLAT SHOULD = be > combined with a CPE router function to ensure packets are forwarded throu= gh > the stateless translation even if the CLAT is running on an end-node/ > > Section 4. > > s/crucial for enabling the IPv4-only applications/crucial for enabling > IPv4-only applications/ > > s/Unlike other transition architectures associated with tunneling or/Unli= ke > other transition architectures associated with tunneling or A&P/ > > /If the IXP or another provider operates the PLAT/If the IXP (Internet > Exchange Point ) or another ISP provider operates the PLAT/ > > Section 6. > > s/Incidentally, Japan Internet Exchange(JPIX) is providing 464XLAT trial > service since July 2010. =A0In addition to this, the effectiveness of 464= XLAT > was confirmed in the WIDE camp Spring 2012. =A0The result is described in > [I-D.hazeyama-widecamp-ipv6-only-experience].// > > Suggest removing from BCP document. > > > s/Since there are 2 PDPs required to support 2 address families/Since a > dedicated PDP is required to support each of the IPv4 and IPv6 address > families in Pre-Release 9 3GPP standards/ > > s/Connections sourced from the IPv4 interface are immediately routed to t= he > CLAT function and passed to the IPv6-only mobile network, destine to the > PLAT. =A0In summary, the UE has the CLAT function that does a stateless > translation [RFC6145], but only when required. The mobile network has a P= LAT > that does stateful translation [RFC6146]./Connections sourced from the IP= v4 > interface are immediately routed to the CLAT function and then transporte= d > via the IPv6-only mobile network to the PLAT. =A0In summary, the UE imple= ments > the CLAT function, providing stateless translation of IPv4 traffic > [RFC6145], but only when required. The mobile network implements a PLAT, > providing stateful translation of IPv6 traffic [RFC6146], but again only > when required./ > > > Section 7. > > s/consume gateway function/consumer premises equipment gateway function/ > > Section 7.5. > > s/ In another cases where/ In other cases where/ > > Section 7.6. > > s/not have dedicated IPv6 prefix/not have a dedicated IPv6 prefix/ > > Section 7.7. > > s/The router with CLAT function SHOULD provide common router services suc= h > as DHCP of [RFC1918] addresses , DHCPv6, and DNS service/A router > implementing a CLAT function SHOULD also provide common CPE router > functions, such as DHCP of [RFC1918] addresses, DHCPv6, and DNS services/ > > s/translation of DNS request/translation of DNS requests/ > > Section 7.8. > Suggest this is pretty irrelevant. The introduction already states that > inbound traffic is not supported. > > Section 8. > s/Internet access provider/Internet Service Provider/ =A0[for consistency= ] > > s/without any deep packet inspection for processing the inner IPv4/withou= t > performing deep packet inspection that processes the inner IPv4/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Mon May 14 12:42:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460DF21F866E for ; Mon, 14 May 2012 12:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hha6PbA2qB1l for ; Mon, 14 May 2012 12:42:26 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B683F21F85FF for ; Mon, 14 May 2012 12:42:26 -0700 (PDT) Received: by dacx6 with SMTP id x6so6545289dac.31 for ; Mon, 14 May 2012 12:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PUEdYQaZlJK2N83el4BCgzLtPXROLz2laQYlbiEYzn0=; b=LTvJ9ko9GTTCs/j0BASNjeX9EyQ7H1Z0KDUo9CG4b7g9PnqxtOM7sMEiujltdM1att 3CVpB2AKovxb0M4HJyZzpzDMcTSFxOP//BXAbHEdo652+Nm/jiKMaLtCaDEs7d2pvw0X d/aAmpGYvUH71goDHxQaTvDTKH/IzIiP5hSE60XT6AuQ3SPoCW6o4z2hU9JOV5hogfL7 kYhxcpQgc1ulA7tbm7XMNZ0XYXkSgKAylxUTIhymhgHAPA5b0Dr/Na6ypAohxFMX2ir6 x5RN7f/glj7pGsF9rCZgIdkzPMqvjEomAfTMF0GrDXOzY1ifr2ePjI3/yFXiVgH3d6yt fdCg== MIME-Version: 1.0 Received: by 10.68.223.67 with SMTP id qs3mr25925125pbc.142.1337024546557; Mon, 14 May 2012 12:42:26 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Mon, 14 May 2012 12:42:26 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> Date: Mon, 14 May 2012 12:42:26 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti 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-464xlat-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, 14 May 2012 19:42:27 -0000 On Sun, May 13, 2012 at 9:34 PM, Lorenzo Colitti wrote= : > On Thu, May 10, 2012 at 2:51 PM, Washam Fan wrote: >> >> =A0 The CLAT SHOULD set itself as the DNS server >> =A0 via DHCP or other means and proxy DNS queries for IPv4 and IPv6 >> =A0 clients. >> >> I just don't get it why proxy IPv6 DNS traffic since there would no >> translation applied to IPv6 traffic. Would it be correct to remove the >> words 'and IPv6' of the sentence? > > > Agreed. On a phone that implements tethering, you might want to do this f= or > other reasons, but I don't see anything in 464xlat that would require it. > Agreed, there is no technical requirement to proxy IPv6 DNS traffic. But, it is frequently prudent to do this and most Home Gateways and mobile routers do this for reasons described in rfc5625 From v6ops@globis.net Mon May 14 13:16:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0956F21F8898 for ; Mon, 14 May 2012 13:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtA+21c4iefZ for ; Mon, 14 May 2012 13:16:58 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id F3DD221F8897 for ; Mon, 14 May 2012 13:16:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1221E870088; Mon, 14 May 2012 22:16:57 +0200 (CEST) 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 eeYgfymda4Fl; Mon, 14 May 2012 22:16:51 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 037A6870085; Mon, 14 May 2012 22:16:50 +0200 (CEST) Message-ID: <4FB16831.4020200@globis.net> Date: Mon, 14 May 2012 22:16:49 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Cameron Byrne References: <4FB10D4B.60009@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 20:16:59 -0000 Thanks. Couple of follow ups inline if I may. > Cameron Byrne > 14 May 2012 21:32 > Ray, > > Thanks for the detailed review. In line. > > On Mon, May 14, 2012 at 6:48 AM, Ray Hunter wrote: >> I have read this draft. >> >> I do not pretend to be an expert in this particular field so I'm reviewing >> it more from a general network operator viewpoint. >> >> Question 1: >> >> If a dual stack IPv4+IPv6 client node is communicating to an IPv4 only >> server, is the translation path native IPv4 on the client -> 464 -> native >> IPv4 on the server preferable over the translation path native IPv6 on the >> client -> NAT64 + DNS64 -> native IPv4 on the server? >> >> That may come down to 2 things: preferable in that it's technically better, >> or not preferable in that the operator wants to discourage use of IPv4. >> > > If the client node is dual-stack the translation path will be dictated > by the address family choice of the client. > > 464XLAT CLAT presents both address families as available. Most > clients prefer IPv6 when available. With DNS64 in the network, IPv6 / > AAAA is always available when asked for. Yep. Got that already. What I wanted to know was if you expected 464 to produce less translation errors and operational problems than NAT64+DNS64, so could an operator force use of 464 on dual stack hosts to IPv4 servers by filtering out the synthesised AAAA records of DNS64 for dual stacked hosts, whilst passing them through for single IPv6 only hosts? But I guess that's implementation dependent, and out of scope of your architecture. >> Question 2: >> >> If this is true, how do you handle synthesised AAAA records generated by >> DNS64 on the PLAT that are needed for an IPv6 only client to communicate >> with a IPv4 only server, but which would be disruptive to a dual stack >> client communicating to the same IPv4 server? Re: Section 6.3.2 of RFC6147. >> Would the CLAT have to selectively filter these synthesised AAAA answers >> out, depending if it detected that the end client was single or dual stack? >> > > 464XLAT is an architecture for an IPv6-only access network, and > therefore Section 6.3.2 of RFC6147 does not apply. > > The CLAT does not do any DNS filtering. > > The 464 architecture treats traffic as defined here > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-03#section-7.3 Ack. >> Question 3: >> >> ref /It is also possible to provide single IPv4/IPv6 translation service, >> which will be needed in the future case of IPv6-only servers and peers to be >> reached from legacy IPv4-only hosts./ >> >> Likewise, would the CLAT or PLAT have to perform any special DNS translation >> to handle an IPv4 only client communicating with an IPv6 only server >> (DNS46??) >> > > No. Don't understand this. rfc6145 does not include any DNS content translation AFAIK. How would an IPv4 only host be able to resolve the to-be-translated IPv4 address for a connection to an IPv6 only server that only had a AAAA record, and no native A record? >> Question 4: >> >> Would it also be possible to transform IPv4 to IPv6 using RFC6145 for >> transport across the IPv6 only edge network, and then perform the stateless >> inverse transform of RFC6145 to get back your original IPv4 packet at the >> physical location of the PLAT (with private IPv4 source address) before >> sending this facsimile of the original packet into a standard stateful NAT44 >> device or other translation device? This would effectively be a two step >> NAT64. >> > > Yes, but that is not 464XLAT. 464XLAT is 6145 at the CLAT and 6146 at the PLAT. Ack. >> 1st motivation: Previous experience with Ethernet -> FDDI translation >> bridging suggests to me it's relatively easy to translate outer frame/packet >> headers on a symmetrical path like client -> Ethernet -> FDDI -> Ethernet -> >> server , but very difficult to catch all the protocol layer violations and >> name leaks in devices that perform single translations like client -> >> Ethernet -> FDDI -> server. 2nd Motivation: Stateful NAT44 devices are >> already abundant, cheap, and well understood. 3rd motivation: you could >> deploy an ALG, proxy, or other higher layer alternative at the PLAT location >> if NAT44 didn't work out for some specific protocols. >> > > I don't align with those motivations. > > Thanks again for the review. > > CB Ack. From rajiva@cisco.com Mon May 14 13:58:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E89C21F88BF for ; Mon, 14 May 2012 13:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.961 X-Spam-Level: X-Spam-Status: No, score=-9.961 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dq9lSgIbJwo for ; Mon, 14 May 2012 13:58:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3668821F884A for ; Mon, 14 May 2012 13:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5550; q=dns/txt; s=iport; t=1337029122; x=1338238722; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QCQpBsfmxFgdMytnOB1hPJa8hDMgvYyByTKcS1g5p/k=; b=I0BrVQlfj7oQA2gEL3uVMlmWeD0KH1aWkdqz7QxthHSq4Rk6mzF8B2X/ yo1W8adqkpf6U9RIzmU4gtjj5z2CEGy4H2G62S/+zBlBN0goqSAjsfxDp OMCokLQoFyuiGpruPN/1NGBpu2PIILIuakddOocE76Mg8xrsLbcLY2ndx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEBxsU+tJV2b/2dsb2JhbABEs3SBB4IVAQEBAwEBAQEPARQJCjEDCwUHBAIBCA4DAQMBAQEKBhcBBgEgBh8DBggBAQQBEggah14DBgULmnKWEw2JU4osboUdYwSIZI4qiiyDGoFpgwc X-IronPort-AV: E=Sophos;i="4.75,588,1330905600"; d="scan'208";a="83157762" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 14 May 2012 20:58:41 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4EKwfUr008134; Mon, 14 May 2012 20:58:41 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 15:58:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 15:58:40 -0500 Message-ID: In-Reply-To: <4FB16831.4020200@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat Thread-Index: Ac0yDopH+/Qo3018REqemI3TENMeQQABXlkQ References: <4FB10D4B.60009@globis.net> <4FB16831.4020200@globis.net> From: "Rajiv Asati (rajiva)" To: "Ray Hunter" , "Cameron Byrne" X-OriginalArrivalTime: 14 May 2012 20:58:41.0661 (UTC) FILETIME=[57C0F2D0:01CD3214] Cc: v6ops@ietf.org, draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 20:58:43 -0000 Ray, > How would an IPv4 only host be able to resolve the to-be-translated IPv4 > address for a connection to an IPv6 only server that only had a AAAA > record, and no native A record? I don't think that this use-case is covered by 464XLAT, but Is the v6-only server realistic yet?=20 Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Ray Hunter > Sent: Monday, May 14, 2012 4:17 PM > To: Cameron Byrne > Cc: v6ops@ietf.org WG; draft-ietf-v6ops-464xlat@tools.ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-464xlat >=20 > Thanks. Couple of follow ups inline if I may. > > Cameron Byrne > > 14 May 2012 21:32 > > Ray, > > > > Thanks for the detailed review. In line. > > > > On Mon, May 14, 2012 at 6:48 AM, Ray Hunter wrote: > >> I have read this draft. > >> > >> I do not pretend to be an expert in this particular field so I'm reviewing > >> it more from a general network operator viewpoint. > >> > >> Question 1: > >> > >> If a dual stack IPv4+IPv6 client node is communicating to an IPv4 only > >> server, is the translation path native IPv4 on the client -> 464 -> native > >> IPv4 on the server preferable over the translation path native IPv6 on the > >> client -> NAT64 + DNS64 -> native IPv4 on the server? > >> > >> That may come down to 2 things: preferable in that it's technically better, > >> or not preferable in that the operator wants to discourage use of IPv4. > >> > > > > If the client node is dual-stack the translation path will be dictated > > by the address family choice of the client. > > > > 464XLAT CLAT presents both address families as available. Most > > clients prefer IPv6 when available. With DNS64 in the network, IPv6 / > > AAAA is always available when asked for. > Yep. Got that already. >=20 > What I wanted to know was if you expected 464 to produce less > translation errors and operational problems than NAT64+DNS64, so could > an operator force use of 464 on dual stack hosts to IPv4 servers by > filtering out the synthesised AAAA records of DNS64 for dual stacked > hosts, whilst passing them through for single IPv6 only hosts? >=20 > But I guess that's implementation dependent, and out of scope of your > architecture. > >> Question 2: > >> > >> If this is true, how do you handle synthesised AAAA records generated by > >> DNS64 on the PLAT that are needed for an IPv6 only client to > communicate > >> with a IPv4 only server, but which would be disruptive to a dual stack > >> client communicating to the same IPv4 server? Re: Section 6.3.2 of > RFC6147. > >> Would the CLAT have to selectively filter these synthesised AAAA > answers > >> out, depending if it detected that the end client was single or dual stack? > >> > > > > 464XLAT is an architecture for an IPv6-only access network, and > > therefore Section 6.3.2 of RFC6147 does not apply. > > > > The CLAT does not do any DNS filtering. > > > > The 464 architecture treats traffic as defined here > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-03#section-7.3 > Ack. > >> Question 3: > >> > >> ref /It is also possible to provide single IPv4/IPv6 translation service, > >> which will be needed in the future case of IPv6-only servers and peers to > be > >> reached from legacy IPv4-only hosts./ > >> > >> Likewise, would the CLAT or PLAT have to perform any special DNS > translation > >> to handle an IPv4 only client communicating with an IPv6 only server > >> (DNS46??) > >> > > > > No. > Don't understand this. rfc6145 does not include any DNS content > translation AFAIK. >=20 > How would an IPv4 only host be able to resolve the to-be-translated IPv4 > address for a connection to an IPv6 only server that only had a AAAA > record, and no native A record? > >> Question 4: > >> > >> Would it also be possible to transform IPv4 to IPv6 using RFC6145 for > >> transport across the IPv6 only edge network, and then perform the > stateless > >> inverse transform of RFC6145 to get back your original IPv4 packet at the > >> physical location of the PLAT (with private IPv4 source address) before > >> sending this facsimile of the original packet into a standard stateful > NAT44 > >> device or other translation device? This would effectively be a two step > >> NAT64. > >> > > > > Yes, but that is not 464XLAT. 464XLAT is 6145 at the CLAT and 6146 at the > PLAT. > Ack. > >> 1st motivation: Previous experience with Ethernet -> FDDI translation > >> bridging suggests to me it's relatively easy to translate outer > frame/packet > >> headers on a symmetrical path like client -> Ethernet -> FDDI -> Ethernet > -> > >> server , but very difficult to catch all the protocol layer violations and > >> name leaks in devices that perform single translations like client -> > >> Ethernet -> FDDI -> server. 2nd Motivation: Stateful NAT44 devices are > >> already abundant, cheap, and well understood. 3rd motivation: you could > >> deploy an ALG, proxy, or other higher layer alternative at the PLAT > location > >> if NAT44 didn't work out for some specific protocols. > >> > > > > I don't align with those motivations. > > > > Thanks again for the review. > > > > CB > Ack. >=20 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Mon May 14 14:17:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F96721F8912 for ; Mon, 14 May 2012 14:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssxVoR2kbW7y for ; Mon, 14 May 2012 14:17:16 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 994A621F8911 for ; Mon, 14 May 2012 14:17:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 254A0870088; Mon, 14 May 2012 23:17:15 +0200 (CEST) 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 TpxVn5CVpx8u; Mon, 14 May 2012 23:16:59 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C391D870065; Mon, 14 May 2012 23:16:58 +0200 (CEST) Message-ID: <4FB17649.6070404@globis.net> Date: Mon, 14 May 2012 23:16:57 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <4FB10D4B.60009@globis.net> <4FB16831.4020200@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 21:17:17 -0000 > Rajiv Asati (rajiva) > 14 May 2012 22:58 > Ray, > >> How would an IPv4 only host be able to resolve the to-be-translated IPv4 >> address for a connection to an IPv6 only server that only had a AAAA >> record, and no native A record? > > I don't think that this use-case is covered by 464XLAT, but Is the > v6-only server realistic yet? > > Cheers, > Rajiv > Don't know. I was just triggered by the following sentence in the 464XLAT ID, which is why I asked the question: /It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts./ regards, RayH From marka@isc.org Mon May 14 16:43:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AAB21F882E for ; Mon, 14 May 2012 16:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQsg8k6qNp2W for ; Mon, 14 May 2012 16:43:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A782A21F8813 for ; Mon, 14 May 2012 16:43:23 -0700 (PDT) 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 id C1324C97D0; Mon, 14 May 2012 23:43:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:bce3:89e:bf33:6271]) (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 7CEC5216C33; Mon, 14 May 2012 23:43: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 F187720A2571; Tue, 15 May 2012 09:43:05 +1000 (EST) To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= From: Mark Andrews References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> <20120514090036.GK84425@Space.Net> In-reply-to: Your message of "Mon, 14 May 2012 14:24:17 +0200." Date: Tue, 15 May 2012 09:43:05 +1000 Message-Id: <20120514234305.F187720A2571@drugs.dv.isc.org> Cc: v6ops WG , Daniel Roesen Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 23:43:24 -0000 In message , =?iso-8859-1?Q?R =E9mi_Despr=E9s?= writes: > > Le 2012-05-14 =E0 11:00, Gert Doering a =E9crit : > > On Mon, May 14, 2012 at 09:09:21AM +0200, Daniel Roesen wrote: > ... > >> Proper PMTUD behaviour is what is being asked for. > > +1 > (In particular, ICMP-PTB forwarding needs to be treated everywhere as a rea= > l MUST.) = > > > It remains that MSS rewrite is a simple and effective way to avoid, for TCP= > , consequences of wrong supports of PMTU-PTB. > As such it is a nice-to-have feature. While that helps TCP, it doesn't help UDP based protocols and if anything makes it harder for UDP as TCP "works" so I don't need to open up my filters to let in ICMPv6 PTB. I don't need to properly direct ICMPv6 PTB in the load balancer, etc. It does sometimes take some work to get ICMPv6 PTB filters removed. I've been waiting a month (reported 12/04) for Verisign to fix whois.crsnic.net. It just doesn't work from behind a HE tunnel. For the few other case I've had in the last 8 years most have been fixed within a day or so. > Suggestion (already made to Joel on another thread): document it in 6204bi= > s (a good opportunity for that), but only as a MAY. = > > > RD > > > > _______________________________________________ > 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 randy@psg.com Mon May 14 16:56:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9460621F8883 for ; Mon, 14 May 2012 16:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXVdxrueXwPf for ; Mon, 14 May 2012 16:56:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3F71221F884B for ; Mon, 14 May 2012 16:56:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SU58I-000BfW-Hi; Mon, 14 May 2012 23:56:54 +0000 Date: Mon, 14 May 2012 13:56:52 -1000 Message-ID: From: Randy Bush To: Mark Andrews In-Reply-To: <20120514234305.F187720A2571@drugs.dv.isc.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> <20120514090036.GK84425@Space.Net> <20120514234305.F187720A2571@drugs.dv.isc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Daniel Roesen , v6ops WG Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 23:56:59 -0000 > For the few other case I've had in the last 8 years most have been > fixed within a day or so. no prob for grandma to do the same, eh? randy From dwing@cisco.com Mon May 14 16:59:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3D21F8528 for ; Mon, 14 May 2012 16:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.112 X-Spam-Level: X-Spam-Status: No, score=-110.112 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kangtEMBLniI for ; Mon, 14 May 2012 16:59:40 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B764C21F8517 for ; Mon, 14 May 2012 16:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3592; q=dns/txt; s=iport; t=1337039980; x=1338249580; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=bRB4yUHZL+uCtXV3S9dXMVjkbLdmn0gm0Iu0jQ1AHkU=; b=FfV6ZGGspe1/9nLFET8wGyvqQEcPWZEkZs/DeSQ4rxobcStQPXr4ZKn5 naupMx0m3fER/2GLyFSzym/3dSveAcHNPciz26lJ6NkopTEv4gNInzhx1 QOBFLJ/1+Txep3jIQ2phFGUCqJCzr4aHnLTljwKn5AGCAIxe4D4tNfi9b 4=; X-IronPort-AV: E=Sophos;i="4.75,590,1330905600"; d="scan'208";a="41676265" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 14 May 2012 23:59:40 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4ENxenf021966; Mon, 14 May 2012 23:59:40 GMT From: "Dan Wing" To: "'Rajiv Asati \(rajiva\)'" , "'Lee Howard'" , "'Cameron Byrne'" , "'IPv6 Ops WG'" References: <009101cd31ec$21d6a390$6583eab0$@asgard.org> In-Reply-To: Date: Mon, 14 May 2012 16:59:39 -0700 Message-ID: <171501cd322d$a013c620$e03b5260$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQGe7ZHALNq+XnC4LUTpReKjwRzsoJcl+tIAgAAu5bCAAFOwIA== Content-Language: en-us Subject: [v6ops] Happy Eyeballs and preferring IPv6 [was RE: CGN vs Native IPv6 latency] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 May 2012 23:59:41 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Rajiv Asati (rajiva) > Sent: Monday, May 14, 2012 11:53 AM > To: Lee Howard; Cameron Byrne; IPv6 Ops WG > Subject: Re: [v6ops] CGN vs Native IPv6 latency > > > I think Apple's implementation notices microseconds, > > This begs the beaten-up question - should the happy eyeball algorithm > tolerate few 100s of usec to still favor IPv6? There is text in Happy Eyeballs explaining reasons to prefer IPv6 over IPv6 (*). But today it does not matter at all to users, especially users on dual-stack clients accessing dual-stack servers. IPv4-only clients accessing servers, or dual-stack clients accessing IPv4-only servers may well experience port starvation, but users will attribute that problem to their "old" IPv4-only client or to the lack of IPv6 on the server. All that assumes that port starvation will exist; that is entirely dependent on how many ports the ISP allocates at busy hour to their subscribers. (*) "Delay IPv4", http://tools.ietf.org/html/rfc6555#section-4.1 -d > Cheers, > Rajiv > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > > Of Lee Howard > > Sent: Monday, May 14, 2012 12:11 PM > > To: 'Cameron Byrne'; 'IPv6 Ops WG' > > Subject: Re: [v6ops] CGN vs Native IPv6 latency > > > > > > > > > -----Original Message----- > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > > Behalf > > > Of > > Cameron > > > Byrne > > > Sent: Monday, May 14, 2012 11:29 AM > > > To: IPv6 Ops WG > > > Subject: [v6ops] CGN vs Native IPv6 latency > > > > > > Hi, > > > > > > I sometimes hear folks say that CGN adds latency or otherwise makes > > > the > > network slower, > > > and this fact will mean that IPv6 will take more traffic than the > > > slower > > CGN IPv4 path. > > > > > > I do not believe CGN adds any meaningful latency when the CGN path > and > > > IPv6 are ostensibly the same for the internal network > > > > Is that a universal architectural assumption? > > That implies running CGN on your existing routers, which may not have > the > > capacity. So one could upgrade, or add additional devices in network > hubs. > > Or shunt traffic to a data center for the CGN. The latter would add > a > couple > > of milliseconds. > > > > > Sometimes, on the external network (the internet), the IPv6 peering > is > > less robust > > > and results in longer paths and therefore higher latency and lower > > performance for IPv6. > > > > Also true. > > > > > Does anyone have data showing CGN harms network performance from a > > > speed perspective? Perhaps in such a way that it may impact a > happy > > > eyeballs > > implementations > > > that may do a "straight race" such as Apple's? > > > > I think Apple's implementation notices microseconds, which might > change > > your results. > > > > Thanks for sharing your results though; this is constructive > conversation to > > have. > > > > Lee > > > > > > > > > > CB > > > _______________________________________________ > > > 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 cb.list6@gmail.com Mon May 14 17:19:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B021F8957 for ; Mon, 14 May 2012 17:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_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 DBkG76eiOv2k for ; Mon, 14 May 2012 17:19:47 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEDFB21F8956 for ; Mon, 14 May 2012 17:19:46 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6974246pbc.31 for ; Mon, 14 May 2012 17:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YZdepN4Fdsc7o7tZlxiK2rUnCLChFGmGHEybFKeQUXo=; b=LeqYfOrfTc6kRGk3Wy+UzIoYW4yTwaq3gEDClPVrupdx0xOgqNTx59IyCmPGMhHUmR kqhPyd4/JBCzkp344V+dAY6IA2l5ebCApvWHUyDeEeAbx49vFBeQbjKHfdVlfFW8Y90c N+fhXwVtURfJNxLNPFHq24zD3tNgS+2y00rQt55YjxyCDcPLEOaYq0Lxhv+mQg8gzzbm we0pfX6y4SCzBJQRzsFc7+9RXLMOwnfuH/WuTZtHShW/hLRQIdo2hDXZe18VK+d94Soe sOu6Hms9krRxQ9LggaTAvzCOkivjerv8O+OFVWerf0RZhOTg4YwKHOnzYEyg3MwNk4l+ zv4w== MIME-Version: 1.0 Received: by 10.68.223.234 with SMTP id qx10mr27399296pbc.154.1337041186582; Mon, 14 May 2012 17:19:46 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Mon, 14 May 2012 17:19:46 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Mon, 14 May 2012 17:19:46 -0700 (PDT) In-Reply-To: <171501cd322d$a013c620$e03b5260$@com> References: <009101cd31ec$21d6a390$6583eab0$@asgard.org> <171501cd322d$a013c620$e03b5260$@com> Date: Mon, 14 May 2012 17:19:46 -0700 Message-ID: From: Cameron Byrne To: Dan Wing Content-Type: multipart/alternative; boundary=047d7b15fe0bf9eeff04c0082885 Cc: IPv6 Ops WG Subject: Re: [v6ops] Happy Eyeballs and preferring IPv6 [was RE: CGN vs Native IPv6 latency] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 00:19:48 -0000 --047d7b15fe0bf9eeff04c0082885 Content-Type: text/plain; charset=ISO-8859-1 On May 14, 2012 4:59 PM, "Dan Wing" wrote: > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > > Of Rajiv Asati (rajiva) > > Sent: Monday, May 14, 2012 11:53 AM > > To: Lee Howard; Cameron Byrne; IPv6 Ops WG > > Subject: Re: [v6ops] CGN vs Native IPv6 latency > > > > > I think Apple's implementation notices microseconds, > > > > This begs the beaten-up question - should the happy eyeball algorithm > > tolerate few 100s of usec to still favor IPv6? > > There is text in Happy Eyeballs explaining reasons to prefer IPv6 > over IPv6 (*). But today it does not matter at all to users, > especially users on dual-stack clients accessing dual-stack > servers. IPv4-only clients accessing servers, or dual-stack > clients accessing IPv4-only servers may well experience port > starvation, but users will attribute that problem to their > "old" IPv4-only client or to the lack of IPv6 on the server. > All that assumes that port starvation will exist; that is > entirely dependent on how many ports the ISP allocates at busy > hour to their subscribers. > > (*) "Delay IPv4", http://tools.ietf.org/html/rfc6555#section-4.1 > > -d > And port exhaustion should not be expected in the real world of stateful translation that may use port overloading CB > > > Cheers, > > Rajiv > > > > > > > -----Original Message----- > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > > Behalf > > > Of Lee Howard > > > Sent: Monday, May 14, 2012 12:11 PM > > > To: 'Cameron Byrne'; 'IPv6 Ops WG' > > > Subject: Re: [v6ops] CGN vs Native IPv6 latency > > > > > > > > > > > > > -----Original Message----- > > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > > > Behalf > > > > Of > > > Cameron > > > > Byrne > > > > Sent: Monday, May 14, 2012 11:29 AM > > > > To: IPv6 Ops WG > > > > Subject: [v6ops] CGN vs Native IPv6 latency > > > > > > > > Hi, > > > > > > > > I sometimes hear folks say that CGN adds latency or otherwise makes > > > > the > > > network slower, > > > > and this fact will mean that IPv6 will take more traffic than the > > > > slower > > > CGN IPv4 path. > > > > > > > > I do not believe CGN adds any meaningful latency when the CGN path > > and > > > > IPv6 are ostensibly the same for the internal network > > > > > > Is that a universal architectural assumption? > > > That implies running CGN on your existing routers, which may not have > > the > > > capacity. So one could upgrade, or add additional devices in network > > hubs. > > > Or shunt traffic to a data center for the CGN. The latter would add > > a > > couple > > > of milliseconds. > > > > > > > Sometimes, on the external network (the internet), the IPv6 peering > > is > > > less robust > > > > and results in longer paths and therefore higher latency and lower > > > performance for IPv6. > > > > > > Also true. > > > > > > > Does anyone have data showing CGN harms network performance from a > > > > speed perspective? Perhaps in such a way that it may impact a > > happy > > > > eyeballs > > > implementations > > > > that may do a "straight race" such as Apple's? > > > > > > I think Apple's implementation notices microseconds, which might > > change > > > your results. > > > > > > Thanks for sharing your results though; this is constructive > > conversation to > > > have. > > > > > > Lee > > > > > > > > > > > > > > CB > > > > _______________________________________________ > > > > 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 > --047d7b15fe0bf9eeff04c0082885 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 14, 2012 4:59 PM, "Dan Wing" <dwing@cisco.com> wrote:
>
> > -----Original Message-----
> > From: v6ops-bounces@iet= f.org [mailto:v6ops-bounces@i= etf.org] On Behalf
> > Of Rajiv Asati (rajiva)
> > Sent: Monday, May 14, 2012 11:53 AM
> > To: Lee Howard; Cameron Byrne; IPv6 Ops WG
> > Subject: Re: [v6ops] CGN vs Native IPv6 latency
> >
> > > I think Apple's implementation notices microseconds,
> >
> > This begs the beaten-up question - should the happy eyeball algor= ithm
> > tolerate few 100s of usec to still favor IPv6?
>
> There is text in Happy Eyeballs explaining reasons to prefer IPv6
> over IPv6 (*). =A0But today it does not matter at all to users,
> especially users on dual-stack clients accessing dual-stack
> servers. =A0IPv4-only clients accessing servers, or dual-stack
> clients accessing IPv4-only servers may well experience port
> starvation, but users will attribute that problem to their
> "old" IPv4-only client or to the lack of IPv6 on the server.=
> All that assumes that port starvation will exist; that is
> entirely dependent on how many ports the ISP allocates at busy
> hour to their subscribers.
>
> (*) "Delay IPv4", http://tools.ietf.org/html/rfc6555#section-4.1
>
> -d
>

And port exhaustion should not be expected in the real world of stateful= translation that may use port overloading

CB
>
> > Cheers,
> > Rajiv
> >
> >
> > > -----Original Message-----
> > > From: v6ops-bounce= s@ietf.org [mailto:v6ops-boun= ces@ietf.org] On
> > Behalf
> > > Of Lee Howard
> > > Sent: Monday, May 14, 2012 12:11 PM
> > > To: 'Cameron Byrne'; 'IPv6 Ops WG'
> > > Subject: Re: [v6ops] CGN vs Native IPv6 latency
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: v6ops-b= ounces@ietf.org [mailto:v6ops= -bounces@ietf.org] On
> > > Behalf
> > > > Of
> > > Cameron
> > > > Byrne
> > > > Sent: Monday, May 14, 2012 11:29 AM
> > > > To: IPv6 Ops WG
> > > > Subject: [v6ops] CGN vs Native IPv6 latency
> > > >
> > > > Hi,
> > > >
> > > > I sometimes hear folks say that CGN adds latency or oth= erwise makes
> > > > the
> > > network slower,
> > > > and this fact will mean that IPv6 will take more traffi= c than the
> > > > slower
> > > CGN IPv4 path.
> > > >
> > > > I do not believe CGN adds any meaningful latency when t= he CGN path
> > and
> > > > IPv6 are ostensibly the same for the internal network > > >
> > > Is that a universal architectural assumption?
> > > That implies running CGN on your existing routers, which may= not have
> > the
> > > capacity. =A0So one could upgrade, or add additional devices= in network
> > hubs.
> > > Or shunt traffic to a data center for the CGN. =A0The latter= would add
> > a
> > couple
> > > of milliseconds.
> > >
> > > > Sometimes, on the external network (the internet), the = IPv6 peering
> > is
> > > less robust
> > > > and results in longer paths and therefore higher latenc= y and lower
> > > performance for IPv6.
> > >
> > > Also true.
> > >
> > > > Does anyone have data showing CGN harms network perform= ance from a
> > > > speed perspective? =A0Perhaps in such a way that it may= impact a
> > happy
> > > > eyeballs
> > > implementations
> > > > that may do a "straight race" such as Apple&#= 39;s?
> > >
> > > I think Apple's implementation notices microseconds, whi= ch might
> > change
> > > your results.
> > >
> > > Thanks for sharing your results though; this is constructive=
> > conversation to
> > > have.
> > >
> > > Lee
> > >
> > >
> > > >
> > > > CB
> > > > _______________________________________________
> > > > v6ops mailing list
> > > > v6ops@ietf.org > > > > https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > http= s://www.ietf.org/mailman/listinfo/v6ops
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
>

--047d7b15fe0bf9eeff04c0082885-- From marka@isc.org Mon May 14 17:25:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2955621F8956 for ; Mon, 14 May 2012 17:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhUWBncGHCQn for ; Mon, 14 May 2012 17:25:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9C921F8621 for ; Mon, 14 May 2012 17:25:20 -0700 (PDT) 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 D213B5F99AB; Tue, 15 May 2012 00:25:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:bce3:89e:bf33:6271]) (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 AFE59216C33; Tue, 15 May 2012 00:25:04 +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 A583420A2A17; Tue, 15 May 2012 10:25:02 +1000 (EST) To: Randy Bush From: Mark Andrews References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> <20120514090036.GK84425@Space.Net> <20120514234305.F187720A2571@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 14 May 2012 13:56:52 -1000." Date: Tue, 15 May 2012 10:25:02 +1000 Message-Id: <20120515002502.A583420A2A17@drugs.dv.isc.org> Cc: Daniel Roesen , v6ops WG Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 00:25:21 -0000 In message , Randy Bush writes: > > For the few other case I've had in the last 8 years most have been > > fixed within a day or so. > > no prob for grandma to do the same, eh? Grandma will complain to the ISP "I can't reach ...." and if the ISP is deploying 6rd / DS-lite and, if they are compentent, they will be testing using 6rd / DS-lite. The ISP knows if they are deploying 6rd / DS-lite so it is not unreasonable to expect them to be testing with these technologies in place. The myth that you can drop all ICMP/ICMPv6 packets and have a working network needs to be broken. The myth that you need to drop ICMP or ICMPv6 needs to be broken. ICMP/ICMPv6 is no better or worse that a UDP, TCP or STCP packet. If you let the latter through you should be letting the former through. Yes there have been specific bugs in the past and given the granularity of the filters it was all ICMP or nothing and at the time most packets did not set DF. The world is very different today. With IPv6 you have near 100% DF so the trade offs are very different. Even IPv4 has changed, for TCP you are getting close to 100% DF traffic these days. It's time to stop kludging around broken firewalls. If you can't configure a firewall properly don't configure one. Firewall vendors need to check ICMP{v6} packets and if they match a flow/rule let them through by default. NAT vendors need to check ICMP{v6} packets and map the contents if appropriate. This isn't rocket science. Flip the source and destination in the ICMP{v6} payload and if you would let the payload in testing only the resulting source and destination details pass the ICMP{v6} packet. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Mon May 14 17:27:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A27D21F88ED for ; Mon, 14 May 2012 17:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnGXjPUoNsI0 for ; Mon, 14 May 2012 17:27:40 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCC821F88A3 for ; Mon, 14 May 2012 17:27:40 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2201698ggn.31 for ; Mon, 14 May 2012 17:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=stf9sU53tMUwRmQgK9fWyBwL0nWQwxtcS+OThOgLaNk=; b=pChirzybOebHmP1HkIFe+X9fAqbuwgPdah/UfHdkgN1AzRbWd4H/e3t8Vk6XVfap3f E0f6Nvd28J/IJttptXcNavk9HtsykfIVFd494PEG44m3oRWCAPt/QY9D7BqviiH87jIq p3L5lBQQfpQY4sYNWZ3bGtPS0xn7BR+bhOcVU0atKm7OrLM+6fhYMzrSBSmX50zqcYMC oIRezRqcwr4n0KZ70jjZtN7knPi+XqodCor3kmQsy8+tLwbF7R7uYMlY5Z/ZaV60tH1x qdJFAYyFbrvFUwKbjF5xvlSe6sZzZHMpyllT9UiiNhwByFNmUEehqHkEZZjnSJ5bJUUr phJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=stf9sU53tMUwRmQgK9fWyBwL0nWQwxtcS+OThOgLaNk=; b=ovq27HazOQLg1zJ3GbS/1E+7q0dMCb/53f6EGzXdPIFUDj77z2FrsHIxYU0XW72B6a jx8Nrc8+m+Yjw5esHUfr6Gxq9EjpSWAD/rpglTrQQQg+eBTqJ+J+VxO97B51BS8f3hWE PO2yGTqBCCpNLL1JlDLNl/BYADQyFkUmVoQbpCrml+688obDVTAVYXbO61a5LvsSNiA6 AYap0VAUz06+JcSIlEeVlsDd6jg0SAjCaRI+5DVFkPMZKL5aO8+xN5rMU3w0xIIACmlk CaZvlNmYq9eBHsPHGZXK7JW5FndBTKAPZZZXQFMjvPzNzwY4Hy44asXlfQL92jE3skeM OAKw== Received: by 10.60.14.41 with SMTP id m9mr14621210oec.57.1337041659941; Mon, 14 May 2012 17:27:39 -0700 (PDT) Received: by 10.60.14.41 with SMTP id m9mr14621198oec.57.1337041659762; Mon, 14 May 2012 17:27:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Mon, 14 May 2012 17:27:19 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> From: Lorenzo Colitti Date: Tue, 15 May 2012 09:27:19 +0900 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8fb1fac02e175a04c00845e5 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnzy651ZHA/txNY+GJJr3ZHdGiJCy8HkJ8WspDUVkx/SD3lEH/AmWsLlGW2zG86eNaAsSqoHS4QPRrrB2O1eaWxa51wgshYvMNXMyyHhM0X1IWnfad2NZaDwdU5/sMsP8f4WOtf Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 15 May 2012 00:27:41 -0000 --e89a8fb1fac02e175a04c00845e5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 15, 2012 at 4:42 AM, Cameron Byrne wrote: > Agreed, there is no technical requirement to proxy IPv6 DNS traffic. > But, it is frequently prudent to do this and most Home Gateways and > mobile routers do this for reasons described in rfc5625 > Ack. Then say SHOULD for IPv4 DNS queries (since things really don't work without it) and MAY for IPv6. SHOULD is quite a strong statement. If you put in a SHOULD for proxying IPv6 DNS requests, then you're saying that "there may exist valid reasons in particular circumstances to NOT proxy IPv6 DNS requests, but the full implications should be understood and carefully weighed before choosing a different course." I don't see the harm if you don't proxy IPv6 DNS lookups. Saying "most current implementations seem to do this by default" is not sufficient to say SHOULD IMO. So you're needlessly restricting implementation. --e89a8fb1fac02e175a04c00845e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 15, 2012 at 4:42 AM, Cameron Byrne <= span dir=3D"ltr"><cb.list6@gmail.com> wrote:
Agreed, there is no technical requi= rement to proxy IPv6 DNS traffic.
But, it is frequently prudent to do this and most Home Gateways and
mobile routers do this for reasons described in =A0rfc5625

Ack. Then say SHOULD for IPv4 DNS queries (sinc= e things really don't work without it) and MAY for IPv6.

=
SHOULD is quite a strong statement. If you put in a SHOULD for p= roxying IPv6 DNS requests, then you're saying that "there may exis= t valid reasons in particular circumstances to NOT proxy IPv6 DNS requests,= but the full=A0implications should be understood and carefully weighed=A0b= efore=A0choosing a different course."

I don't see the harm if you don't proxy IPv6 DNS loo= kups. Saying "most current implementations seem to do this by default&= quot; is not sufficient to say SHOULD IMO. So you're needlessly restric= ting implementation.
--e89a8fb1fac02e175a04c00845e5-- From dwing@cisco.com Mon May 14 17:44:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2600821F8823 for ; Mon, 14 May 2012 17:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.408 X-Spam-Level: X-Spam-Status: No, score=-110.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7g4Ca+e6IoO for ; Mon, 14 May 2012 17:44:43 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66E2A21F87D8 for ; Mon, 14 May 2012 17:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1529; q=dns/txt; s=iport; t=1337042683; x=1338252283; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=MlpNRXSemliG/i3pScOcZbJZyitPjtW5sM99bfyEXrs=; b=ebdZv0LEyKPFh+iVKuUfxK14MY+3nf5h6kzc9aPMlE/1IInNs6sLPzMA f9yJr+5/hxfTUIygd/Kbik2EdnRB+q/OHrt7ZUzHSuSY02/opom1x/gBg ZvPizXUeCwtrA54ykV4QlhxTq6VWsFC0uoy5IeOs03A6zH9PzHnlWKqe3 g=; X-IronPort-AV: E=Sophos;i="4.75,590,1330905600"; d="scan'208";a="44794047" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 15 May 2012 00:44:42 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4F0ifOE023645; Tue, 15 May 2012 00:44:42 GMT From: "Dan Wing" To: "'Cameron Byrne'" References: <009101cd31ec$21d6a390$6583eab0$@asgard.org> <171501cd322d$a013c620$e03b5260$@com> In-Reply-To: Date: Mon, 14 May 2012 17:44:41 -0700 Message-ID: <173a01cd3233$ea8ea430$bfabec90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0yMH4osa1dr1ZbTLKaOiwO62qGgAAARnNw Content-Language: en-us Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] Happy Eyeballs and preferring IPv6 [was RE: CGN vs Native IPv6 latency] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 00:44:44 -0000 ... > And port exhaustion should not be expected in the real world of > stateful translation that may use port overloading It can help, but if all the subscribers visit the same popular IPv4 address, port overloading can fail to provide service -- its law of large numbers collapses. There is a proposal to improve one of the problems (TCP server going into TIMEWAIT, see (*) and RFC6191) but the number of active connections to a popular server remains a problem if the server is suddenly more popular than anticipated by the port allocation. Stateless MAP ("A+P") techniques can suffer significantly from attempts to use port overloading, because their user base is smaller (often one house), and a stateful CGN suffers fewer problems (because it can utilize more port numbers if there is sudden popularity to a single IPv4 server). The use of SPDY, which reduces the number of TCP connections to servers, will help all of these problems. (*) http://www.ietf.org/proceedings/83/slides/slides-83-tcpm-2.ppt http://tools.ietf.org/html/draft-naito-nat-resource-optimizing-extension Port overloading also interferes with, or breaks, peer to peer applications such as SIP, Skype, Bittorrent, Octoshape, and the upcoming WEBRTC. I know those applications are often not well loved for a variety of reasons. That is documented in REQ-1 of RFC5382, which says port overloading is bad. I realize business reasons cause a lot of networks to be deployed violating that requirement. -d From cb.list6@gmail.com Mon May 14 17:56:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C1721F88C0 for ; Mon, 14 May 2012 17:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwXZWPyxio9k for ; Mon, 14 May 2012 17:56:09 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 004ED21F884C for ; Mon, 14 May 2012 17:56:08 -0700 (PDT) Received: by dacx6 with SMTP id x6so6808130dac.31 for ; Mon, 14 May 2012 17:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rejiTAH8xZ9tOylqmsydY3BJLvqFs8aEuKkGX0r84qs=; b=VFK+pe3zOmhyiorWAedn5f6IsN8Lsi0yw2gJ9c5L3REy9Uf17ihetJp2P9vk/pMICZ f59Ic4dCqukMsx/z+2F/6RyoefDyGbWAhL+LAko21rrH72IDWnmDyMv1HvOCZuz3Iyvl nAvzx4+wyJjOhqK1edbGhol4AG+Udo/OVa5Mc0DJp83RxXpH+vKM2vh/TS/WuOgk2Z1h HTZxS2GC9+dEugoVc06XSrSE5rdXJ23b8ao5RbjueDXfcrgxb+uF43xIgMeGPfZ2me0Y h3btFU7dB41ITio9h7DPSYUL3Q1jSoz7DraRXHiUFR+nHzUM9IhkaMpAaMxeXzy0RKcg TFsg== MIME-Version: 1.0 Received: by 10.68.226.163 with SMTP id rt3mr72565pbc.41.1337043368692; Mon, 14 May 2012 17:56:08 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Mon, 14 May 2012 17:56:08 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Mon, 14 May 2012 17:56:08 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> Date: Mon, 14 May 2012 17:56:08 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=e89a8ff2495d0a4ad304c008aba2 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 15 May 2012 00:56:09 -0000 --e89a8ff2495d0a4ad304c008aba2 Content-Type: text/plain; charset=ISO-8859-1 On May 14, 2012 5:27 PM, "Lorenzo Colitti" wrote: > > On Tue, May 15, 2012 at 4:42 AM, Cameron Byrne wrote: >> >> Agreed, there is no technical requirement to proxy IPv6 DNS traffic. >> But, it is frequently prudent to do this and most Home Gateways and >> mobile routers do this for reasons described in rfc5625 > > > Ack. Then say SHOULD for IPv4 DNS queries (since things really don't work without it) and MAY for IPv6. > > SHOULD is quite a strong statement. If you put in a SHOULD for proxying IPv6 DNS requests, then you're saying that "there may exist valid reasons in particular circumstances to NOT proxy IPv6 DNS requests, but the full implications should be understood and carefully weighed before choosing a different course." > > I don't see the harm if you don't proxy IPv6 DNS lookups. Saying "most current implementations seem to do this by default" is not sufficient to say SHOULD IMO. So you're needlessly restricting implementation. Ok. Will make this change. CB --e89a8ff2495d0a4ad304c008aba2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 14, 2012 5:27 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Tue, May 15, 2012 at 4:42 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> Agreed, there is no technical requirement to proxy IPv6 DNS traffi= c.
>> But, it is frequently prudent to do this and most Home Gateways an= d
>> mobile routers do this for reasons described in =A0rfc5625
>
>
> Ack. Then say SHOULD for IPv4 DNS queries (since things really don'= ;t work without it) and MAY for IPv6.
>
> SHOULD is quite a strong statement. If you put in a SHOULD for proxyin= g IPv6 DNS requests, then you're saying that "there may exist vali= d reasons in particular circumstances to NOT proxy IPv6 DNS requests, but t= he full=A0implications should be understood and carefully weighed=A0before= =A0choosing a different course."
>
> I don't see the harm if you don't proxy IPv6 DNS lookups. Sayi= ng "most current implementations seem to do this by default" is n= ot sufficient to say SHOULD IMO. So you're needlessly restricting imple= mentation.

Ok. Will make this change.

CB

--e89a8ff2495d0a4ad304c008aba2-- From dwing@cisco.com Mon May 14 19:20:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC5F21F8926 for ; Mon, 14 May 2012 19:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.114 X-Spam-Level: X-Spam-Status: No, score=-110.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPHDLbwni762 for ; Mon, 14 May 2012 19:20:22 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55121F889F for ; Mon, 14 May 2012 19:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2773; q=dns/txt; s=iport; t=1337048421; x=1338258021; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=pSuquYcb3NmCJpOk5VoPHpOQcN7hZKR+f02bbkbCrCA=; b=J3r/efKD9HqDhcYpphcs+NfwIkX1ISCb5ejFAghHMUYzf3rqprHMra1g XBA2v4pOGfow8eauGw+gX+MPPUshuR5zcZ397ba/8kURffcBCUtza3PDA SL/taA6O9VCSwx4oJyWVtxxb3uut31Px7Z7HlIRMVf/E9eF2bxnLlahbd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokJACq9sU+rRDoH/2dsb2JhbABEozyPGASBIYEHghUBAQEDAQEBAQUKARcQNBAHAQMCCQ4BAgQBASgHGQ4VCgkIAQEEARILF4dnBAybBaATixJEhTwEiGSFFokUjUaBaYMJ X-IronPort-AV: E=Sophos;i="4.75,590,1330905600"; d="scan'208";a="42226788" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 15 May 2012 02:20:20 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4F2KKtQ006129; Tue, 15 May 2012 02:20:20 GMT From: "Dan Wing" To: "'Cameron Byrne'" , "'IPv6 Ops WG'" References: In-Reply-To: Date: Mon, 14 May 2012 19:20:20 -0700 Message-ID: <178a01cd3241$4718e7d0$d54ab770$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0x5lrYrK+YbSx7TiCKA1oyXTEpWQAWF8tg Content-Language: en-us Subject: Re: [v6ops] CGN vs Native IPv6 latency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 02:20:23 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Cameron Byrne > Sent: Monday, May 14, 2012 8:29 AM > To: IPv6 Ops WG > Subject: [v6ops] CGN vs Native IPv6 latency > > Hi, > > I sometimes hear folks say that CGN adds latency or otherwise makes > the network slower, and this fact will mean that IPv6 will take more > traffic than the slower CGN IPv4 path. > > I do not believe CGN adds any meaningful latency when the CGN path and > IPv6 are ostensibly the same for the internal network (something an > access network provider controls). Sometimes, on the external network > (the internet), the IPv6 peering is less robust and results in longer > paths and therefore higher latency and lower performance for IPv6. > > Here is some data i casually collect from my phone doing speedtest at > ipv6-test.com. Yes, i know these test are flawed in many ways, but > this is just a casual observation. The test was done using the > IPv6-only connection across an HSPA+ mobile network. The IPv6 path is > native end to end. The "IPv4 path" is IPv6 from the Samsung handset > to a NAT64 (CGN) and then IPv4 to the test server. This is just a > casual test using production and easily available elements. > > IPv4 / IPv6 speeds Mbit/s > > 10.2 /9.07 > http://img2.ipv6- > test.com/speedtest/result/2012/05/14/0b6984f7f589c0fdd10bce5bdaf7b80f.p > ng > > 11.8/10.8 > http://img2.ipv6- > test.com/speedtest/result/2012/05/14/898322b8348a47dfe31d944bf3d8b154.p > ng > > 11.8/12.0 > http://img2.ipv6- > test.com/speedtest/result/2012/05/14/ae2cb534d9d5e74020191d072f127456.p > ng > > As you can see, no noticeable difference in this casual observation. > I am sure someone with time and precision gear can show that CGN addes > ~1ms of latency, but that is hardly impactful on today's internet > > Does anyone have data showing CGN harms network performance from a > speed perspective? For a NAT64, http://www.lightreading.com/document.asp?doc_id=216955 says average bi-directional latency is about 800 microseconds (0.8 milliseconds), which includes all 7 devices in their test bed (not solely the NAT64). Worst case was about 108 milliseconds (bi-directional), also including all 7 devices in their test bed. To my knowledge, that's the best test that has been published. > Perhaps in such a way that it may impact a happy > eyeballs implementations that may do a "straight race" such as > Apple's? Send synthetic traffic through the IPv4 path, so it stays busy and slows down? :-) -d > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Mon May 14 23:24:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F7211E8089 for ; Mon, 14 May 2012 23:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.592 X-Spam-Level: X-Spam-Status: No, score=-101.592 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm19SkY2pVsy for ; Mon, 14 May 2012 23:24:41 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40711E8074 for ; Mon, 14 May 2012 23:24:41 -0700 (PDT) Received: by werf13 with SMTP id f13so3735823wer.31 for ; Mon, 14 May 2012 23:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cGpnOwHVdr0U93Y9OeDbvNkbW954+KZy7dAFGyL/xb0=; b=nQk2fJmj59thek98/mcg0+lP4gPDD6S+pc1rBpod4M3FKgfPGDj0QVlHokNggu/FJd MhkccgUlfG/TqhQUJXXeS7C1Ihp20CHCLHIHpuZzvrrzOU3krrsR1YLPqy6pInlGVdaV YZROxRTJ0PEkHWE/A2YD/LY+rDAlYx1CqdZr9xWGhSV4qkY2RjvjHkPJ5mEMU7QY+EGq +7GSIKRDrQyaoWc+LQxR5j6MZmyv2A/KScp+Zl8TyhlW9478qKlPhQrzrCyeU6CBmGMO LNvKRt1uvG0y7AjHjf8WezpPA9Q7KsE6SmYRvj6RkHuwRtU4oDBdMfQC5CRGJCIsI/1q s5cg== Received: by 10.216.27.199 with SMTP id e49mr6932939wea.45.1337063080300; Mon, 14 May 2012 23:24:40 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-67.as13285.net. [2.102.216.67]) by mx.google.com with ESMTPS id bn9sm40372521wib.5.2012.05.14.23.24.38 (version=SSLv3 cipher=OTHER); Mon, 14 May 2012 23:24:39 -0700 (PDT) Message-ID: <4FB1F6A3.6060903@gmail.com> Date: Tue, 15 May 2012 07:24:35 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> <20120514090036.GK84425@Space.Net> <20120514234305.F187720A2571@drugs.dv.isc.org> <20120515002502.A583420A2A17@drugs.dv.isc.org> In-Reply-To: <20120515002502.A583420A2A17@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops WG , Daniel Roesen Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 06:24:42 -0000 On 2012-05-15 01:25, Mark Andrews wrote: > In message , Randy Bush writes: >>> For the few other case I've had in the last 8 years most have been >>> fixed within a day or so. >> no prob for grandma to do the same, eh? > > Grandma will complain to the ISP "I can't reach ...." and if the > ISP is deploying 6rd / DS-lite and, if they are compentent, they > will be testing using 6rd / DS-lite. The ISP knows if they are > deploying 6rd / DS-lite so it is not unreasonable to expect them > to be testing with these technologies in place. Even if Grandma calls her help desk and cites several RFCs, most ISPs of my acquaintance will fail to understand the nature of the problem and will brush her off (that's if they're past the stage of advising to disable 1Pv6). It seems to me that's what is needed is a set of operationally clueful people running a set of testing boxes looking for these cases, followed by a name and shame process to get them fixed. Meanwhile, Grandma will be grateful for any tunnel endpoint that fakes the MSS if necessary. Make it a MAY please. > The myth that you can drop all ICMP/ICMPv6 packets and have a working > network needs to be broken. The myth that you need to drop ICMP > or ICMPv6 needs to be broken. Er, so what's your master plan for achieving this? Brian From bzeeb-lists@lists.zabbadoz.net Mon May 14 23:27:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D9411E8093 for ; Mon, 14 May 2012 23:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iae67B-qK2V for ; Mon, 14 May 2012 23:27:09 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id C194111E808E for ; Mon, 14 May 2012 23:27:09 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7F57725D3870; Tue, 15 May 2012 06:27:08 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 82E0CBE6FAD; Tue, 15 May 2012 06:27:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id HnlOJmdQcBwH; Tue, 15 May 2012 06:27:06 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E999ABE6FAC; Tue, 15 May 2012 06:27:05 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4FAD61B4.2000301@si6networks.com> Date: Tue, 15 May 2012 06:27:04 +0000 Content-Transfer-Encoding: 7bit Message-Id: <6E9CE2FC-9591-4DA6-93E5-7717CC6181BB@lists.zabbadoz.net> References: <20120511183001.26924.33901.idtracker@ietfa.amsl.com> <4FAD61B4.2000301@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-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, 15 May 2012 06:27:10 -0000 On 11. May 2012, at 19:00 , Fernando Gont wrote: Hi Fernando, > COuld youuuble-check/confirm that this version addresses the issues you > raised during the WGLC? I had done previously and just double checked. I am fine with the current version. I am expecting this to help a lot. Thanks a lot for the update! Regards, Bjoern -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From despres.remi@laposte.net Tue May 15 00:36:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866AA21F88D9 for ; Tue, 15 May 2012 00:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnjpK5S3lGT4 for ; Tue, 15 May 2012 00:36:20 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id C3E7021F8892 for ; Tue, 15 May 2012 00:36:19 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id 06E997000119; Tue, 15 May 2012 09:36:18 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id A9B1970000B9; Tue, 15 May 2012 09:36:14 +0200 (CEST) X-SFR-UUID: 20120515073614695.A9B1970000B9@msfrf2219.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FB17649.6070404@globis.net> Date: Tue, 15 May 2012 09:36:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <064AFE4D-77DA-4DE2-95EE-2D5A551B452F@laposte.net> References: <4FB10D4B.60009@globis.net> <4FB16831.4020200@globis.net> <4FB17649.6070404@globis.net> To: Masataka Mawatari , Masanobu Kawashima , Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , v6ops WG , draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 07:36:30 -0000 Masataka-san, Masanobu-san, Cameron, 1. Could you please clarify your intention? Privately, you justified your lack of interest for improvements I = proposed by your wish to publish the draft as is, planing for this to = have it back to *informational* rather than BCP. If this is the case, can you please confirm here? If not, I guess I should send to the WG detailed amendments proposed to = you for the BCP to be acceptable AFAIAC. 2. 2012-05-14 23:16, Ray Hunter: >> Rajiv Asati (rajiva) >> 14 May 2012 22:58 >> Ray, >>=20 >>> How would an IPv4 only host be able to resolve the to-be-translated = IPv4 >>> address for a connection to an IPv6 only server that only had a AAAA >>> record, and no native A record? >>=20 >> I don't think that this use-case is covered by 464XLAT, but Is the >> v6-only server realistic yet? >>=20 >> Cheers, >> Rajiv >>=20 > Don't know. >=20 > I was just triggered by the following sentence in the 464XLAT ID, = which is why I asked the question: >=20 > /It is also possible to provide single IPv4/IPv6 translation service, = which will be needed in the future case of IPv6-only servers and peers = to be reached from legacy IPv4-only hosts./ As already said, this sentence becomes understandable if it is noted = that 464XLAT can be combined with RFC 6535. (RFC 6535 is the standard track specification for connectivity from = IPv4-only applications to IPv6-only servers). Without this, the sentence should IMHO be deleted. Regards, RD =20 >=20 > regards, > RayH > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Tue May 15 00:40:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A275E21F8701 for ; Tue, 15 May 2012 00:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvcnLdbvBChh for ; Tue, 15 May 2012 00:40:55 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE1221F849A for ; Tue, 15 May 2012 00:40:55 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id 6E3C0700010B; Tue, 15 May 2012 09:40:54 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id 0B20B7000109; Tue, 15 May 2012 09:40:53 +0200 (CEST) X-SFR-UUID: 20120515074054457.0B20B7000109@msfrf2219.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120515002502.A583420A2A17@drugs.dv.isc.org> Date: Tue, 15 May 2012 09:40:53 +0200 Content-Transfer-Encoding: 7bit Message-Id: <1DD792B5-A602-4D88-AC9B-51141F868DA9@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> <20120514090036.GK84425@Space.Net> <20120514234305.F187720A2571@drugs.dv.isc.org> <20120515002502.A583420A2A17@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Daniel Roesen Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 07:40:55 -0000 2012-05-15 02:25, Mark Andrews: > > In message , Randy Bush writes: >>> For the few other case I've had in the last 8 years most have been >>> fixed within a day or so. >> >> no prob for grandma to do the same, eh? > > Grandma will complain to the ISP "I can't reach ...." Isn't it preferable to relieve grandma from having to do this? RD From despres.remi@laposte.net Tue May 15 00:53:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A0421F88E8 for ; Tue, 15 May 2012 00:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9fvgI2cBzMY for ; Tue, 15 May 2012 00:53:45 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7D521F878E for ; Tue, 15 May 2012 00:53:45 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id 75D307000116; Tue, 15 May 2012 09:53:44 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id 41F4D7000060; Tue, 15 May 2012 09:53:44 +0200 (CEST) X-SFR-UUID: 20120515075344270.41F4D7000060@msfrf2219.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120514234305.F187720A2571@drugs.dv.isc.org> Date: Tue, 15 May 2012 09:53:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <20120514070921.GA6906@srv03.cluenet.de> <20120514090036.GK84425@Space.Net> <20120514234305.F187720A2571@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Daniel Roesen Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 07:53:45 -0000 2012-05-15 01:43, Mark Andrews: ... >> It remains that MSS rewrite is a simple and effective way to avoid, = for TCP=3D >> , consequences of wrong supports of PMTU-PTB. >> As such it is a nice-to-have feature. >=20 > While that helps TCP, it doesn't help UDP based protocols and if > anything makes it harder for UDP as TCP "works" so I don't need to > open up my filters to let in ICMPv6 PTB. =20 Different view. Avoiding to fix TCP because it doesn't help UDP amounts to consciously = delay solution of a real problem. Note that if MSS rewrite is a MAY, it can be turned off when ICMP PTB = becomes known to be handled properly. > I don't need to properly > direct ICMPv6 PTB in the load balancer, etc. If this to say that treating ICMPv6 PTB properly isn't a simple matter, = it is AFAIK one more reason to document asap the solution for TCP/IPv6, = and explicitly authorize to use. Regards, RD From nick@inex.ie Tue May 15 03:38:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2C521F8717 for ; Tue, 15 May 2012 03:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNs03nJbyBBh for ; Tue, 15 May 2012 03:38:12 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id B75A121F8622 for ; Tue, 15 May 2012 03:38:10 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q4FAbPaS044133 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 May 2012 11:37:26 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FB23208.7000304@inex.ie> Date: Tue, 15 May 2012 11:38:00 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dan Wing References: <009101cd31ec$21d6a390$6583eab0$@asgard.org> <171501cd322d$a013c620$e03b5260$@com> <173a01cd3233$ea8ea430$bfabec90$@com> In-Reply-To: <173a01cd3233$ea8ea430$bfabec90$@com> X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] Happy Eyeballs and preferring IPv6 [was RE: CGN vs Native IPv6 latency] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 10:38:12 -0000 On 15/05/2012 01:44, Dan Wing wrote: > It can help, but if all the subscribers visit the same popular > IPv4 address, port overloading can fail to provide service -- its > law of large numbers collapses. I would be particularly concerned in this situation about CDNs (e.g. akamai, limelight and all those guys) and other anycast addresses like as112. Nick From despres.remi@laposte.net Tue May 15 05:31:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E55E21F8974 for ; Tue, 15 May 2012 05:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK9ome5tw2L0 for ; Tue, 15 May 2012 05:31:04 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 51FA821F8968 for ; Tue, 15 May 2012 05:31:02 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3C1F09400E6; Tue, 15 May 2012 14:30:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <10e101cd3002$4917d960$db478c20$@com> Date: Tue, 15 May 2012 14:30:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <10e101cd3002$4917d960$db478c20$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: 'IPv6 Operations' Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 12:31:05 -0000 2012-05-12 07:44, Dan Wing: >> -----Original Message----- >> From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >> Sent: Friday, May 11, 2012 8:31 PM ... >> The CPE router MUST support adjusting the MSS value of the TCP SYN >> packets. >=20 > In which direction (inbound, outbound, or both)? What value should > operators adjust the MSS to? Should the MSS be adjusted by default, > or should it not be adjustment by default? Is MSS adjustment best > done by the CPE, or best done by the DS-Lite AFTR or 6rd BR? The most general and simplest answer is AFAIK the following: In any node, before entering of just after leaving a link whose MTU is = the same in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS = advertised in a received TCP SYN packet exceeds the link MTU minus the = TCP/IP header length (40 octets in IPv4, 60 in IPv6), reduce it to this = value, and adjust IP and TCP checksums accordingly. Where this can be done without excessive processing burden, this = mitigates the risk of problem related to fragmentation when packets = enter or exit this link, and cannot be harmful. This behavior can be abandoned if and when PMTUD and ICMP-PTB forwarding = are known to be generalized. =20 An ISP provides all border nodes of a domain (e.g. CPEs and AFTRs of = some kind), it may select to do it only in the domain entry direction, = or domain exit direction. Regards, RD =20 From shemant@cisco.com Tue May 15 08:07:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50E321F8973 for ; Tue, 15 May 2012 08:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdr78YwP+unw for ; Tue, 15 May 2012 08:07:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 33CDE21F8966 for ; Tue, 15 May 2012 08:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14561; q=dns/txt; s=iport; t=1337094423; x=1338304023; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=ImDo09E3gdGolIRkd3MFL/u7V0k0N0H7mHouq9Oi0vk=; b=JmC8+x9p18t9j3piJvfEZKrTxczjGM8nNgui+BqeExcyJSlC8AW6DWNm bG/zlFvp5wnPhPt9v9tHrx5gtuuf6+RUbkprCkHrurrYkeMXgLLCzhklw OXciEEf7NHdvA5QjwL4iSg7Nrp7iP5hPcrRFj7VKtS/+2BtvCO8+xeHRp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIpwsk+tJXHB/2dsb2JhbABEgkaxM4EHghUBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCAwOh2yaeqAZixyFHWMEiGSbcIFpgwc X-IronPort-AV: E=Sophos;i="4.75,595,1330905600"; d="scan'208,217";a="83200408" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 15 May 2012 15:07:02 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q4FF6t4N029273 for ; Tue, 15 May 2012 15:07:02 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 May 2012 10:06:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD32AC.5E7B8EDE" Date: Tue, 15 May 2012 10:06:55 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0x5Br2+j9mNxDaQuuqarxLphgLSAAxrk/Q References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "IPv6 Operations" X-OriginalArrivalTime: 15 May 2012 15:06:56.0905 (UTC) FILETIME=[5EC07F90:01CD32AC] Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 15:07:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD32AC.5E7B8EDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Changed the TCP MSS Adjust from a MUST to a MAY. In case one asks "why have a MAY requirement at all?" The issue makes sense to capture in rfc6204bis so that the community is aware of potential problems and especially since RFC 4459 does not discuss the TCP MSS Adjust. Changed text is included below. Latest by tomorrow, the -09 for rfc6204bis is planned to be released.=20 =20 OLD =20 4.4. Transition Technologies Support =20 4.4.1. 6rd =20 =20 NEW =20 4.4. Transition Technologies Support =20 Transition technology support requirements: =20 TTS-1: The CPE router MAY support a TCP MSS Adjust feature on packets traversing the CPE router. =20 4.4.1. 6rd =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Monday, May 14, 2012 11:13 AM To: IPv6 Operations Subject: [v6ops] proposed TCP MSS text for rfc6204bis =20 [The CPE router MUST support a TCP MSS Adjust feature on packets traversing the CPE router. By default, the TCP MSS Adjust feature is turned off. ]=20 =20 Some thoughts below on why the above text. =20 The TCP MSS Adjust is not needed for TCP packets sourced or destined to the CPE because the number of such packets at the CPE will be very small. Additionally, we (Wes and I) deliberately left out qualifying the feature for IPv4 or IPv6 because the feature should be supported for both since the CPE also supports 6rd. We have left out specifying any default value for the MSS because there are several values since the MSS is a function of the protocols being used. Note IPv4 CPE routers already support a TCP MSS Adjust knob. Further, the DS-Lite AFTR and the 6rd BR in the SP domain sit between the home TCP client and a TCP server on the Internet. Thus the AFTR and the BR can perform TCP MSS Adjust. It's only for 6rd where the CPE's talk without going through the BR, the CPE has to invoke the TCP MSS Adjust. =20 =20 The problems that the above text alleviates are: =20 (a) Any of native IPv6 and tunneled technologies such as DS-Lite and 6rd can cause ICMPv6 errors for packet too big to the source. Even when the CPE issues the ICMPv6 error to the host connected to the CPE, the Internet access of the host is delayed which is not good. Additionally, what if the CPE passes the host packet to the Internet and one router on the Internet issues the ICMPv6 error with packet too big but a node in the path back blocks the ICMPv6 error. Now the Internet connectivity is really delayed for the host. This summarizes that we do have problems to fix. (b) DS-Lite is an additional problem. Since DS-Lite mandates that the CPE and the AFTR perform fragmentation and reassembly, we have a nasty problem. Reassembly of tunneled encapsulated packets is very complex because the receiver of the fragmented packet has to reassemble before decapsulation. Thus the received needs more memory and a general purpose cpu. If I want to choke a DS-Lite deployment at the AFTR and the CPE, I will generate packets close to 1500 bytes and force tunnel fragmentation. Thus the DS-Lite problem is an attack vector that Daniel Rosen pointed out too. =20 Further, PMTUD is not practical to deploy so the TCP MSS Adjust is still a usable choice. =20 =20 Thanks, =20 Hemant =20 =20 =20 =20 =20 ------_=_NextPart_001_01CD32AC.5E7B8EDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Changed the TCP MSS Adjust from a MUST to a = MAY.   In case one asks “why have a MAY requirement at = all?”  The issue makes sense to capture in rfc6204bis so that = the community is aware of potential problems and especially since RFC = 4459 does not discuss the TCP MSS Adjust.  Changed text is included = below.  Latest by tomorrow, the -09 for rfc6204bis is planned to be = released.

 

OLD

 

4.4.  Transition Technologies Support

 

4.4.1.  = 6rd

 

 

NEW

 

4.4.  =
Transition Technologies =
Support
 
   =
Transition technology support =
requirements:
 
 &nbs=
p; TTS-1:  The CPE router MAY support a TCP MSS Adjust feature =
on
        &=
nbsp;  packets traversing the CPE =
router.
 
4.4.1.  =
6rd

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Hemant Singh (shemant)
Sent: Monday, May 14, 2012 11:13 = AM
To: IPv6 Operations
Subject: [v6ops] proposed TCP = MSS text for rfc6204bis

 

[The CPE = router MUST support a TCP MSS Adjust feature on packets traversing the = CPE router.  By default, the TCP MSS Adjust feature is turned off. = ]

 

Some thoughts below on why the above = text.

 

The TCP MSS Adjust is not needed for TCP packets = sourced or destined to the CPE because the number of such packets at the = CPE will be very small.  Additionally, we (Wes and I) deliberately = left out qualifying the feature for IPv4 or IPv6 because the feature = should be supported for both since the CPE also supports = 6rd.   We have left out specifying any default value for the = MSS because there are several values since the MSS is a function of the = protocols being used.   Note IPv4 CPE routers already support = a TCP MSS Adjust knob.    Further, the DS-Lite AFTR and = the 6rd BR in the SP domain sit between the home TCP client and a TCP = server on the Internet.  Thus the AFTR and the BR can perform TCP = MSS Adjust.  It’s only for 6rd  where the CPE’s = talk without going through the BR, the CPE has to invoke the TCP MSS = Adjust. 

 

The problems = that the above text alleviates are:

 

(a)    = Any of native IPv6  and tunneled = technologies such as DS-Lite and 6rd can cause ICMPv6 errors for packet = too big to the source.   Even when the CPE issues the ICMPv6 = error to the host connected to the CPE, the Internet access of the host = is delayed which is not good.   Additionally, what if the CPE = passes the host packet to the Internet and one router on the Internet = issues the ICMPv6 error with packet too big but a node in the path back = blocks the ICMPv6 error.   Now the Internet connectivity is = really delayed for the host.   This summarizes that we do have = problems to fix.

(b)    = DS-Lite is an additional problem.   = Since DS-Lite mandates that the CPE and the AFTR perform fragmentation = and reassembly, we have a nasty problem.   Reassembly of = tunneled encapsulated packets is very complex because the receiver of = the fragmented packet has to reassemble before = decapsulation.   Thus the received needs more memory and a = general purpose cpu.  If I want to choke a DS-Lite deployment at = the AFTR and the CPE, I will generate packets close to 1500 bytes and = force tunnel fragmentation.   Thus the DS-Lite problem is an = attack vector that Daniel Rosen pointed out too.

 

Further, = PMTUD is not practical to deploy so the TCP MSS Adjust is still a usable = choice.    

 

Thanks,

 

Hemant =  

 

 

 

 

------_=_NextPart_001_01CD32AC.5E7B8EDE-- From ichiroumakino@gmail.com Tue May 15 08:12:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CEC21F8776 for ; Tue, 15 May 2012 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.106 X-Spam-Level: X-Spam-Status: No, score=-3.106 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfJNNgkkjISj for ; Tue, 15 May 2012 08:12:14 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B321021F84D9 for ; Tue, 15 May 2012 08:12:13 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so2507604wib.13 for ; Tue, 15 May 2012 08:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3W/2XXbf5r1fXxv25rnatPiwwTnYZIkBuDL7j5NLjdE=; b=Y3CK7daK3GTcJ/DvyvwAc+BJiYBRUHm7SA+iGDj5SgQd9nU/ESHacDzLWfpAYjASM+ qDmPCbWMNCZgPsxHO+TF+8DY3SyGniwDbdI+97WjDF8NoxSAOPyQs7nVs8u3BybNdnwn OZFz+E1qJylGR4C9EOPjoIwq3x9w6dMIAsTS/IatzxAidOG71NaQxVUWmMnuAgqvqrtg hA4ehd01pLpf7kj0pinOszzAjdfmaO+Hp9noVu8tZ750aCI2ZBwI6pbYBTrE23XpsKGo oA2vB75jQRKXsO2CfyVSFroF5IJHAcCEqBXQPaGi1omK+5SfvSDl7QSDJnrr5WCxjp6h GNxw== Received: by 10.180.104.231 with SMTP id gh7mr9232348wib.10.1337094732843; Tue, 15 May 2012 08:12:12 -0700 (PDT) Received: from dhcp-10-61-99-111.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id eb8sm6918132wib.11.2012.05.15.08.12.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 08:12:12 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> Date: Tue, 15 May 2012 17:12:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 15:12:14 -0000 > Changed the TCP MSS Adjust from a MUST to a MAY. In case one asks = =93why have a MAY requirement at all?=94 The issue makes sense to = capture in rfc6204bis so that the community is aware of potential = problems and especially since RFC 4459 does not discuss the TCP MSS = Adjust. Changed text is included below. Latest by tomorrow, the -09 = for rfc6204bis is planned to be released. > =20 > OLD > =20 > 4.4. Transition Technologies Support > =20 > 4.4.1. 6rd > =20 > =20 > NEW > =20 > 4.4. Transition Technologies Support > =20 > Transition technology support requirements: > =20 > TTS-1: The CPE router MAY support a TCP MSS Adjust feature on > packets traversing the CPE router. > =20 > 4.4.1. 6rd I object to any TCP MSS text in the document. cheers, Ole= From brian.e.carpenter@gmail.com Tue May 15 08:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D11E21F8969 for ; Tue, 15 May 2012 08:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.143 X-Spam-Level: X-Spam-Status: No, score=-101.143 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8RXBL1jE2BW for ; Tue, 15 May 2012 08:55:01 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E71921F8999 for ; Tue, 15 May 2012 08:55:01 -0700 (PDT) Received: by eekd4 with SMTP id d4so2153436eek.31 for ; Tue, 15 May 2012 08:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1eIBp3cSMnYKsh80eTmZ+152DgH7PpmP5znjsHKgYvM=; b=gp77/lLOsNdfQg+ur2annXpjnW8yY9Jy7MY0je9Y5zVva/Mh/RCyEuLBnGiBE7TFw9 2A7Kvk4Eg1XOBMrkWTUUlaGfMNCziuM6FYHyLo07RVWoptdgS/McNytYLy8u4iFWzaNV SC2VrWK7K8d3VuViQfF/CHBglXU57HH0d0cmE59HLmT4wysgy9oYkOSL7gmpfjAfNEre 2ywjO7BdAmjSxl2va1hKDmiTihKjMhJVkOBOAGnJwlQkqsIxq7cT6Tp8HorcqnaofbMp qSmZG1czHIJErQXjQm5bF/HXkZTNjnW2D+RhdG9wyncIXjI9Awbs2JppklGmofPHSZ/I dlgQ== Received: by 10.14.53.70 with SMTP id f46mr617182eec.62.1337097300562; Tue, 15 May 2012 08:55:00 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-67.as13285.net. [2.102.216.67]) by mx.google.com with ESMTPS id y54sm108622600eef.10.2012.05.15.08.54.57 (version=SSLv3 cipher=OTHER); Tue, 15 May 2012 08:54:59 -0700 (PDT) Message-ID: <4FB27C4E.5010006@gmail.com> Date: Tue, 15 May 2012 16:54:54 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <10e101cd3002$4917d960$db478c20$@com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Operations' Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 15:55:02 -0000 On 2012-05-15 13:30, R=C3=A9mi Despr=C3=A9s wrote: > 2012-05-12 07:44, Dan Wing: >=20 >>> -----Original Message----- >>> From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >>> Sent: Friday, May 11, 2012 8:31 PM > ... >>> The CPE router MUST support adjusting the MSS value of the TCP SYN >>> packets. >> In which direction (inbound, outbound, or both)? What value should >> operators adjust the MSS to? Should the MSS be adjusted by default, >> or should it not be adjustment by default? Is MSS adjustment best >> done by the CPE, or best done by the DS-Lite AFTR or 6rd BR? >=20 > The most general and simplest answer is AFAIK the following: > In any node, before entering of just after leaving a link whose MTU is = the same in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS adv= ertised in a received TCP SYN packet exceeds the link MTU minus the TCP/I= P header length (40 octets in IPv4, 60 in IPv6), reduce it to this value,= and adjust IP and TCP checksums accordingly. What if there are additional IPv6 extension headers before the TCP header= , in some packets? Brian > Where this can be done without excessive processing burden, this mitiga= tes the risk of problem related to fragmentation when packets enter or ex= it this link, and cannot be harmful. > This behavior can be abandoned if and when PMTUD and ICMP-PTB forwardin= g are known to be generalized. =20 >=20 > An ISP provides all border nodes of a domain (e.g. CPEs and AFTRs of so= me kind), it may select to do it only in the domain entry direction, or d= omain exit direction. >=20 > Regards, > RD =20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From despres.remi@laposte.net Tue May 15 09:19:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FF221F8979 for ; Tue, 15 May 2012 09:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kDjwFOPNgJJ for ; Tue, 15 May 2012 09:19:57 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 04C4E21F8978 for ; Tue, 15 May 2012 09:19:56 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 2DB797000886; Tue, 15 May 2012 18:19:55 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id C781970001B2; Tue, 15 May 2012 18:19:54 +0200 (CEST) X-SFR-UUID: 20120515161954817.C781970001B2@msfrf2211.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FB27C4E.5010006@gmail.com> Date: Tue, 15 May 2012 18:19:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D0B0B30-05A4-4582-B8DD-3F19CD10CDC1@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <10e101cd3002$4917d960$db478c20$@com> <4FB27C4E.5010006@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: 'IPv6 Operations' Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 16:19:58 -0000 Le 2012-05-15 =E0 17:54, Brian E Carpenter a =E9crit : > On 2012-05-15 13:30, R=E9mi Despr=E9s wrote: >> 2012-05-12 07:44, Dan Wing: >>=20 >>>> -----Original Message----- >>>> From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >>>> Sent: Friday, May 11, 2012 8:31 PM >> ... >>>> The CPE router MUST support adjusting the MSS value of the TCP SYN >>>> packets. >>> In which direction (inbound, outbound, or both)? What value should >>> operators adjust the MSS to? Should the MSS be adjusted by default, >>> or should it not be adjustment by default? Is MSS adjustment best >>> done by the CPE, or best done by the DS-Lite AFTR or 6rd BR? >>=20 >> The most general and simplest answer is AFAIK the following: >> In any node, before entering of just after leaving a link whose MTU = is the same in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS = advertised in a received TCP SYN packet exceeds the link MTU minus the = TCP/IP header length (40 octets in IPv4, 60 in IPv6), reduce it to this = value, and adjust IP and TCP checksums accordingly. >=20 > What if there are additional IPv6 extension headers before the TCP = header, > in some packets? Good theoretical question! - In SYN packets, I would say implementations MAY treat them or ignore = them, since it is an overall MAY anyway. - If some subsequent data packets have extension headers plus full = MSS's, they may be rejected due to PTB (or fragmented if they would be = with DF=3D0), thus defeating the purpose of MSS rewrite. However, the fragmentation extension, which is unavoidable for large UDP = datagrams, isn't AFAIK applicable to TCP. If an IPv6 stack would add extensions of maximum length L to = non-fragmented IPv6 packets, it could I suppose reduce its transmit MSS = by L. But is this a case of the real IPv6 world? RD >=20 > Brian >=20 >> Where this can be done without excessive processing burden, this = mitigates the risk of problem related to fragmentation when packets = enter or exit this link, and cannot be harmful. >> This behavior can be abandoned if and when PMTUD and ICMP-PTB = forwarding are known to be generalized. =20 >>=20 >> An ISP provides all border nodes of a domain (e.g. CPEs and AFTRs of = some kind), it may select to do it only in the domain entry direction, = or domain exit direction. >>=20 >> Regards, >> RD =20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 From ichiroumakino@gmail.com Tue May 15 09:33:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F8A21F899E for ; Tue, 15 May 2012 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXUCW6FqZBnh for ; Tue, 15 May 2012 09:33:47 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3BD021F87C8 for ; Tue, 15 May 2012 09:33:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4338232wgb.13 for ; Tue, 15 May 2012 09:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4B/M7iQ2WGnOqP8EJU4MPQaTUP5X1yG0RMgeZZXWBrs=; b=nYuqTUyDQwbjz6gz8EKe6bJJjCOi/pu9VAH47vefPOzgG8B8zIdvhNcBJaxCvTu/6O 9VKX9eT9R137UPLZ9mpSzdKppGbH2Xb9LeZDCer+fkQ6yZCDKLKWjWnX9T2lM+r6EpXr LfnVTraz6LLvFpEZCaSUbrbIUTbYPrT0e13gzIid7CV90f1FMyxdNQ4AFyGWjdfrqaZL vOQDKvxtBo6oF2hCUws3FDM9MtdJUUYPpbqHyi7uKmQslBJxAymE5G8Qd9xF6amjkUGm uL6LfDElY737VWfy+zGN0QCJJKiXnZedjEFFMvH1dBl4wAH98P5mq8SOSenvqwaJXEuy FwmA== Received: by 10.216.137.147 with SMTP id y19mr2588520wei.33.1337099625920; Tue, 15 May 2012 09:33:45 -0700 (PDT) Received: from dhcp-10-61-99-111.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gd4sm68047405wib.6.2012.05.15.09.33.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 09:33:45 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> Date: Tue, 15 May 2012 18:33:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 16:33:48 -0000 >> NEW >>=20 >> 4.4. Transition Technologies Support >>=20 >> Transition technology support requirements: >>=20 >> TTS-1: The CPE router MAY support a TCP MSS Adjust feature on >> packets traversing the CPE router. >>=20 >> 4.4.1. 6rd >=20 > I object to any TCP MSS text in the document. I got poked to give a reason for this opinion: top of my head: - don't want an IPv6 router to have to do this forever - don't want to require all routers to look into transport layer = information. (aka layer violation) - we never specified this for IPv4 - is TCP MSS rewrite specified anywhere to reference? or are we now = going to specify that in an v6ops document? - this isn't specific to transition mechanisms and isn't such an issue given that the MTU for 6rd, DS-lite are = required to be "well managed" - doesn't solve the problem. only works for TCP. only handles the case of a WAN-side MTU being = lower than LAN side MTU use RFC481 for TCP - should be reviewed by the transport area cheers, Ole= From marc.blanchet@viagenie.ca Tue May 15 09:46:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0990B21F87D2 for ; Tue, 15 May 2012 09:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX5ZryAGIWVg for ; Tue, 15 May 2012 09:46:06 -0700 (PDT) Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8615F21F87CD for ; Tue, 15 May 2012 09:46:06 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by blues.viagenie.ca (Postfix) with ESMTPSA id 9D3911C284 for ; Tue, 15 May 2012 12:46:04 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Marc Blanchet In-Reply-To: Date: Tue, 15 May 2012 12:46:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> To: IPv6 Operations X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 16:46:07 -0000 Le 2012-05-15 =E0 12:33, Ole Tr=F8an a =E9crit : >>> NEW >>>=20 >>> 4.4. Transition Technologies Support >>>=20 >>> Transition technology support requirements: >>>=20 >>> TTS-1: The CPE router MAY support a TCP MSS Adjust feature on >>> packets traversing the CPE router. >>>=20 >>> 4.4.1. 6rd >>=20 >> I object to any TCP MSS text in the document. >=20 > I got poked to give a reason for this opinion: >=20 > top of my head: > - don't want an IPv6 router to have to do this forever > - don't want to require all routers to look into transport layer = information. > (aka layer violation) > - we never specified this for IPv4 > - is TCP MSS rewrite specified anywhere to reference? or are we now = going to specify that in an v6ops > document? I agree with Ole that MSS rewrite is not specific to this document and = requires additional detailed specification on how it is done.=20 So I'm also opposed in adding this requirement as it is now (i.e. = underspecified and not discussing all the consequences). So either=20 a) we identify a document that clearly describes how to do MSS rewrite, = the pros and cons, the applicability, etc=85 and then we refer to that = document. Does such document exist? b) we do not specify MSS rewrite here. Regards, Marc. > - this isn't specific to transition mechanisms > and isn't such an issue given that the MTU for 6rd, DS-lite are = required to be "well managed" > - doesn't solve the problem. > only works for TCP. only handles the case of a WAN-side MTU being = lower than LAN side MTU > use RFC481 for TCP > - should be reviewed by the transport area >=20 > cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue May 15 09:53:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C8321F8834 for ; Tue, 15 May 2012 09:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJBGOnwloGoB for ; Tue, 15 May 2012 09:53:14 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 11C2C21F8810 for ; Tue, 15 May 2012 09:53:14 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4FGrDfe002564 for ; Tue, 15 May 2012 09:53:13 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4FGrCHk002546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2012 09:53:13 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4FGrCk9023686; Tue, 15 May 2012 09:53:12 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4FGrCZX023676 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 15 May 2012 09:53:12 -0700 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; Tue, 15 May 2012 09:53:12 -0700 From: "Templin, Fred L" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Hemant Singh Date: Tue, 15 May 2012 09:53:11 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0yuIk/ydG7DqzrQbOYyoPlRAwKQAAAUHDQ Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> 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 Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 16:53:15 -0000 If the concern is for MTU mitigations for tunneling protocols that use IPv4 as the outer layer of encapsulation, SEAL has a solution for this: https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ The idea is that the tunneling protocol has an adjunct UDP messaging protocol whereby the tunnel egress informs the ingress in case any IPv4 fragmentation occurs on the path. The MTU feedback is delivered in the form of a "Packet Too Big" message that the ingress can then turn around and return to the original source. So, I agree with Ole - no need to have MSS adjustments if we can make path MTU discovery more robust. Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Ole Tr=F8an > Sent: Tuesday, May 15, 2012 9:34 AM > To: Hemant Singh > Cc: IPv6 Operations > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > >> NEW > >> > >> 4.4. Transition Technologies Support > >> > >> Transition technology support requirements: > >> > >> TTS-1: The CPE router MAY support a TCP MSS Adjust feature on > >> packets traversing the CPE router. > >> > >> 4.4.1. 6rd > > > > I object to any TCP MSS text in the document. >=20 > I got poked to give a reason for this opinion: >=20 > top of my head: > - don't want an IPv6 router to have to do this forever > - don't want to require all routers to look into transport layer > information. > (aka layer violation) > - we never specified this for IPv4 > - is TCP MSS rewrite specified anywhere to reference? or are we now going > to specify that in an v6ops > document? > - this isn't specific to transition mechanisms > and isn't such an issue given that the MTU for 6rd, DS-lite are require= d > to be "well managed" > - doesn't solve the problem. > only works for TCP. only handles the case of a WAN-side MTU being lower > than LAN side MTU > use RFC481 for TCP > - should be reviewed by the transport area >=20 > cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Tue May 15 09:56:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E1421F8939 for ; Tue, 15 May 2012 09:56:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F0nV6MhR39V for ; Tue, 15 May 2012 09:56:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47FCE21F8915 for ; Tue, 15 May 2012 09:56:41 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8014875pbc.31 for ; Tue, 15 May 2012 09:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HRK2wtUuq/66d8eGZdMwicB2e7jA2vIcReS8oQAjDJ4=; b=tF5A2s2TJlyAtYMjbmxxxma4SIgR8amZb/cdderHrPnPsvKtREsepMyZ7D/+frLiSN LBqXjOod0IewO0YZ+DbZyjRYgGVvgQbbjl5hEvEqgURDzY0MkEmaJmc2ZeC7A0Un9UyQ bjqQl52/YrKIEpfO1V1OoPmb3q1IB1z43N99phTbrx6euJUTHaYw8SXyXXXgqstNMaej 80lzS5uz1y0MuhGZPPuBXD/lBVdsdpdMo3E55GoVij5/LA8jPZFmUbLqHPOVRwfdWiTm AgVWHOjSy1l3o0zM2JiRL74m+lc0SBCsiBKGUCOsWNM/ePsj7cULKlk2qlPf/Z+UfAMk jBZw== MIME-Version: 1.0 Received: by 10.68.195.168 with SMTP id if8mr389638pbc.164.1337101000503; Tue, 15 May 2012 09:56:40 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Tue, 15 May 2012 09:56:40 -0700 (PDT) In-Reply-To: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> Date: Tue, 15 May 2012 09:56:40 -0700 Message-ID: From: Cameron Byrne To: Marc Blanchet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 16:56:41 -0000 On Tue, May 15, 2012 at 9:46 AM, Marc Blanchet wrote: > > Le 2012-05-15 =E0 12:33, Ole Tr=F8an a =E9crit : > >>>> NEW >>>> >>>> 4.4. =A0Transition Technologies Support >>>> >>>> =A0Transition technology support requirements: >>>> >>>> =A0TTS-1: =A0The CPE router MAY support a TCP MSS Adjust feature on >>>> =A0 =A0 =A0 =A0 =A0packets traversing the CPE router. >>>> >>>> 4.4.1. =A06rd >>> >>> I object to any TCP MSS text in the document. >> I object to your objection ! >> I got poked to give a reason for this opinion: >> >> top of my head: >> - don't want an IPv6 router to have to do this forever >> - don't want to require all routers to look into transport layer informa= tion. >> =A0(aka layer violation) >> - we never specified this for IPv4 >> - is TCP MSS rewrite specified anywhere to reference? or are we now goin= g to specify that in an v6ops >> =A0document? > > I agree with Ole that MSS rewrite is not specific to this document and re= quires additional detailed specification on how it is done. > So I'm also opposed in adding this requirement as it is now (i.e. undersp= ecified and not discussing all the consequences). > > So either > a) we identify a document that clearly describes how to do MSS rewrite, t= he pros and cons, the applicability, etc=85 and then we refer to that docum= ent. Does such document exist? > b) we do not specify MSS rewrite here. > c). 6204bis CE MAY implement a compensating mechanism for MTU related service degradation that may occur when tunnels such as 6RD and DS-lite are used. CB > Regards, Marc. > >> - this isn't specific to transition mechanisms >> =A0and isn't such an issue given that the MTU for 6rd, DS-lite are requi= red to be "well managed" >> - doesn't solve the problem. >> =A0only works for TCP. only handles the case of a WAN-side MTU being low= er than LAN side MTU >> =A0use RFC481 for TCP >> - should be reviewed by the transport area >> >> cheers, >> Ole >> _______________________________________________ >> 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 despres.remi@laposte.net Tue May 15 10:05:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A995021F8956 for ; Tue, 15 May 2012 10:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2vrNDY4v2Rf for ; Tue, 15 May 2012 10:05:27 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 19DFC21F893D for ; Tue, 15 May 2012 10:05:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id A948370000D0; Tue, 15 May 2012 19:05:25 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id 2F4E1700009D; Tue, 15 May 2012 19:05:25 +0200 (CEST) X-SFR-UUID: 20120515170525193.2F4E1700009D@msfrf2107.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 15 May 2012 19:05:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06E52FF8-0FFA-47ED-9882-1FA5D85A5279@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 17:05:28 -0000 Le 2012-05-15 =E0 18:56, Cameron Byrne a =E9crit : > On Tue, May 15, 2012 at 9:46 AM, Marc Blanchet > wrote: >>=20 >> Le 2012-05-15 =E0 12:33, Ole Tr=F8an a =E9crit : >>=20 >>>>> NEW >>>>>=20 >>>>> 4.4. Transition Technologies Support >>>>>=20 >>>>> Transition technology support requirements: >>>>>=20 >>>>> TTS-1: The CPE router MAY support a TCP MSS Adjust feature on >>>>> packets traversing the CPE router. >>>>>=20 >>>>> 4.4.1. 6rd >>>>=20 >>>> I object to any TCP MSS text in the document. >>>=20 >=20 > I object to your objection ! >=20 >>> I got poked to give a reason for this opinion: >>>=20 >>> top of my head: >>> - don't want an IPv6 router to have to do this forever >>> - don't want to require all routers to look into transport layer = information. >>> (aka layer violation) >>> - we never specified this for IPv4 >>> - is TCP MSS rewrite specified anywhere to reference? or are we now = going to specify that in an v6ops >>> document? >>=20 >> I agree with Ole that MSS rewrite is not specific to this document = and requires additional detailed specification on how it is done. >> So I'm also opposed in adding this requirement as it is now (i.e. = underspecified and not discussing all the consequences). >>=20 >> So either >> a) we identify a document that clearly describes how to do MSS = rewrite, the pros and cons, the applicability, etc=85 and then we refer = to that document. Does such document exist? >> b) we do not specify MSS rewrite here. >>=20 >=20 > c). 6204bis CE MAY implement a compensating mechanism for MTU related > service degradation that may occur when tunnels such as 6RD and > DS-lite are used ... in particular by some ad hoc MSS reductions in TCP SYN packets = [RFC879] c) is preferred to doing nothing especially if completed as proposed = here. Free, the largest 6rd network, does AFAIK MSS rewrites (copy added to = Alexandre who can confirm or infirm). RD =20 >=20 > CB >=20 >> Regards, Marc. >>=20 >>> - this isn't specific to transition mechanisms >>> and isn't such an issue given that the MTU for 6rd, DS-lite are = required to be "well managed" >>> - doesn't solve the problem. >>> only works for TCP. only handles the case of a WAN-side MTU being = lower than LAN side MTU >>> use RFC481 for TCP >>> - should be reviewed by the transport area >>>=20 >>> cheers, >>> Ole >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From warren@kumari.net Tue May 15 10:29:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F294021F867C for ; Tue, 15 May 2012 10:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.591 X-Spam-Level: X-Spam-Status: No, score=-105.591 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMIBV7JH8LZS for ; Tue, 15 May 2012 10:29:41 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBE821F8678 for ; Tue, 15 May 2012 10:29:41 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4BDFF1B402EB; Tue, 15 May 2012 13:29:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warren Kumari In-Reply-To: Date: Tue, 15 May 2012 13:29:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 17:29:42 -0000 On May 15, 2012, at 12:33 PM, Ole Tr=F8an wrote: >>> NEW >>>=20 >>> 4.4. Transition Technologies Support >>>=20 >>> Transition technology support requirements: >>>=20 >>> TTS-1: The CPE router MAY support a TCP MSS Adjust feature on >>> packets traversing the CPE router. >>>=20 >>> 4.4.1. 6rd >>=20 >> I object to any TCP MSS text in the document. >=20 > I got poked to give a reason for this opinion: >=20 > top of my head: > - don't want an IPv6 router to have to do this forever > - don't want to require all routers to look into transport layer = information. > (aka layer violation) > - we never specified this for IPv4 > - is TCP MSS rewrite specified anywhere to reference? or are we now = going to specify that in an v6ops > document? > - this isn't specific to transition mechanisms > and isn't such an issue given that the MTU for 6rd, DS-lite are = required to be "well managed" > - doesn't solve the problem. > only works for TCP. only handles the case of a WAN-side MTU being = lower than LAN side MTU > use RFC481 for TCP > - should be reviewed by the transport area Having used widgets that did MSS rewriting (to make IPv4 TCP packets fit = down a GRE tunnel, that itself rode on IPSec) I ran into (at least) = these problems: 1: The widget would occasionally rewrite what it though was the MSS = field in *non-SYN* packets. This obviously does not work (and is, er, = fun to debug). 2: The CPU load was much higher with the MSS rewrite feature on. The = widget had hardware that did session state tracking, and the MSS rewrite = function required punting from the fast path to the CPU. In another = widget (actually just a newer version of the same widget) the MSS = rewrite was done in fast path, but lots of SYN packets would overwhelm = the devices ability to rewrite (and at a much lower rate than with = rewriting turned off) -- as with many hardware limits, the fact that you = had bumped into it wasn't exposed anywhere. 3: With a different vendor -- If you happened to try run a (GRE) tunnel = through the device, it would "helpfully" peer into the tunnel and = rewrite the MSS on the tunnels SYN packet, correctly update the TCP = checksum, but then fail to recalculate the GRE checksum. This "feature" = seemed to not be something you could turn off... Yes, all of these are anecdotes, and yes, all of them were stupid = implementation bugs, but MSS rewrite caused much annoyance... W >=20 > cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From jhw@apple.com Tue May 15 10:59:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7EE21F8862 for ; Tue, 15 May 2012 10:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5chRUIIHXGb for ; Tue, 15 May 2012 10:59:41 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4A021F882B for ; Tue, 15 May 2012 10:59:41 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 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 <0M4200MEOSI07ON0@mail-out.apple.com> for v6ops@ietf.org; Tue, 15 May 2012 10:59:40 -0700 (PDT) X-AuditID: 11807136-b7f516d000003f9b-cc-4fb2998ce319 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id AC.4A.16283.C8992BF4; Tue, 15 May 2012 10:59:40 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 15 May 2012 10:59:40 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1461) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42IRPMjroNszc5O/wfa3Rhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvu++ywFu9gqPu39yt7A2M3axcjBISFgIrH0u3UXIyeQKSZx 4d56ti5GLg4hgdlMEv1bmhlBEswCOhI7t95hA7F5BfQktjW2sYDYwgKWEpc3LwaLswmoSHy7 fJcJxOYUcJTY924qWJxFQFXi8b5j7BBztCWWLXzNDDHHRuLWziaoZd8ZJab3NoAlRAQ0JLq2 /GGDuEhWYsaZtawTGPlmIbljFpI7ZiGZu4CReRWjYFFqTmKloaleYkFBTqpecn7uJkZQKDUU mu1g3PFX7hCjAAejEg9vZ8smfyHWxLLiytxDjBIczEoivGJmQCHelMTKqtSi/Pii0pzU4kOM 0hwsSuK870SBUgLpiSWp2ampBalFMFkmDk6pBsb++a3Ol/V+8Sydp8rw6aRn7jX1ugldhXu/ 8BuoTujwcusPmdXCW2G5cQN/d8hRuy1fD7ySzV8y592s5ECt8L183ZxMWmsW3f7rFj1ZK53x 0uSvRXGLCoRqF3G6x3z2/flLTaCwmHP7XQG2Y7z7b+704Nyw9VWDvdITO8Yv3o4afLtz72/f yqrEUpyRaKjFXFScCADI0dbmIQIAAA== Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 17:59:41 -0000 On May 15, 2012, at 09:33 , Ole Tr=F8an wrote: >>>=20 >>> 4.4. Transition Technologies Support >>>=20 >>> Transition technology support requirements: >>>=20 >>> TTS-1: The CPE router MAY support a TCP MSS Adjust feature on >>> packets traversing the CPE router. >>=20 >> I object to any TCP MSS text in the document. I share Mr. Troan's opinion, and I specifically object to the MAY clause = quoted above on the grounds that it conveys the rather undesirable idea = that IETF believes it is truly OPTIONAL whether routers will or will not = rewrite TCP headers in forwarded packets. I see no good reason to = promote this debauchery by affirmatively declaring tolerance of it. -- james woodyatt member of technical staff, core os networking From Fred.L.Templin@boeing.com Tue May 15 11:04:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D7C21F865C for ; Tue, 15 May 2012 11:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3u0kRgLUfra for ; Tue, 15 May 2012 11:04:29 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24F21F865F for ; Tue, 15 May 2012 11:04:29 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4FI4SNu002348 for ; Tue, 15 May 2012 11:04:28 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4FI4SuG002345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2012 11:04:28 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4FI4RLD023019; Tue, 15 May 2012 11:04:27 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4FI4RBm023014 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 15 May 2012 11:04:27 -0700 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, 15 May 2012 11:04:27 -0700 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Cameron Byrne Date: Tue, 15 May 2012 11:04:26 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0yvPIK64dTVt54SI6ztWwO/CJUnwABtlLQ Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <06E52FF8-0FFA-47ED-9882-1FA5D85A5279@laposte.net> In-Reply-To: <06E52FF8-0FFA-47ED-9882-1FA5D85A5279@laposte.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: Alexandre Cassen , IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 18:04:29 -0000 Hi Remi, > > c). 6204bis CE MAY implement a compensating mechanism for MTU related > > service degradation that may occur when tunnels such as 6RD and > > DS-lite are used >=20 > ... in particular by some ad hoc MSS reductions in TCP SYN packets > [RFC879] That's a great RFC, but I didn't see anything about gateways rewriting the MSS (or maybe that's not what you were intending to say). > c) is preferred to doing nothing especially if completed as proposed here= . >=20 > Free, the largest 6rd network, does AFAIK MSS rewrites (copy added to > Alexandre who can confirm or infirm). I have a different idea for 6rd MTU mitigations: 1) Set the 6rd tunnel MTU to 64KB 2) Set DF=3D0 in the outer IPv4 header of each packet admitted into the tunnel 3) The 6rd egress tunnel endpoint watches for any tunneled packets that arrive fragmented. When a fragmented tunneled packet arrives, the 6rd egress tunnel endpoint drops it and sends a UDP message to the 6rd tunnel ingress saying: "Packet Too Big". 4) The 6rd ingress tunnel endpoint receives the UDP PTB message, translates it into an ICMPv6 PTB message, and returns the message to the original IPv6 source within the 6rd site. Thanks - Fred fred.l.templin@boeing.com From jason.weil@twcable.com Tue May 15 11:13:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F21B21F878E for ; Tue, 15 May 2012 11:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.411 X-Spam-Level: X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6tivZssSQer for ; Tue, 15 May 2012 11:13:45 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 931E121F8772 for ; Tue, 15 May 2012 11:13:45 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,595,1330923600"; d="scan'208";a="364610030" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 15 May 2012 14:12:33 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 15 May 2012 14:12:45 -0400 From: "Weil, Jason" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Hemant Singh Date: Tue, 15 May 2012 14:12:44 -0400 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0yxlOGK3uyd61PSRWhk98fRYHv1g== 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.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 18:13:46 -0000 +1 ..and back to an earlier discussion, the MSS rewrite can but does not need to be done on the CPE Router. As a provider, If I chose to deploy an AFTR to support DS-Lite I would make sure the AFTR did the MSS rewrite since it is the one box I actually administer. I would want the service to be as controllable as possible so that I could tune as needed. A MAY here is not needed and should be dropped imo. Jason On 5/15/12 12:33 PM, "Ole Tr=F8an" wrote: >>> NEW >>> >>> 4.4. Transition Technologies Support >>> >>> Transition technology support requirements: >>> >>> TTS-1: The CPE router MAY support a TCP MSS Adjust feature on >>> packets traversing the CPE router. >>> >>> 4.4.1. 6rd >> >> I object to any TCP MSS text in the document. > >I got poked to give a reason for this opinion: > >top of my head: >- don't want an IPv6 router to have to do this forever >- don't want to require all routers to look into transport layer >information. > (aka layer violation) >- we never specified this for IPv4 >- is TCP MSS rewrite specified anywhere to reference? or are we now going >to specify that in an v6ops > document? >- this isn't specific to transition mechanisms > and isn't such an issue given that the MTU for 6rd, DS-lite are >required to be "well managed" >- doesn't solve the problem. > only works for TCP. only handles the case of a WAN-side MTU being lower >than LAN side MTU > use RFC481 for TCP >- should be reviewed by the transport area > >cheers, >Ole >_______________________________________________ >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 acassen@corp.free.fr Tue May 15 12:06:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E6C21F88B6 for ; Tue, 15 May 2012 12:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.069 X-Spam-Level: X-Spam-Status: No, score=-0.069 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGynJxqtSDja for ; Tue, 15 May 2012 12:06:25 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by ietfa.amsl.com (Postfix) with ESMTP id E92E921F88B5 for ; Tue, 15 May 2012 12:06:23 -0700 (PDT) Received: from lnxos-dev (unknown [213.228.1.188]) by smtp5-g21.free.fr (Postfix) with ESMTP id D5C92D4800D; Tue, 15 May 2012 21:06:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lnxos-dev (Postfix) with ESMTPS id 3C4429C0010; Tue, 15 May 2012 21:02:03 +0200 (CEST) Date: Tue, 15 May 2012 21:02:02 +0200 (CEST) From: Alexandre Cassen X-X-Sender: acassen@lnxos-dev To: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= In-Reply-To: <06E52FF8-0FFA-47ED-9882-1FA5D85A5279@laposte.net> Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <06E52FF8-0FFA-47ED-9882-1FA5D85A5279@laposte.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1939136844-1337108523=:17600" Cc: Alexandre Cassen , IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 19:06:25 -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. --8323329-1939136844-1337108523=:17600 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 15 May 2012, Rémi Després wrote: > Free, the largest 6rd network, does AFAIK MSS rewrites (copy added to > Alexandre who can confirm or infirm). not for 6rd, we do not perform mss_adjust at 6rd tuneling. In other tuneling playground we are using mss_adjust, yes, but not here. --8323329-1939136844-1337108523=:17600-- From wbeebee@cisco.com Tue May 15 12:16:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EB521F8835 for ; Tue, 15 May 2012 12:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.382 X-Spam-Level: X-Spam-Status: No, score=-8.382 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooTxrHxWq28q for ; Tue, 15 May 2012 12:16:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4876B21F882D for ; Tue, 15 May 2012 12:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=149; q=dns/txt; s=iport; t=1337109374; x=1338318974; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=y5hoyBtWekPZw99z0mDdYtsmhh6JJbfp1FwsrQFXzSI=; b=GHNOCMRF8Q9BA/RmJ43aKgoSvOQ5rkRLTG9uyamLV/EIpsEMSEnqutLq OzQSxfkHmqYjfVxAqqip42cG8D7eFQCvO5avRV45dq3dcpBC8vRa+bpNv bOy0I5mO5rxyAJbcYrLoIbbf0wk6DcmEc/4zj2VhUXQw80e7w294WNy70 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkHAC+qsk+tJXHA/2dsb2JhbABEij2pQgKBB4IVAQEBAwESAScCATwFDQEIgR0BAQQBDSeHZwWbBqATkRwElX2OVyeBQoMF X-IronPort-AV: E=Sophos;i="4.75,595,1330905600"; d="scan'208";a="83283934" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 15 May 2012 19:16:13 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q4FJGDKc022237; Tue, 15 May 2012 19:16:13 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 May 2012 14:16:13 -0500 Received: from 161.44.175.143 ([161.44.175.143]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 May 2012 19:16:13 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Tue, 15 May 2012 15:16:12 -0400 From: Wes Beebee To: =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , v6ops WG Message-ID: Thread-Topic: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? Thread-Index: Ac0yzzCuw6tWpcBj/0uHO+w9IferQw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 May 2012 19:16:13.0433 (UTC) FILETIME=[31898E90:01CD32CF] Cc: Daniel Roesen Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 19:16:15 -0000 > Suggestion (already made to Joel on another thread): document it in 6204bis > (a good opportunity for that), but only as a MAY. +1 - Wes From shemant@cisco.com Tue May 15 12:25:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2493E21F8849 for ; Tue, 15 May 2012 12:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.334 X-Spam-Level: X-Spam-Status: No, score=-10.334 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykHYpi8JNxzi for ; Tue, 15 May 2012 12:25:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 28D0021F87D3 for ; Tue, 15 May 2012 12:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6770; q=dns/txt; s=iport; t=1337109905; x=1338319505; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=pG74GZu6iEm20yud+83/upLX+ll+Ju4mwjyTHSxy6ik=; b=Wc5ahKNuNGalQ5wRNTv/FYMESKtFWdQldgX4Bi2rwPWSkC1eWY6BQlh4 EBSR1EWJMqWTz/QSmoJjUD4bgWTZJZ0dxXyxzyPIDEmS761E157JrOdHr LoyWYUs4V3NBQ9/nOaA88z27Ky1zQjfxtH7dD4RZKSPZ6Jk6UHAzpCxlZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAISssk+tJV2a/2dsb2JhbABEgkWxPIEHghUBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodsmn2gFIschR1jBIgwNJtwgWmDBw X-IronPort-AV: E=Sophos;i="4.75,595,1330905600"; d="scan'208,217";a="83503614" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 15 May 2012 19:25:04 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4FJP4Oq012319; Tue, 15 May 2012 19:25:04 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 May 2012 14:25:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD32D0.6DAA4F76" Date: Tue, 15 May 2012 14:25:03 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0yuIk/ydG7DqzrQbOYyoPlRAwKQAAAUHDQAACnQQA= References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com><301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> From: "Hemant Singh (shemant)" To: "Templin, Fred L" , =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 15 May 2012 19:25:04.0533 (UTC) FILETIME=[6E18FC50:01CD32D0] Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 19:25:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD32D0.6DAA4F76 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Tuesday, May 15, 2012 12:53 PM To: Ole Tr=F8an; Hemant Singh (shemant) Cc: IPv6 Operations Subject: RE: [v6ops] proposed TCP MSS text for rfc6204bis =20 =20 >So, I agree with Ole - no need to have MSS adjustments if >we can make path MTU discovery more robust. =20 PMTUD does not work across the Internet as already discussed related to = this thread; a node in the path may block ICMPv6 error to be propagated = back to the source of the packet too big. Also said was that even if = the ICMPv6 error makes it to the host, the host delays Internet = connectivity for the user because the host processes the ICMPv6 error = and works out out packet fragmentation. For a tunneled tech such as = DS-Lite the host the CPE is mandated to do tunnel fragmentation. This = is an interesting conundrum because DS-Lite did not ask the host to = fragment the payload but the host does fragment the payload. This issue = is resolved if the CPE implements the TCP MSS Adjust. =20 Additionally, it has be pointed out in earlier emails that when 6rd CPEs = communicate directly to each other without going thru the BR, then the = CPE is a good node in the path between the TCP server and the TCP client = to perform the TCP MSS Adjust. =20 Hemant ------_=_NextPart_001_01CD32D0.6DAA4F76 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin= @boeing.com]
Sent: Tuesday, May 15, 2012 12:53 PM
To: Ole = Tr=F8an; Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: RE: = [v6ops] proposed TCP MSS text for rfc6204bis

 

 

>So, I = agree with Ole - no need to have MSS adjustments = if

>we can make path MTU discovery = more robust.

 

PMTUD does not work = across the Internet as already discussed related to this thread; a node = in the path may block ICMPv6 error to be propagated back to the source = of the packet too big.=A0 Also said was that even if the ICMPv6 error = makes it to the host, the host delays Internet connectivity for the user = because the host processes the ICMPv6 error and works out out packet = fragmentation. =A0For a tunneled tech such as DS-Lite the host the CPE = is mandated to do tunnel fragmentation.=A0 This is an interesting = conundrum because DS-Lite did not ask the host to fragment the payload = but the host does fragment the payload.=A0 This issue is resolved if the = CPE implements the TCP MSS Adjust.

 

Additionally, it has be pointed out in earlier emails = that when 6rd CPEs communicate directly to each other without going thru = the BR, then the CPE is a good node in the path between the TCP server = and the TCP client to perform the TCP MSS = Adjust.

 

Hemant

------_=_NextPart_001_01CD32D0.6DAA4F76-- From shemant@cisco.com Tue May 15 12:32:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEED21F86D7 for ; Tue, 15 May 2012 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.333 X-Spam-Level: X-Spam-Status: No, score=-10.333 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re6OT8bf3byM for ; Tue, 15 May 2012 12:32:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5514B21F86D0 for ; Tue, 15 May 2012 12:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1558; q=dns/txt; s=iport; t=1337110350; x=1338319950; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=WRmOA219xP+kIY4fVilz6xtof8i30glVT96jyerTqSc=; b=YS/BO2ZJ9Ql5sDYnHx/VVwsgtJ4rdFzwWUO3FqNFcHAW0WP8WobTB1Mg wVuJ3YqAMDNCBHbw4Wu8YNQl735XJmICotVSjeCLliJJvKbh2MannDEPK gBTWKBN5mEpj0gcs/VTbNjNJ0nJImTRUzfQQDwLDn52tmtM2cN621EjGs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABGvsk+tJXG8/2dsb2JhbABEtAGBB4IVAQEBBBIBHUkMBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2yae6ARixyFHWMEiDA0m3CBaYMH X-IronPort-AV: E=Sophos;i="4.75,595,1330905600"; d="scan'208";a="80480758" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 15 May 2012 19:32:24 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4FJWNAD029375; Tue, 15 May 2012 19:32:24 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 May 2012 14:32:23 -0500 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-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 May 2012 14:32:22 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CAA1@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0yxlOGK3uyd61PSRWhk98fRYHv1gACj9tw References: From: "Hemant Singh (shemant)" To: "Weil, Jason" , =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 15 May 2012 19:32:23.0640 (UTC) FILETIME=[73D36580:01CD32D1] Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 19:32:31 -0000 Jason, There is no IETF document including the DS-Lite RFC 6333 that calls out = for MSS Rewrite at the DS-Lite AFTR. We also have an RFC in RFC 4459 = that covers fragmentation for tunneled technologies but the RFC does not = cover TCP MSS Adjust. That is why some folks have asked for the issue = to be captured in rfc6204bis and also because there are clear use cases = where the CPE is best doing the TCP MSS Adjust such as when 6rd nodes = are communicating directly with each other. A simple case when 6rd CPEs talk directly to each other. A host has = MTU default of 1500. The CPE uses PPPOE in 6rd and PPPOE has MTU of = 1492. The host sent a packet of size 1500. The CPE drops the packet = and issues an ICMPv6 error of packet too big. Now the host has to deal = with fragmentation and Internet connectivity of the host is delayed. Hemant -----Original Message----- From: Weil, Jason [mailto:jason.weil@twcable.com]=20 Sent: Tuesday, May 15, 2012 2:13 PM To: Ole Tr=F8an; Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis +1 ..and back to an earlier discussion, the MSS rewrite can but does not = need to be done on the CPE Router. As a provider, If I chose to deploy an = AFTR to support DS-Lite I would make sure the AFTR did the MSS rewrite since = it is the one box I actually administer. I would want the service to be as controllable as possible so that I could tune as needed. A MAY here is = not needed and should be dropped imo. Jason From simon.perreault@viagenie.ca Tue May 15 12:32:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5E21F882D for ; Tue, 15 May 2012 12:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFzIp9K1rrUK for ; Tue, 15 May 2012 12:32:47 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id EA93D21F8779 for ; Tue, 15 May 2012 12:32:46 -0700 (PDT) Received: from [IPv6:2607:fa48:94:201:7dcb:4d7f:6ab0:60f0] (unknown [IPv6:2607:fa48:94:201:7dcb:4d7f:6ab0:60f0]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3E6AC41596; Tue, 15 May 2012 15:32:46 -0400 (EDT) Message-ID: <4FB2AF61.3090300@viagenie.ca> Date: Tue, 15 May 2012 15:32:49 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 19:32:47 -0000 On 2012-05-15 11:06, Hemant Singh (shemant) wrote: > TTS-1: The CPE router MAY support a TCP MSS Adjust feature on > packets traversing the CPE router. -1 The statement is too general. Allowing MSS rewriting all the time on all packets under any circumstance is wrong. It has to be qualified carefully. Either we spend time carefully qualifying the statement, or we leave it as future work for a separate RFC. I vote for the latter. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ichiroumakino@gmail.com Tue May 15 12:39:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334F911E8087 for ; Tue, 15 May 2012 12:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atjbM894L3po for ; Tue, 15 May 2012 12:39:36 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68D2711E8083 for ; Tue, 15 May 2012 12:39:36 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4451540wgb.13 for ; Tue, 15 May 2012 12:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pgcauzPKgcF+Vlf90RrLC3TL6V2EC8sS+D+gKT7FfR8=; b=zuNFEUW/+ilo3MCtoy1we7ZUA9zdVs0Sk/McOjEndkEjxkb4nkU06/vct0QM8Spq45 kcwLfs/XDVT1KFhU5A9KfhKbdu+4ZwGNmMkaTdz6R2T4vXk8/2phVqJyoDg8s94QcSn+ iSS7+i2ctLZLy8qrwhMZAboGHYgSdduJSbiPAwvxr3DkziSp3KyPhvRXQa5AW+/tDNvt uSmYNFXVGZ2PGJ7ab8rcHc+Qn5RX05GCVtxCgc7AOmBIvyyUb2ybDDTXmSMTvQBqe2EU 2G1p3WuclmN054ij4FskuQbYDf6kV1gaCrhzmJqduFMhaA/XiWf16dIP0BFURu2lsLd+ gdvA== Received: by 10.180.83.196 with SMTP id s4mr575313wiy.15.1337110775452; Tue, 15 May 2012 12:39:35 -0700 (PDT) Received: from dhcp-10-61-97-36.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id o9sm438330wia.3.2012.05.15.12.39.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 12:39:34 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CAA1@XMB-RCD-109.cisco.com> Date: Tue, 15 May 2012 21:39:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8DE45446-85D8-4FB1-BC3C-282CE31D0260@employees.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CAA1@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 19:39:37 -0000 > A simple case when 6rd CPEs talk directly to each other. A host has = MTU default of 1500. The CPE uses PPPOE in 6rd and PPPOE has MTU of = 1492. The host sent a packet of size 1500. The CPE drops the packet = and issues an ICMPv6 error of packet too big. Now the host has to deal = with fragmentation and Internet connectivity of the host is delayed. please read section 9.1 of RFC5969. Ole From mawatari@jpix.ad.jp Tue May 15 13:23:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F2321F86CA for ; Tue, 15 May 2012 13:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 w6LDeNlwu9C7 for ; Tue, 15 May 2012 13:23:50 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5501B21F86B7 for ; Tue, 15 May 2012 13:23:49 -0700 (PDT) Received: from [192.168.1.6] (i114-185-194-56.s42.a013.ap.plala.or.jp [114.185.194.56]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 82661FC021 for ; Wed, 16 May 2012 05:23:48 +0900 (JST) Date: Wed, 16 May 2012 05:23:46 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: <064AFE4D-77DA-4DE2-95EE-2D5A551B452F@laposte.net> References: <4FB17649.6070404@globis.net> <064AFE4D-77DA-4DE2-95EE-2D5A551B452F@laposte.net> Message-Id: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 20:23:51 -0000 Dear Remi-san and all, We appreciate your comments. 1. There were some comments about deleting dedicated IPv6 prefix model without NAT44 from the 464XLAT document on v6ops mailing list. But, we, 464XLAT co-authors, would like to keep the dedicated IPv6 prefix model without NAT44 on the 464XLAT document. Our beliefs are simple as below. - We insist that we should eliminate implement complexity on CPE and reduce the cost (memory resources on CPE, operation cost (troubleshooting, user support)) for IPv4 long life during a period of transition from IPv4 to IPv6 as far as possible. - 464XLAT using a dedicated IPv6 prefix can do that instead of assigning a dedicated IPv6 prefix for translation. We would not like to write specific descriptions for keeping selectivity of operator's priority. So we think we should write 2 models (dedicated IPv6 prefix and no dedicated IPv6 prefix). Honestly, we do not care about the document category. We think that is depending on v6ops members and chairs. 2. We will add following sentence. --- By combining 464XLAT with BIH [RFC6535], it is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts across IPv6-only networks. --- If we have any missing points, please let me know. Kind Regards, Masataka MAWATARI * On Tue, 15 May 2012 09:36:13 +0200 * Remi Despres wrote: > Masataka-san, Masanobu-san, Cameron, > > 1. > Could you please clarify your intention? > > Privately, you justified your lack of interest for improvements I proposed by your wish to publish the draft as is, planing for this to have it back to *informational* rather than BCP. > If this is the case, can you please confirm here? > > If not, I guess I should send to the WG detailed amendments proposed to you for the BCP to be acceptable AFAIAC. > > > 2. > 2012-05-14 23:16, Ray Hunter: > >> Rajiv Asati (rajiva) > >> 14 May 2012 22:58 > >> Ray, > >> > >>> How would an IPv4 only host be able to resolve the to-be-translated IPv4 > >>> address for a connection to an IPv6 only server that only had a AAAA > >>> record, and no native A record? > >> > >> I don't think that this use-case is covered by 464XLAT, but Is the > >> v6-only server realistic yet? > >> > >> Cheers, > >> Rajiv > >> > > Don't know. > > > > I was just triggered by the following sentence in the 464XLAT ID, which is why I asked the question: > > > > /It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts./ > > As already said, this sentence becomes understandable if it is noted that 464XLAT can be combined with RFC 6535. > (RFC 6535 is the standard track specification for connectivity from IPv4-only applications to IPv6-only servers). > Without this, the sentence should IMHO be deleted. > > Regards, > RD From Fred.L.Templin@boeing.com Tue May 15 13:30:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C8711E80C0 for ; Tue, 15 May 2012 13:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKk7lIPZMyaa for ; Tue, 15 May 2012 13:30:02 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 0B79311E80B3 for ; Tue, 15 May 2012 13:30:02 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4FKTtaR031350 for ; Tue, 15 May 2012 13:29:56 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4FKTtgB031329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2012 13:29:55 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4FKU0LC001787; Tue, 15 May 2012 13:30:00 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4FKU0am001778 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 15 May 2012 13:30:00 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 15 May 2012 13:30:00 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Tue, 15 May 2012 13:29:58 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0yuIk/ydG7DqzrQbOYyoPlRAwKQAAAUHDQAACnQQAABlsOgA== Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com><301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.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-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 20:30:03 -0000 Hi Hemant, >> So, I agree with Ole - no need to have MSS adjustments if >> we can make path MTU discovery more robust. > > PMTUD does not work across the Internet as already discussed > related to this thread; a node in the path may block ICMPv6 > error to be propagated back to the source of the packet too > big. Let's examine the components of an IPv6 path supported by a 6rd tunnel: 1) the path within the 6rd site between the IPv6 host and the 6rd CPE. 2) the path within the operator's network between the CPE and the 6rd BR. 3) the path from the BR across the IPv6 Internet to the final destination's site. 4) the path from the final destination's site border router to the final destination. For component 1), IPv6 PMTUD must surely work in order for heterogeneous link MTUs to be active within the site. For components 3) and 4), IPv6 PMTUD must surely work in order for the original source to obtain useful PMTUD feedback *even if some router is adjusting the MSS*. This is because the links within the component 3) and 4) paths may have a too-small MTU to support the MSS chosen by the router.=20 For component 2), it is not possible to rely on IPv4 PMTUD due to the many well-known issues. That is why my proposal is to disable IPv4 PMTUD by setting DF=3D0 and having the 6rd tunnel egress return the IPv6 PMTUD feedback (and, I just realized that UDP encaps is unnecessary because the 6rd egress can simply use plain IPv6/IPv4 encapsulation to return the ICMPv6 PTB message back to the ingress). > Also said was that even if the ICMPv6 error makes it > to the host, the host delays Internet connectivity for the > user because the host processes the ICMPv6 error and works > out out packet fragmentation. =A0For a tunneled tech such as > DS-Lite the host the CPE is mandated to do tunnel fragmentation. > This is an interesting conundrum because DS-Lite did not ask > the host to fragment the payload but the host does fragment > the payload.=A0 This issue is resolved if the CPE implements > the TCP MSS Adjust. I find this all to be very weak reasoning. IF the host gets the necessary PMTUD feedback it will do the right thing - it's been that way for over 20 years. Any tweaks by middleboxes that try to give small optimizations to hosts are just best-guesses as to how the hosts will react. > Additionally, it has be pointed out in earlier emails that > when 6rd CPEs communicate directly to each other without > going thru the BR, then the CPE is a good node in the path > between the TCP server and the TCP client to perform the > TCP MSS Adjust. For the CPE-to-CPE path, it works the just the same way as for the CPE-to-BR path. In neither case does a CPE have to adjust MSS if MTU discovery is properly implemented. > Hemant Fred (and please do not turn this back into RTF) From Tina.Tsou.Zouting@huawei.com Tue May 15 14:20:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5235321F8758 for ; Tue, 15 May 2012 14:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2D837YaqkZX for ; Tue, 15 May 2012 14:20:20 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5638F21F8757 for ; Tue, 15 May 2012 14:20:20 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF42516; Tue, 15 May 2012 17:20:20 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 14:18:03 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Tue, 15 May 2012 14:18:02 -0700 From: Tina TSOU To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [v6ops] 6204 bis and mtu Thread-Index: AQHNL9iYEJKix0ifpEKlx7IAMvUSbZbF9OEAgAAlV4CAAKPxgP//lA4egAAQt2CAAgKZAIAAPIJDgADQHoCAAe5rIA== Date: Tue, 15 May 2012 21:18:01 +0000 Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com><10e101cd3002$4917d960$db478c20$@com>, <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C38C@XMB-RCD-109.cisco.com> <52F40CF6-7FD1-4E5C-8617-C885F1D7AE9E@huawei.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C393@XMB-RCD-109.cisco.com>, <7B93EA23-7A06-481D-9E97-7DE1DE12A76B@townsley.net> <4F1F03B5-4219-4AC6-AAAF-7B7AB5881DB2@employees.org> In-Reply-To: <4F1F03B5-4219-4AC6-AAAF-7B7AB5881DB2@employees.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.151] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 21:20:21 -0000 Tina > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Tr=F8an > Sent: Monday, May 14, 2012 1:48 AM > To: Tina TSOU > Cc: Mark Townsley; IPv6 Operations > Subject: Re: [v6ops] 6204 bis and mtu >=20 > Tina, >=20 > > In traditional 6RD scenarios, the IPv6 packets must be encapsulated int= o > the IPv4 packets with DIP pointing to BR. So in traditional 6RD scenarios= , > the IPv6 packets must go through the BR. >=20 > incorrect. you have misunderstood how 6rd works. 6rd is a mesh mode tunne= l. I am very sorry that I have missed the scenario of CE <--> CE tunnel in 6RD= .=20 Ole is correct. >=20 > cheers, > Ole From shemant@cisco.com Tue May 15 14:58:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9535311E809F for ; Tue, 15 May 2012 14:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.331 X-Spam-Level: X-Spam-Status: No, score=-10.331 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWrruHA9GsLr for ; Tue, 15 May 2012 14:58:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ADF1721F87E5 for ; Tue, 15 May 2012 14:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5205; q=dns/txt; s=iport; t=1337119105; x=1338328705; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=+pPlzPL938uO5gZOKJr4jKTlDlX32ac1UdYf93PF6d8=; b=IGFmuiUCnaGEqUCfYc+F/3dK+HwhYCz7mmlEXZh4HFuPj1KHz+C6PL3a IeKi+/Ne/viurk/k5pZhxu+W8o9h4nRuBbOoGF36izt8cslBKwJjIcrGG TzlvO7ZNTx9cCmF7GnG7VWXsS4bCBkH73emKkO+yHqnigq/reaKKkhkxY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM/Qsk+tJV2a/2dsb2JhbABEgkWxP4EHghUBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBICUJCAEBBBMIGodeAwubGZYyDYlTii5uhR1jBIgwNJhWgxqBaYMH X-IronPort-AV: E=Sophos;i="4.75,598,1330905600"; d="scan'208,217";a="83544118" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 15 May 2012 21:58:21 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4FLwLMI026505; Tue, 15 May 2012 21:58:21 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 May 2012 16:58:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD32E5.D73FA7E2" Date: Tue, 15 May 2012 16:58:19 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CB7E@XMB-RCD-109.cisco.com> In-Reply-To: <8DE45446-85D8-4FB1-BC3C-282CE31D0260@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0y0n8celHk1NhbRfmksfwmaqdAdAAEqe3Q References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CAA1@XMB-RCD-109.cisco.com> <8DE45446-85D8-4FB1-BC3C-282CE31D0260@employees.org> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 15 May 2012 21:58:21.0081 (UTC) FILETIME=[D7AAD890:01CD32E5] Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 21:58:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD32E5.D73FA7E2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Tr=F8an Sent: Tuesday, May 15, 2012 3:40 PM To: Hemant Singh (shemant) Cc: Weil, Jason; IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis =20 =20 >please read section 9.1 of RFC5969. =20 =20 The section includes recommendations on the 6rd tunnel MTU. However, = the deployment cannot control that the default MTU on most popular host = operating systems is 1500. Thus if the CPE is set to anything smaller = than 1500 for an MTU, the use case of host packet drop at the CPE and = the CPE issuing ICMPv6 Error for packet too big to the host stands. = Then one has UnHappyEyeballs. =20 TCP MSS Adjust at the CPE fixes the issue by adjusting the MSS so that = the host TCP client uses the MSS value.=20 =20 Hemant ------_=_NextPart_001_01CD32E5.D73FA7E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: Ole Troan = [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Tr=F8an
Sent: = Tuesday, May 15, 2012 3:40 PM
To: Hemant Singh (shemant)
Cc: Weil, = Jason; IPv6 Operations
Subject: Re: [v6ops] proposed TCP MSS text for = rfc6204bis

 

 

>please read section 9.1 of = RFC5969.

 

 

The section includes recommendations = on the 6rd tunnel MTU.=A0 However, the deployment cannot control that = the default MTU on most popular host operating systems is 1500.=A0 Thus = if the CPE is set to anything smaller than 1500 for an MTU, the use case = of host packet drop at the CPE and the CPE issuing ICMPv6 Error for = packet too big to the host stands.=A0 Then one has = UnHappyEyeballs.

 

TCP MSS Adjust at the CPE fixes the issue by adjusting = the MSS so that the host TCP client uses the MSS value. =

 

Hemant

------_=_NextPart_001_01CD32E5.D73FA7E2-- From Fred.L.Templin@boeing.com Tue May 15 15:28:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD6311E8097 for ; Tue, 15 May 2012 15:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQfu41f177NI for ; Tue, 15 May 2012 15:28:32 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9AA11E8093 for ; Tue, 15 May 2012 15:28:32 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4FMSlL0011637 for ; Tue, 15 May 2012 15:28:47 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4FMSl54011630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2012 15:28:47 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4FMSVfJ008751; Tue, 15 May 2012 15:28:31 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4FMSUiS008742 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 15 May 2012 15:28:31 -0700 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, 15 May 2012 15:28:30 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Tue, 15 May 2012 15:28:29 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0y0n8celHk1NhbRfmksfwmaqdAdAAEqe3QAAC0Q9A= Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CAA1@XMB-RCD-109.cisco.com> <8DE45446-85D8-4FB1-BC3C-282CE31D0260@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CB7E@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CB7E@XMB-RCD-109.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-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 22:28:32 -0000 >> please read section 9.1 of RFC5969. > > The section includes recommendations on the 6rd tunnel > MTU.=A0However, the deployment cannot control that the > default MTU on most popular host operating systems is > 1500.=A0 Thus if the CPE is set to anything smaller than > 1500 for an MTU, the use case of host packet drop at > the CPE and the CPE issuing ICMPv6 Error for packet > too big to the host stands.=A0 Then one has UnHappyEyeballs. Why? IPv6 PMTUD within the site works. For that matter, IPv6 PMTUD over any all-IPv6 path works. If that were not to be the case, then no choice but to set MTU=3D1280 on all links. We should only be worried about the MTU of any portion of the path that is manifested by IPv6 in IPv4 tunneling, i.e. the 6rd tunnel. My proposal=20 fixes that portion of the path. > TCP MSS Adjust at the CPE fixes the issue by adjusting > the MSS so that the host TCP client uses the MSS value. If the CPE adjusts MSS to anything larger than 1240, there may still be some other link on the path to the final destination that configures a too-small MTU to support the chosen MSS. In that case, an ICMPv6 PTB is generated and you still have to rely on IPv6 PMTUD. And, adjusting MSS to 1240 would (IMHO) be a very unsatisfactory outcome. Fred fred.l.templin@boeing.com From shtsuchi@cisco.com Tue May 15 16:56:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B43511E80AF for ; Tue, 15 May 2012 16:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22QavQuzBVuH for ; Tue, 15 May 2012 16:56:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 99F8C11E8099 for ; Tue, 15 May 2012 16:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=906; q=dns/txt; s=iport; t=1337126188; x=1338335788; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4/ykWfAVuR/CS85xKn75PHZsN3C+U/OybxErzUaVOB4=; b=NnRblzeKCNgOxeQOL95HTFliSYtbyo8opF61vdiGsDFuhaMryj2xSd5i GaAfDl42z5SoOmx+/pyUQB9c/x/yfT2HOyKrbcfS2bHJJq8t8vwo281sK DkArI2pizzm4mFId/HdJdEvuNztRInzN4nvL8/4vOIuzoS/sjCf1aWG3C Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsFAK/ssk+tJV2Y/2dsb2JhbABEgx2CX64JgQeCFQEBAQICAQEBDwEQDwEFNgsQCxgCAgUhAgIPAhYwBg0BBQIBAR6HbAuaeI0WknqBMIwegg6BGASIYo0bhXWIYoFpgng X-IronPort-AV: E=Sophos;i="4.75,598,1330905600"; d="scan'208";a="83524977" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 15 May 2012 23:56:28 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4FNuSuK005898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 May 2012 23:56:28 GMT Received: from [10.71.44.89] (173.37.183.73) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 15 May 2012 18:56:27 -0500 Message-ID: <4FB2ED26.40606@cisco.com> Date: Wed, 16 May 2012 08:56:22 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [173.37.183.73] X-TM-AS-Product-Ver: SMEX-10.2.0.1135-6.800.1017-18906.007 X-TM-AS-Result: No--10.221000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: dr@cluenet.de, v6ops@ietf.org Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 May 2012 23:56:29 -0000 +1 I also prefer "MAY". I checked "IPv6 Home Router Guideline" which was published by IPv6 Promotion council IPv6 Home Router SWG. Even Japan environment which is providing pppoe to customer nation wide,the requirement is MAY. http://www.v6pc.jp/en/wg/coexistenceWG/v6hgw-swg.phtml http://www.v6pc.jp/pdf/v6hgw_Guideline_20.pdf 7.4 Special Forwarding Requirement 55ïĵš A router has a function for appropriately adjusting the MSS (Maximum Segment Size) option of TCP communication through a Home Router. NecessityïĵšOptionalïĵˆMAY) Regards, -Shishio (2012/05/16 4:16), Wes Beebee wrote: >> Suggestion (already made to Joel on another thread): document it in 6204bis >> (a good opportunity for that), but only as a MAY. > > +1 > > - Wes > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From shemant@cisco.com Tue May 15 18:43:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C6111E80AF for ; Tue, 15 May 2012 18:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.031 X-Spam-Level: X-Spam-Status: No, score=-10.031 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBJ4rkVXNx3U for ; Tue, 15 May 2012 18:43:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6010911E8095 for ; Tue, 15 May 2012 18:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=580; q=dns/txt; s=iport; t=1337132622; x=1338342222; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5fHJMt+99/sJ5hnp+8VxJteujFBoqEmnCdhAa8ypG4E=; b=X5v0VSR2lf8iQ4nvxH6Si+BWPk3rV/SFAGsRP5gNV2Hr5K1YcXfBJ3aC IZwBWBYtrVGYoYePaAcZBAscJudp1GjrtjcPezeqog73Pw8tiOCuWaUou f1b0pBh85dc3j/re6zmlLCpET8WrlEEbbqH17TIsJ/N1o2chgIzneaYVr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA8Gs0+tJV2Z/2dsb2JhbABEtAOBB4IVAQEBAwEBAQEPAR0+CwUHBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodnBQubBaARBIschHVjBIgwNJtwgWmDBw X-IronPort-AV: E=Sophos;i="4.75,599,1330905600"; d="scan'208";a="83581054" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 16 May 2012 01:43:23 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4G1hNLK000958; Wed, 16 May 2012 01:43:23 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 May 2012 20:43:22 -0500 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-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 May 2012 20:43:21 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CBDE@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? Thread-Index: Ac0yzzCuw6tWpcBj/0uHO+w9IferQwANg/RQ References: From: "Hemant Singh (shemant)" To: "Wes Beebee (wbeebee)" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "v6ops WG" X-OriginalArrivalTime: 16 May 2012 01:43:22.0441 (UTC) FILETIME=[471AE390:01CD3305] Cc: Daniel Roesen Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 01:43:43 -0000 +1 Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Wes Beebee (wbeebee) Sent: Tuesday, May 15, 2012 3:16 PM To: R=E9mi Despr=E9s; v6ops WG Cc: Daniel Roesen Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY? > Suggestion (already made to Joel on another thread): document it in = 6204bis > (a good opportunity for that), but only as a MAY. +1 - Wes _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From hesham@elevatemobile.com Tue May 15 19:05:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824DA21F8742 for ; Tue, 15 May 2012 19:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM5tqIg016ui for ; Tue, 15 May 2012 19:05:43 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC7221F8740 for ; Tue, 15 May 2012 19:05:36 -0700 (PDT) Received: from [124.181.25.243] (helo=[10.0.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SUTby-0006WK-TU; Wed, 16 May 2012 12:05:11 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 16 May 2012 12:04:54 +1000 From: Hesham Soliman To: Marc Blanchet , IPv6 Operations Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 02:05:44 -0000 > >I agree with Ole that MSS rewrite is not specific to this document and >requires additional detailed specification on how it is done. >So I'm also opposed in adding this requirement as it is now (i.e. >underspecified and not discussing all the consequences). > >So either=20 >a) we identify a document that clearly describes how to do MSS rewrite, >the pros and cons, the applicability, etc=8A and then we refer to that >document. Does such document exist? >b) we do not specify MSS rewrite here. =3D> +1. I would like to add that such document should be reviewed by the Transport area.=20 Hesham > >Regards, Marc. > >> - this isn't specific to transition mechanisms >> and isn't such an issue given that the MTU for 6rd, DS-lite are >>required to be "well managed" >> - doesn't solve the problem. >> only works for TCP. only handles the case of a WAN-side MTU being >>lower than LAN side MTU >> use RFC481 for TCP >> - should be reviewed by the transport area >>=20 >> cheers, >> Ole >> _______________________________________________ >> 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 lorenzo@google.com Tue May 15 20:37:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317B821F86C5 for ; Tue, 15 May 2012 20:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=0.048, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zArF5kOIWs9Y for ; Tue, 15 May 2012 20:37:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D15C21F86C4 for ; Tue, 15 May 2012 20:37:57 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so489811obb.31 for ; Tue, 15 May 2012 20:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=cHhsv2nOVuKsrvZdI9UvvwdBhcDsXPIkRQq2rWvke/Y=; b=IPqjgTU2QUKeUB1nVhrAT2wQ/IrUfu+YcjZFlQfN6JHka8ceLZrz0ZEM08453D22Hj Rw/8wFud1CHaSjmyDFUO4abixwz3RCVMvJ3Za2eAdqTJ/8tYJpkDuBJSeZ7ynibg+dTn YRBqnX7RExhw3JDfk43/5TzGjoVZqGBCa8/U4csCGDRfXmp1jJtrat5VsDzpSc3yzD2b 99tVQeV24UlZAGxayZt0rax3rcnR4vj1AV+xT8U1l0NsGeB6memsd6kxxE12XdT0QHFx 278G2YUB/vdXZJdtk/oqH6KSUW1y+AcXORkXvOboAaplyO5pg8BTXBbGtojJw/BFzgW3 D7ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=cHhsv2nOVuKsrvZdI9UvvwdBhcDsXPIkRQq2rWvke/Y=; b=OFcZWvldOQkyasr2VtbRAoIpA+11CJ2G/GJI6Slisk/f2iKiMpHeay4Fs+kTh4KIdr wUpQkl1cQPvdkMNG1EUPDCsvAUu+8Bm124bfJjRa1lEqKugCHTeSIbcdrjvF1YWemSCu mFUi08basLNxfm8sjX+/596/ql9EB0g+hZmEAsqA3pJEwRqpEjRsoh9IKsOCYc9hXvPc JCjP6Q1RsB+Ik1JKTDtsMdkL4miVrMHuDM/Z9CQ/e0ao9BYA+FPIvqaBW2E5XQuzEXax 9W+yWqUR8W/Bn7XYLi4/JlFB7XWrIqqSkZEk2cW+XBYC5L6AwxFCBQDT0CRzWcVQ/4wx Wq7w== Received: by 10.182.167.39 with SMTP id zl7mr1375875obb.10.1337139476827; Tue, 15 May 2012 20:37:56 -0700 (PDT) Received: by 10.182.167.39 with SMTP id zl7mr1375864obb.10.1337139476551; Tue, 15 May 2012 20:37:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Tue, 15 May 2012 20:37:35 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Wed, 16 May 2012 12:37:35 +0900 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=e89a8f642c7483d98d04c01f0bec X-System-Of-Record: true X-Gm-Message-State: ALoCoQm3k72OZD6OUMcqQJjPzeRw/0t4jpHJpwC2FlrL+YFbqBYYQUfiS9Mghjlwa+YDiefTi44jggb/8KQWiuF5eeIfxr3OsqAWBWorEOCw+AlQadvp+BES6vh6rdHJjncsuMS2Gdjh Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 03:37:58 -0000 --e89a8f642c7483d98d04c01f0bec Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 15, 2012 at 12:13 AM, Hemant Singh (shemant) wrote: > (a) **Any of *native IPv6* and tunneled technologies such as DS-Lite > and 6rd can cause ICMPv6 errors for packet too big to the source. Even > when the CPE issues the ICMPv6 error to the host connected to the CPE, the > Internet access of the host is delayed which is not good. Additionally, > what if the CPE passes the host packet to the Internet and one router on > the Internet issues the ICMPv6 error with packet too big but a node in the > path back blocks the ICMPv6 error. Now the Internet connectivity is > really delayed for the host. This summarizes that we do have problems to > fix. > I strongly disagree that this is a CPE problem. The node in the path is doing it wrong and needs to be fixed. The CPE should not work around this problem. --e89a8f642c7483d98d04c01f0bec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 15, 2012 at 12:13 AM, Hemant Singh (= shemant) <shemant@cisco.com> wrote:

(= a)=A0= =A0=A0 Any of native IPv6 =A0and tunneled technologies= such as DS-Lite and 6rd can cause ICMPv6 errors for packet too big to the = source.=A0=A0 Even when the CPE issues the ICMPv6 error to the host connect= ed to the CPE, the Internet access of the host is delayed which is not good= .=A0=A0 Additionally, what if the CPE passes the host packet to the Interne= t and one router on the Internet issues the ICMPv6 error with packet too bi= g but a node in the path back blocks the ICMPv6 error.=A0 =A0Now the Intern= et connectivity is really delayed for the host.=A0=A0 This summarizes that = we do have problems to fix.


I strongly disagree that this is a C= PE problem. The node in the path is doing it wrong and needs to be fixed. T= he CPE should not work around this problem.
--e89a8f642c7483d98d04c01f0bec-- From Carl.Wuyts@technicolor.com Tue May 15 23:00:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923D521F8628 for ; Tue, 15 May 2012 23:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.764 X-Spam-Level: X-Spam-Status: No, score=-5.764 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P98qBPhKCPTy for ; Tue, 15 May 2012 23:00:20 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5321F8616 for ; Tue, 15 May 2012 23:00:18 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKT7NCcN8+gZXiIihcxPAYydHAD3fYhFYQ@postini.com; Tue, 15 May 2012 23:00:20 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 16 May 2012 07:57:16 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 16 May 2012 07:57:27 +0200 From: Wuyts Carl To: "Templin, Fred L" , "Hemant Singh (shemant)" , =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Wed, 16 May 2012 07:57:25 +0200 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0yuIk/ydG7DqzrQbOYyoPlRAwKQAAAUHDQAACnQQAABlsOgAAUlmHA Message-ID: <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com><301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 06:00:21 -0000 +1, PMTUD it should be!! No MSS. Please tackle the problem where it pops u= p, i.e. if certain nodes don't do their jobs on ICMPv6 handling, they're no= t qualified for the role, so it should be fixed at those places. One keeps= trying to push some "improvements" to the CPEs while it's not the CPE impl= ementing anything wrong. =20 Don't get me wrong, I don't ignore the issue being present. We've been bla= med already before that our PPP was not working OK for IPV6, but in the end= , some node was dropping the ICMPv6 messages, hence dropped packets due to = MTU size. regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= emplin, Fred L Sent: dinsdag 15 mei 2012 22:30 To: Hemant Singh (shemant); Ole Tr=F8an Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis Hi Hemant, >> So, I agree with Ole - no need to have MSS adjustments if we can make=20 >> path MTU discovery more robust. > > PMTUD does not work across the Internet as already discussed related=20 > to this thread; a node in the path may block ICMPv6 error to be=20 > propagated back to the source of the packet too big. Let's examine the components of an IPv6 path supported by a 6rd tunnel: 1) the path within the 6rd site between the IPv6 host and the 6rd CPE. 2) the path within the operator's network between the CPE and the 6rd BR. 3) the path from the BR across the IPv6 Internet to the final destination's site. 4) the path from the final destination's site border router to the final destination. For component 1), IPv6 PMTUD must surely work in order for heterogeneous li= nk MTUs to be active within the site. For components 3) and 4), IPv6 PMTUD must surely work in order for the orig= inal source to obtain useful PMTUD feedback *even if some router is adjusti= ng the MSS*. This is because the links within the component 3) and 4) paths= may have a too-small MTU to support the MSS chosen by the router.=20 For component 2), it is not possible to rely on IPv4 PMTUD due to the many well-known issues. That is why my proposal is to disable IPv4 PMTUD by setting DF=3D0 and havi= ng the 6rd tunnel egress return the IPv6 PMTUD feedback (and, I just realiz= ed that UDP encaps is unnecessary because the 6rd egress can simply use pla= in IPv6/IPv4 encapsulation to return the ICMPv6 PTB message back to the ing= ress). > Also said was that even if the ICMPv6 error makes it to the host, the=20 > host delays Internet connectivity for the user because the host=20 > processes the ICMPv6 error and works out out packet fragmentation. =A0 > For a tunneled tech such as DS-Lite the host the CPE is mandated to do=20 > tunnel fragmentation. > This is an interesting conundrum because DS-Lite did not ask the host=20 > to fragment the payload but the host does fragment the payload.=A0 This=20 > issue is resolved if the CPE implements the TCP MSS Adjust. I find this all to be very weak reasoning. IF the host gets the necessary P= MTUD feedback it will do the right thing - it's been that way for over 20 y= ears. Any tweaks by middleboxes that try to give small optimizations to hos= ts are just best-guesses as to how the hosts will react. > Additionally, it has be pointed out in earlier emails that when 6rd=20 > CPEs communicate directly to each other without going thru the BR,=20 > then the CPE is a good node in the path between the TCP server and the=20 > TCP client to perform the TCP MSS Adjust. For the CPE-to-CPE path, it works the just the same way as for the CPE-to-B= R path. In neither case does a CPE have to adjust MSS if MTU discovery is p= roperly implemented. > Hemant Fred (and please do not turn this back into RTF) __________________________= _____________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Tue May 15 23:59:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CC421F855F for ; Tue, 15 May 2012 23:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.93 X-Spam-Level: X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.046, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONkLpQSJy207 for ; Tue, 15 May 2012 23:59:56 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC321F855D for ; Tue, 15 May 2012 23:59:55 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so753794obb.31 for ; Tue, 15 May 2012 23:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7D8nidUvmExbM3lQyzwIkEXP/JKza9Ew+YAvrs44JGQ=; b=TNcvEEQZHUeYbkJ5lS+ndpvsyzyH0HtyHKPtkdvIHFKrr1X7AIJbWQrzSXf5e0beSB QmfwtkPQR8H0++p4gr0am+rwQJ1V7vrqEN6FYJkvLJ2308xYLy1PvqVUb8nfbUYM3dAd zaiEzjKnhV7WeOx/v+QPOiDPt6I6zT+2l1RrdFj7h6E8a4ouW5LTW8TkWb/jV2l9YNE0 XKMGT4HA3EjA4Vq/7eyq9YEZPv2yXHV1bSNauZQ4lnvxcrv9sxB8lf1MwklpVzr1wlwy Ld4o3QL18ElulG7FsFiotSKoDJtU/6QB9FwO6N/p5NaqKkYMH4OmUz6nSCdXV5FuA69c //Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7D8nidUvmExbM3lQyzwIkEXP/JKza9Ew+YAvrs44JGQ=; b=eF01u+6EukRVLpxcADc9qnIms+rjcTJvSkGXhtUMS51MuRQBgS9lx1r7MeAoMG46NI BNVAMPA7z/8fnToxKs+PyAM8l/t8TYjsEuRxKsUXkG/omN7cLKlSCvYTSOIq6MBsUnYQ M2BYSF5+5JGU9BYC6LY2svnoa88858wUlzukREx+F0RWKzNtHGOfXHAiv2tnr3T6sFwx d9Ghe72hYye8gJ7gIhAey1xihmikVOG6amdrHPyLTannwQEA8Tddg1wOmAfOrDsyzLAA eWKje3qI1YY8bXfe0MhI+xVwjG0sNsUCK8YmbznF15PW+LOlUwjSuG17MKebBcIkeiwO ah4w== Received: by 10.60.14.41 with SMTP id m9mr1655568oec.57.1337151595551; Tue, 15 May 2012 23:59:55 -0700 (PDT) Received: by 10.60.14.41 with SMTP id m9mr1655544oec.57.1337151595334; Tue, 15 May 2012 23:59:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Tue, 15 May 2012 23:59:35 -0700 (PDT) In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> From: Lorenzo Colitti Date: Wed, 16 May 2012 15:59:35 +0900 Message-ID: To: Wuyts Carl Content-Type: multipart/alternative; boundary=e89a8fb1fac0d9cdf604c021dd6e X-System-Of-Record: true X-Gm-Message-State: ALoCoQkQ1SDWtJT26Ag970pCWXWkrbe2mw68mnXRK9oOsMTR3+su0i0bqFDWqTpP5/uYy3eVb91ESxyZWMKlNktkLVxZ+iQkCIkEM36mzD5f4474lFVMcdCMnrEnAu7FJTPfATRe/Lwr Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 06:59:56 -0000 --e89a8fb1fac0d9cdf604c021dd6e Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 16, 2012 at 2:57 PM, Wuyts Carl wrote: > +1, PMTUD it should be!! No MSS. Please tackle the problem where it pops > up, i.e. if certain nodes don't do their jobs on ICMPv6 handling, they're > not qualified for the role, so it should be fixed at those places. Even if you fix all those places, PMTUD still adds one RTT to every connection you make to a new host. Do we want to live with that kind of performance penalty compared to IPv4 - or, are you willing to have strict happy eyeballs implementation always prefer IPv4 because IPv6 is slow to establish connections I'm not saying the solution should be MSS rewriting - I don't think it should be. But if you're a 6rd CPE and you know your MTU to the Internet is 1480, then giving the host an MTU of 1480 in the RA would improve TCP latency. --e89a8fb1fac0d9cdf604c021dd6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 16, 2012 at 2:57 PM, Wuyts Carl <Carl.Wuyts@technicolor.com> wrote:
+1, PMTUD it should be!! No MSS. =A0Please tackle the problem where it pops= up, i.e. if certain nodes don't do their jobs on ICMPv6 handling, they= 're not qualified for the role, so it should be fixed at those places.<= /blockquote>

Even if you fix all those places, PMTUD still adds one = RTT to every connection you make to a new host. Do we want to live with tha= t kind of performance penalty compared to IPv4 - or, are you willing to hav= e strict happy eyeballs implementation always prefer IPv4 because IPv6 is s= low to establish connections

I'm not saying the solution should be MSS rewriting= - I don't think it should be. But if you're a 6rd CPE and you know= your MTU to the Internet is 1480, then giving the host an MTU of 1480 in t= he RA would improve TCP latency.
--e89a8fb1fac0d9cdf604c021dd6e-- From Carl.Wuyts@technicolor.com Wed May 16 00:05:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00321F858F for ; Wed, 16 May 2012 00:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkbBBSVP11uJ for ; Wed, 16 May 2012 00:05:26 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB0021F8589 for ; Wed, 16 May 2012 00:05:23 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKT7NRsYRnb1ludJCXlH1cuefbYQXmEE5P@postini.com; Wed, 16 May 2012 00:05:25 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 16 May 2012 09:02:45 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 16 May 2012 09:02:56 +0200 From: Wuyts Carl To: Lorenzo Colitti Date: Wed, 16 May 2012 09:02:55 +0200 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0zMYJeO4Mtj/sTTJuL0iXWo4HPfwAAC1+A Message-ID: <867F4B6A1672E541A94676D556793ACD10E23328D9@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD10E23328D9MOPESMBX01eut_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 07:05:27 -0000 --_000_867F4B6A1672E541A94676D556793ACD10E23328D9MOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable @ Lorenzo Our RTADVD allows for setting MTU (configurable), so can be applied for 6rd= without any problems, so this has been taken into account already. Just w= ant to avoid "dirty" work-around in CPE-land with MSS-stuff. Regs Carl From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: woensdag 16 mei 2012 9:00 To: Wuyts Carl Cc: Templin, Fred L; Hemant Singh (shemant); Ole Tr=F8an; IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis On Wed, May 16, 2012 at 2:57 PM, Wuyts Carl > wrote: +1, PMTUD it should be!! No MSS. Please tackle the problem where it pops u= p, i.e. if certain nodes don't do their jobs on ICMPv6 handling, they're no= t qualified for the role, so it should be fixed at those places. Even if you fix all those places, PMTUD still adds one RTT to every connect= ion you make to a new host. Do we want to live with that kind of performanc= e penalty compared to IPv4 - or, are you willing to have strict happy eyeba= lls implementation always prefer IPv4 because IPv6 is slow to establish con= nections I'm not saying the solution should be MSS rewriting - I don't think it shou= ld be. But if you're a 6rd CPE and you know your MTU to the Internet is 148= 0, then giving the host an MTU of 1480 in the RA would improve TCP latency. --_000_867F4B6A1672E541A94676D556793ACD10E23328D9MOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

@ Lorenzo=

Our RTADVD allows for set= ting MTU (configurable), so can be applied for 6rd without any problems, so= this has been taken into account already.=A0 Just want to avoid “dir= ty” work-around in CPE-land with MSS-stuff.

 

Regs

Carl<= /span>

 

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: woensdag 16 mei 2012 9:00
To: Wuyts Carl
Cc: Templin= , Fred L; Hemant Singh (shemant); Ole Tr=F8an; IPv6 Operations
Subjec= t: Re: [v6ops] proposed TCP MSS text for rfc6204bis

 

On Wed, May 16, 2012 at 2:57 PM, Wuyts Carl <Carl.Wuyts@technicolor.com> wr= ote:

+1, PMTUD it should be!! No MSS. &n= bsp;Please tackle the problem where it pops up, i.e. if certain nodes don't= do their jobs on ICMPv6 handling, they're not qualified for the role, so i= t should be fixed at those places.

=  

Even if you fix all th= ose places, PMTUD still adds one RTT to every connection you make to a new = host. Do we want to live with that kind of performance penalty compared to = IPv4 - or, are you willing to have strict happy eyeballs implementation alw= ays prefer IPv4 because IPv6 is slow to establish connections

 

I'm not saying the solution should be MSS rewriting - I don't = think it should be. But if you're a 6rd CPE and you know your MTU to the In= ternet is 1480, then giving the host an MTU of 1480 in the RA would improve= TCP latency.

= --_000_867F4B6A1672E541A94676D556793ACD10E23328D9MOPESMBX01eut_-- From despres.remi@laposte.net Wed May 16 00:08:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CCE21F85E7 for ; Wed, 16 May 2012 00:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqt9imXY740B for ; Wed, 16 May 2012 00:08:57 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 987CA21F85E6 for ; Wed, 16 May 2012 00:08:57 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id CC2857000040; Wed, 16 May 2012 09:08:56 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id 2E11D70000A2; Wed, 16 May 2012 09:08:56 +0200 (CEST) X-SFR-UUID: 20120516070856188.2E11D70000A2@msfrf2321.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 16 May 2012 09:08:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <06E52FF8-0FFA-47ED-9882-1FA5D85A5279@laposte.net> To: Alexandre Cassen X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 07:08:58 -0000 Le 2012-05-15 =E0 21:02, Alexandre Cassen a =E9crit : >=20 >=20 > On Tue, 15 May 2012, R=E9mi Despr=E9s wrote: >> Free, the largest 6rd network, does AFAIK MSS rewrites (copy added to = Alexandre who can confirm or infirm). >=20 > not for 6rd, we do not perform mss_adjust at 6rd tuneling. In other = tuneling playground we are using mss_adjust, yes, but not here. I suppose it is acceptable because 1280, the common IPv6 transmit MTU, = purposely chosen well below the 1500 common link MTU, the need is not = the same as for some other tunnels. =20 Thanks for the clarification. RD= From despres.remi@laposte.net Wed May 16 00:13:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF94A21F85F1 for ; Wed, 16 May 2012 00:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUl8AfcUP7aw for ; Wed, 16 May 2012 00:13:24 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 64CA721F85EA for ; Wed, 16 May 2012 00:13:24 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id C0E3B7000044; Wed, 16 May 2012 09:13:23 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id 8523D70000A2; Wed, 16 May 2012 09:13:23 +0200 (CEST) X-SFR-UUID: 20120516071323545.8523D70000A2@msfrf2321.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 16 May 2012 09:13:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <06E52FF8-0FFA-47ED-9882-1FA5D85A5279@laposte.net> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 07:13:25 -0000 Hi Fred, Le 2012-05-15 =E0 20:04, Templin, Fred L a =E9crit : > Hi Remi, >=20 >>> c). 6204bis CE MAY implement a compensating mechanism for MTU = related >>> service degradation that may occur when tunnels such as 6RD and >>> DS-lite are used >>=20 >> ... in particular by some ad hoc MSS reductions in TCP SYN packets >> [RFC879] >=20 > That's a great RFC, but I didn't see anything about > gateways rewriting the MSS (or maybe that's not what > you were intending to say). This RFC, which is about CE routers, isn't concerned with what other = gateways might do. Regards, RD =20 >=20 >> c) is preferred to doing nothing especially if completed as proposed = here. >>=20 >> Free, the largest 6rd network, does AFAIK MSS rewrites (copy added to >> Alexandre who can confirm or infirm). >=20 > I have a different idea for 6rd MTU mitigations: >=20 > 1) Set the 6rd tunnel MTU to 64KB > 2) Set DF=3D0 in the outer IPv4 header of each packet > admitted into the tunnel > 3) The 6rd egress tunnel endpoint watches for any > tunneled packets that arrive fragmented. When a > fragmented tunneled packet arrives, the 6rd egress > tunnel endpoint drops it and sends a UDP message > to the 6rd tunnel ingress saying: "Packet Too Big". > 4) The 6rd ingress tunnel endpoint receives the > UDP PTB message, translates it into an ICMPv6 > PTB message, and returns the message to the > original IPv6 source within the 6rd site. >=20 > Thanks - Fred > fred.l.templin@boeing.com From despres.remi@laposte.net Wed May 16 00:25:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3174221F86F8 for ; Wed, 16 May 2012 00:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IulcGrx0+yY5 for ; Wed, 16 May 2012 00:25:18 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9047C21F86EE for ; Wed, 16 May 2012 00:25:18 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id 9393270000AE; Wed, 16 May 2012 09:25:17 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id 42E5C70000AD; Wed, 16 May 2012 09:25:17 +0200 (CEST) X-SFR-UUID: 20120516072517274.42E5C70000AD@msfrf2418.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 16 May 2012 09:25:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4ED0951D-E320-4982-892B-F541DB923A39@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 07:25:19 -0000 2012-05-15 =E0 19:59, james woodyatt: > On May 15, 2012, at 09:33 , Ole Tr=F8an wrote: >>>>=20 >>>> 4.4. Transition Technologies Support >>>>=20 >>>> Transition technology support requirements: >>>>=20 >>>> TTS-1: The CPE router MAY support a TCP MSS Adjust feature on >>>> packets traversing the CPE router. >>>=20 >>> I object to any TCP MSS text in the document. >=20 >=20 > I share Mr. Troan's opinion, and I specifically object to the MAY = clause quoted above on the grounds that it conveys the rather = undesirable idea that IETF believes it is truly OPTIONAL whether routers = will or will not rewrite TCP headers in forwarded packets. =20 > I see no good reason to promote this debauchery by affirmatively = declaring tolerance of it. For clarification of why you say this: - Is it that you negate that MSS rewrite can prevent adverse effects of = fragmentation where TCP ICMP-PTB packets are lost or ignored? - Or is it because such prevention uses some inter-layer cooperation = (very limited but real)? Regards, RD >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Wed May 16 00:35:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E982821F877F for ; Wed, 16 May 2012 00:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beOg2WNV7Ewn for ; Wed, 16 May 2012 00:35:39 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id E402021F877E for ; Wed, 16 May 2012 00:35:38 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id 1F7C070000B3; Wed, 16 May 2012 09:35:38 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id E4BB170000A1; Wed, 16 May 2012 09:35:37 +0200 (CEST) X-SFR-UUID: 20120516073537937.E4BB170000A1@msfrf2418.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> Date: Wed, 16 May 2012 09:35:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FB17649.6070404@globis.net> <064AFE4D-77DA-4DE2-95EE-2D5A551B452F@laposte.net> <20120516052346.63F1.8FE1F57E@jpix.ad.jp> To: MAWATARI Masataka X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 07:35:40 -0000 Le 2012-05-15 =E0 22:23, MAWATARI Masataka a =E9crit : > Dear Remi-san and all, >=20 > We appreciate your comments. >=20 >=20 > 1. > There were some comments about deleting dedicated IPv6 prefix model > without NAT44 from the 464XLAT document on v6ops mailing list. >=20 > But, we, 464XLAT co-authors, would like to keep the dedicated IPv6 > prefix model without NAT44 on the 464XLAT document. >=20 > Our beliefs are simple as below. >=20 > - We insist that we should eliminate implement complexity on CPE > and reduce the cost (memory resources on CPE, operation cost > (troubleshooting, user support)) for IPv4 long life during a > period of transition from IPv4 to IPv6 as far as possible. >=20 > - 464XLAT using a dedicated IPv6 prefix can do that instead of > assigning a dedicated IPv6 prefix for translation. >=20 > We would not like to write specific descriptions for keeping > selectivity of operator's priority. So we think we should write > 2 models (dedicated IPv6 prefix and no dedicated IPv6 prefix). > Honestly, we do not care about the document category. > We think > that is depending on v6ops members and chairs. If the proposed simplification based on on a CLAT well-known interface = ID is not included, I personally object to BCP status, but have no = objection against Informational (the originally proposed status). =20 > 2. > We will add following sentence. > --- > By combining 464XLAT with BIH [RFC6535], it is also possible to > provide single IPv4/IPv6 translation service, which will be needed in > the future case of IPv6-only servers and peers to be reached from > legacy IPv4-only hosts across IPv6-only networks. > --- A useful clarification IMHO. Thanks. Regards, RD >=20 >=20 > If we have any missing points, please let me know. >=20 >=20 > Kind Regards, > Masataka MAWATARI >=20 >=20 > * On Tue, 15 May 2012 09:36:13 +0200 > * Remi Despres wrote: >=20 >> Masataka-san, Masanobu-san, Cameron, >>=20 >> 1. >> Could you please clarify your intention? >>=20 >> Privately, you justified your lack of interest for improvements I = proposed by your wish to publish the draft as is, planing for this to = have it back to *informational* rather than BCP. >> If this is the case, can you please confirm here? >>=20 >> If not, I guess I should send to the WG detailed amendments proposed = to you for the BCP to be acceptable AFAIAC. >>=20 >>=20 >> 2. >> 2012-05-14 23:16, Ray Hunter: >>>> Rajiv Asati (rajiva) >>>> 14 May 2012 22:58 >>>> Ray, >>>>=20 >>>>> How would an IPv4 only host be able to resolve the = to-be-translated IPv4 >>>>> address for a connection to an IPv6 only server that only had a = AAAA >>>>> record, and no native A record? >>>>=20 >>>> I don't think that this use-case is covered by 464XLAT, but Is the >>>> v6-only server realistic yet? >>>>=20 >>>> Cheers, >>>> Rajiv >>>>=20 >>> Don't know. >>>=20 >>> I was just triggered by the following sentence in the 464XLAT ID, = which is why I asked the question: >>>=20 >>> /It is also possible to provide single IPv4/IPv6 translation = service, which will be needed in the future case of IPv6-only servers = and peers to be reached from legacy IPv4-only hosts./ >>=20 >> As already said, this sentence becomes understandable if it is noted = that 464XLAT can be combined with RFC 6535. >> (RFC 6535 is the standard track specification for connectivity from = IPv4-only applications to IPv6-only servers). >> Without this, the sentence should IMHO be deleted. >>=20 >> Regards, >> RD >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Wed May 16 00:37:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EDA21F87CD for ; Wed, 16 May 2012 00:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.782 X-Spam-Level: X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN7VLt0bfX1s for ; Wed, 16 May 2012 00:37:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 496DB21F87C7 for ; Wed, 16 May 2012 00:37:03 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so805733obb.31 for ; Wed, 16 May 2012 00:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=cNWa6B6tTBOAmNOqpBzNfwxQqKK9+CCPHEWEC+6q1rM=; b=PXzmyGY7fPEXonusTpGdSK7JbCIVyDkY1c1iGHjNt0hg2nxGZDqOVfXfImL34O0IdY vdqCpeYxVlz43zzNZUGaChSialTpG2PuZAEjGFvmjRnhAoxd7lAljtRrQeIRkuatfsCG ygLnoGoKhDANnmBe6BlsRYwi2O3t5ulE/GmYtMK4aZA1t57Qp/xvV9n74vhCS5Lw9GFx V8lbNCmPmyQhcaYkWATqvOv1/TsartYQvcx1JklRuQKQ7L1DyuLo22hJXcfrlOpywSP3 rp6hdd1kIEPcw3LJr+W2/uW6UU+d9HfIUoh3GU6/6GJPQ8zCg3GRCnfcyyT5kG4M2QH6 iOGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=cNWa6B6tTBOAmNOqpBzNfwxQqKK9+CCPHEWEC+6q1rM=; b=BDc2Tfi5UouuxTt0NHZxSfzou19+0FAQmEiozZCme3UTR6FMkvUrDuvJ8I2S4akOAF XeDLwcZVdqV8eMOQ60R8HN16YHGzdWg2inWVyMcpgzXvWJrGuPf5JWccd7oNsL3NNUbW Nf+VshOZv61h9/qfWhgxGnqIvemTX+vP2y6rksCxq1xgd4yM1mcOGls2JLIDiFFuLrPk UD5kV3SDFuyQREQ5hoJQ0EiL0JEadY+FZBbh7M86OezFghXhq51VhxZ4osjfFkytJ1qv Sf9zijJmpv3W7asi0pa/1qM50YdRg+gJBS8STiWKqksIXnnConeNIdRW5w7cClmUeoup 1HXw== Received: by 10.182.169.68 with SMTP id ac4mr1811802obc.19.1337153822801; Wed, 16 May 2012 00:37:02 -0700 (PDT) Received: by 10.182.169.68 with SMTP id ac4mr1811786obc.19.1337153822616; Wed, 16 May 2012 00:37:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Wed, 16 May 2012 00:36:42 -0700 (PDT) In-Reply-To: <4ED0951D-E320-4982-892B-F541DB923A39@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <4ED0951D-E320-4982-892B-F541DB923A39@laposte.net> From: Lorenzo Colitti Date: Wed, 16 May 2012 16:36:42 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8f646a219b6c6304c0226219 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnpYPX7DEKaxfAcZYhok2givYRHtFUkzCQM1pVrPhKTyjCvIBkYDrmBFa4OAfKnDB0oY+Y0vvVK+wqvRbA9ZfHpLTC9z4aY4qo7uOz1IFZ21Kue/vR0GSIb30tpZ2okIihRhNUp Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 07:37:03 -0000 --e89a8f646a219b6c6304c0226219 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 16, 2012 at 4:25 PM, R=E9mi Despr=E9s wrote: > - Or is it because such prevention uses some inter-layer cooperation (ver= y > limited but real)? > I think what he said is: - It's superfluous - It's a layering violation - The IETF should not endorse it by making it optional I would like to add that superfluous -> slow. --e89a8f646a219b6c6304c0226219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 16, 2012 at 4:25 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
- Or is it because such prevention uses some inter-layer cooperation (very = limited but real)?

I think what he said= is:

- It's superfluous
- It's a= layering violation
- The IETF should not endorse it by making it optional

<= /div>
I would like to add that superfluous -> slow.
--e89a8f646a219b6c6304c0226219-- From v6ops@globis.net Wed May 16 00:57:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF1621F869F for ; Wed, 16 May 2012 00:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6HzuJ2JhDBq for ; Wed, 16 May 2012 00:57:47 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C234021F867E for ; Wed, 16 May 2012 00:57:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8E20A87007D; Wed, 16 May 2012 09:57:45 +0200 (CEST) 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 ciGFlowg7xTU; Wed, 16 May 2012 09:57:37 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 76BE6870065; Wed, 16 May 2012 09:57:37 +0200 (CEST) Message-ID: <4FB35DF0.4060308@globis.net> Date: Wed, 16 May 2012 09:57:36 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: MAWATARI Masataka References: <4FB17649.6070404@globis.net> <064AFE4D-77DA-4DE2-95EE-2D5A551B452F@laposte.net> <20120516052346.63F1.8FE1F57E@jpix.ad.jp> In-Reply-To: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 07:57:47 -0000 Thanks Masataka-san. The pointer from Remi and yourself to RFC6535 answered my question and removed my confusion on DNS A record synthesis. But RFC6535 will NOT help with legacy IPv4 only *hosts* IMHO RFC6535 provides the necessary locally synthesised A record within the API to support certain legacy IPv4 only *applications*, only on the client side, only for applications that can traverse NAT, and only for ones that use DNS for name resolution. The synthesised A record never appears on the wire. All hosts will still eventually have to speak native IPv6 on the wire if they want to enjoy universal connectivity. It may seem like a small thing to the WG, but raising any expectations that legacy IPv4 hosts and applications can continue to work as-is forever without any changes (due to the widespread deployment of magic translators within the Internet infrastructure) makes many of my clients doubt whether they should invest in IPv6 at all. Respectfully suggest the following text: By combining 464XLAT with BIH [RFC6535], it is also possible to provide a single step IPv4/IPv6 translation service, which may be needed in the future so that IPv6-only servers and peers can be reached across IPv6-only networks from a limited subset of legacy IPv4-only applications. regards, RayH MAWATARI Masataka wrote: > Dear Remi-san and all, > > We appreciate your comments. > > > 1. > There were some comments about deleting dedicated IPv6 prefix model > without NAT44 from the 464XLAT document on v6ops mailing list. > > But, we, 464XLAT co-authors, would like to keep the dedicated IPv6 > prefix model without NAT44 on the 464XLAT document. > > Our beliefs are simple as below. > > - We insist that we should eliminate implement complexity on CPE > and reduce the cost (memory resources on CPE, operation cost > (troubleshooting, user support)) for IPv4 long life during a > period of transition from IPv4 to IPv6 as far as possible. > > - 464XLAT using a dedicated IPv6 prefix can do that instead of > assigning a dedicated IPv6 prefix for translation. > > We would not like to write specific descriptions for keeping > selectivity of operator's priority. So we think we should write > 2 models (dedicated IPv6 prefix and no dedicated IPv6 prefix). > Honestly, we do not care about the document category. We think > that is depending on v6ops members and chairs. > > > 2. > We will add following sentence. > --- > By combining 464XLAT with BIH [RFC6535], it is also possible to > provide single IPv4/IPv6 translation service, which will be needed in > the future case of IPv6-only servers and peers to be reached from > legacy IPv4-only hosts across IPv6-only networks. > --- > > > If we have any missing points, please let me know. > > > Kind Regards, > Masataka MAWATARI > > > * On Tue, 15 May 2012 09:36:13 +0200 > * Remi Despres wrote: > >> Masataka-san, Masanobu-san, Cameron, >> >> 1. >> Could you please clarify your intention? >> >> Privately, you justified your lack of interest for improvements I proposed by your wish to publish the draft as is, planing for this to have it back to *informational* rather than BCP. >> If this is the case, can you please confirm here? >> >> If not, I guess I should send to the WG detailed amendments proposed to you for the BCP to be acceptable AFAIAC. >> >> >> 2. >> 2012-05-14 23:16, Ray Hunter: >>>> Rajiv Asati (rajiva) >>>> 14 May 2012 22:58 >>>> Ray, >>>> >>>>> How would an IPv4 only host be able to resolve the to-be-translated IPv4 >>>>> address for a connection to an IPv6 only server that only had a AAAA >>>>> record, and no native A record? >>>> I don't think that this use-case is covered by 464XLAT, but Is the >>>> v6-only server realistic yet? >>>> >>>> Cheers, >>>> Rajiv >>>> >>> Don't know. >>> >>> I was just triggered by the following sentence in the 464XLAT ID, which is why I asked the question: >>> >>> /It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts./ >> As already said, this sentence becomes understandable if it is noted that 464XLAT can be combined with RFC 6535. >> (RFC 6535 is the standard track specification for connectivity from IPv4-only applications to IPv6-only servers). >> Without this, the sentence should IMHO be deleted. >> >> Regards, >> RD > > From marka@isc.org Wed May 16 01:07:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7BB21F8551 for ; Wed, 16 May 2012 01:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S01dIO0rxkQM for ; Wed, 16 May 2012 01:07:42 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 81FF621F8550 for ; Wed, 16 May 2012 01:07:42 -0700 (PDT) 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 C0D575F9906; Wed, 16 May 2012 08:07:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:210b:6ab2:ca5:2c98]) (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 E3B79216C36; Wed, 16 May 2012 08:07:22 +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 440B520AAA62; Wed, 16 May 2012 18:07:18 +1000 (EST) To: Lorenzo Colitti From: Mark Andrews References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> In-reply-to: Your message of "Wed, 16 May 2012 15:59:35 +0900." Date: Wed, 16 May 2012 18:07:17 +1000 Message-Id: <20120516080718.440B520AAA62@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 08:07:43 -0000 In message , Lorenzo Colitti writes: > On Wed, May 16, 2012 at 2:57 PM, Wuyts Carl wrote > : > > > +1, PMTUD it should be!! No MSS. Please tackle the problem where it pops > > up, i.e. if certain nodes don't do their jobs on ICMPv6 handling, they're > > not qualified for the role, so it should be fixed at those places. > > > Even if you fix all those places, PMTUD still adds one RTT to every > connection you make to a new host. Do we want to live with that kind of > performance penalty compared to IPv4 - or, are you willing to have strict > happy eyeballs implementation always prefer IPv4 because IPv6 is slow to > establish connections Happy Eyeballs doesn't see the PMTUD issues, they come later in the transaction. If you want Happy Eyeballs to see PMTUD then we need a TCP option that pads the SYN|ACK to the computed MSS and does it for both IPv4 and IPv6. Happy Eyeballs will then prefer IPv6 if DS-Lite is in use and IPv4 if 6to4 / 6rd are in use and be agnostic if both are native. > I'm not saying the solution should be MSS rewriting - I don't think it > should be. But if you're a 6rd CPE and you know your MTU to the Internet is > 1480, then giving the host an MTU of 1480 in the RA would improve TCP > latency. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From despres.remi@laposte.net Wed May 16 02:19:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407CA21F87ED for ; Wed, 16 May 2012 02:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbcmOOrkA+j1 for ; Wed, 16 May 2012 02:19:36 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 45C8721F87F7 for ; Wed, 16 May 2012 02:19:35 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 4364F70000AF; Wed, 16 May 2012 11:19:35 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id D39D5700004B; Wed, 16 May 2012 11:19:34 +0200 (CEST) X-SFR-UUID: 20120516091934866.D39D5700004B@msfrf2304.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-35-223005412 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 16 May 2012 11:19:34 +0200 Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <4ED0951D-E320-4982-892B-F541DB923A39@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 09:19:37 -0000 --Apple-Mail-35-223005412 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-05-16 =E0 09:36, Lorenzo Colitti: > On Wed, May 16, 2012 at 4:25 PM, R=E9mi Despr=E9s = wrote: > - Or is it because such prevention uses some inter-layer cooperation = (very limited but real)? >=20 > I think what he said is: >=20 > - It's superfluous Not vital, I agree, but not superfluous as long as ICMP PTB handling is = known to be abundantly mistreated, and fragmentation can deteriorate = performance. > - It's a layering violation Well, one can see it as a layer "cooperation" (serves a useful = purpose). > - The IETF should not endorse it by making it optional I can't understand why IETF wouldn't document, and permit as opposed to = require, a solution that is known to do some good and no harm, and that = has been successfully used in the field. > I would like to add that superfluous -> slow. Not sure to understand what you mean. RD= --Apple-Mail-35-223005412 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, May 16, 2012 at 4:25 PM, R=E9mi Despr=E9s = <despres.remi@laposte.net> = wrote:
- Or is it because such prevention uses some inter-layer cooperation = (very limited but real)?

I think = what he said is:

- It's = superfluous

Not vital, I = agree, but not superfluous as long as ICMP PTB handling is known to be = abundantly mistreated, and fragmentation can deteriorate = performance.

- It's a layering = violation

Well, one can see it as = a layer "cooperation"  (serves a useful = purpose).

- The IETF should not endorse it by making it = optional

I can't = understand why IETF wouldn't document, and permit as opposed to require, = a solution that is known to do some good and no harm, and that has been = successfully used in the field.

I would like to add that = superfluous -> slow.

Not sure to understand what you = mean.

RD
= --Apple-Mail-35-223005412-- From gert@space.net Wed May 16 02:24:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C294521F87E3 for ; Wed, 16 May 2012 02:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDKQ3TQhIZG0 for ; Wed, 16 May 2012 02:24:43 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id E585D21F87D7 for ; Wed, 16 May 2012 02:24:41 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9DBB2F8B74 for ; Wed, 16 May 2012 11:24:40 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 92DA1F8B6F for ; Wed, 16 May 2012 11:24:40 +0200 (CEST) Received: (qmail 95473 invoked by uid 1007); 16 May 2012 11:24:40 +0200 Date: Wed, 16 May 2012 11:24:40 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20120516092440.GX84425@Space.Net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 09:24:43 -0000 Hi, On Wed, May 16, 2012 at 03:59:35PM +0900, Lorenzo Colitti wrote: > On Wed, May 16, 2012 at 2:57 PM, Wuyts Carl wrote: > > > +1, PMTUD it should be!! No MSS. Please tackle the problem where it pops > > up, i.e. if certain nodes don't do their jobs on ICMPv6 handling, they're > > not qualified for the role, so it should be fixed at those places. > > Even if you fix all those places, PMTUD still adds one RTT to every > connection you make to a new host. Do we want to live with that kind of > performance penalty compared to IPv4 - or, are you willing to have strict > happy eyeballs implementation always prefer IPv4 because IPv6 is slow to > establish connections I don't think HE will actually notice that delay, as it happens after SYN/ACK handshaking - and HE is happy as soon as the connect() returns. But indeed, this is not particularily nice, as the MTU-impaired link will usually be close to the client, and the server's MTU needs to be adjusted. OTOH, one might hope that eventually people will learn how to build proper ISP backbones that can handle a layer of ISP-network tunneling (like "PPPoE") without MTU reduction... Or one could advise the servers to assume 1492 byte MTU for the generic eyeball case... > I'm not saying the solution should be MSS rewriting - I don't think it > should be. But if you're a 6rd CPE and you know your MTU to the Internet is > 1480, then giving the host an MTU of 1480 in the RA would improve TCP > latency. True (assuming that the incoming MTU is then also 1480 and that the host would signal a proper MSS to the server). Outbound packets from the client wouldn't suffer that much, as only the LAN RTT will be added. 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 dr@cluenet.de Wed May 16 03:55:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8446B21F8742 for ; Wed, 16 May 2012 03:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec74GLPN+FqF for ; Wed, 16 May 2012 03:55:24 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id B9EF221F8746 for ; Wed, 16 May 2012 03:55:24 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id B74D31083B6; Wed, 16 May 2012 12:55:22 +0200 (CEST) Date: Wed, 16 May 2012 12:55:22 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120516105522.GA6613@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> <20120516092440.GX84425@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120516092440.GX84425@Space.Net> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 10:55:25 -0000 On Wed, May 16, 2012 at 11:24:40AM +0200, Gert Doering wrote: > OTOH, one might hope that eventually people will learn how to build > proper ISP backbones that can handle a layer of ISP-network tunneling > (like "PPPoE") without MTU reduction... Sometimes it's not that easy. E.g. how do you manage endpoint-specific MTU in a shared L3 broadcast domain? There is a proposal for an IPv6 NDP extension to negotiate bilateral MTU, but nothing standardised, let alone generally implemented. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From jouni.nospam@gmail.com Wed May 16 03:59:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0652621F85F2 for ; Wed, 16 May 2012 03:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gkfsd-AR8Vb for ; Wed, 16 May 2012 03:59:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 271C721F862A for ; Wed, 16 May 2012 03:59:11 -0700 (PDT) Received: by lagv3 with SMTP id v3so463421lag.31 for ; Wed, 16 May 2012 03:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=oYW16diQFPLGkR31UWw59kwcf7j94l+uaby0hUjqnys=; b=HSmkuTplGzANI+zhF294BDBPziAQOdUKSynpw7Cjawhy+8ic/gNjTYYL/dCOWEEOpr qtzsm6MMAON6fJY3W6rAnzBCjstAtCMePvb7/6BRS+BBfFHgzg1qvFuNl6uXIdahriGF xTzhCXxFfZSKuCX90XC/KGrTC4wPO17YCRdOb+o3TjOmUFu/D1svN2ML+QcwbaN0N0EU aYmi57a/dtouyubofAl5aHMJx1+Z4FICsQ24a2Fr3j0q956lwSVZVP0XGHQjeQ6SqnTd GZtjqE8HnqHe/9eci0rfUj1cgu1DiZVHyQUYp2EIMXDWUubHDDjOUf1CHKNRwwJ9+zNs idXQ== Received: by 10.112.49.131 with SMTP id u3mr1238003lbn.14.1337165951053; Wed, 16 May 2012 03:59:11 -0700 (PDT) Received: from a88-114-71-183.elisa-laajakaista.fi (a88-114-71-183.elisa-laajakaista.fi. [88.114.71.183]) by mx.google.com with ESMTPS id ox7sm3059856lbb.17.2012.05.16.03.59.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 03:59:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 16 May 2012 13:59:07 +0300 Content-Transfer-Encoding: 7bit Message-Id: <52EFFB80-9AE5-41CF-8F27-8598C8EFB0EC@gmail.com> References: <4FB10D4B.60009@globis.net> To: Cameron Byrne , "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 10:59:14 -0000 Hi, I got few comments on the draft -03.. mainly editorial. o Sections 3. and 6.2. first paragraphs could add a reference to [RFC6459], since it is already in the references section but never used in the main text. My proposals: Section 3: ... translation. This is especially cost-effective in wireless 3GPP GSM and UMTS networks that would otherwise require two separate PDP connections to support IPv4 and IPv6 [RFC6459]. Section 6.2: The vast majority of mobile wireless networks are compliant to Pre- Release 9 3GPP standards. In Pre-Release 9 3GPP networks, GSM and UMTS networks must signal and support both IPv4 and IPv6 PDP attachments to access IPv4 and IPv6 network destinations [RFC6459]. ... o Section 3 could add a reference to TS23.203 for PCC. o Section 6.2 could also mention that each PDP connection also equals to a RAB, which is indeed costly when it comes to support for parallel context over the radio. o Section 7.5 talks about the case where there is no dedicated translation prefix. I would not say "will do NAT44.." there, rather "can do NAT44.." This is imho an implementation choice, for example, inside the UE that has to serve only a single IPv4 address. o Same as above for Section 7.6 o Section 7.5 or Section 6.2 could state for 3G case that when DHCPv6-PD is not available opening a second IPv6 PDP Connection for obtaining a dedicated translation prefix is not recommended. Rather stick with a single prefix model.. - Jouni From Jean-Francois.TremblayING@videotron.com Wed May 16 05:37:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CBE21F8646 for ; Wed, 16 May 2012 05:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWDpFagIcJWN for ; Wed, 16 May 2012 05:37:39 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 95F2F21F85AD for ; Wed, 16 May 2012 05:37:39 -0700 (PDT) In-Reply-To: To: IPv6 Operations MIME-Version: 1.0 X-KeepSent: CA8FF2EA:9D4248DD-85257A00:00443E73; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Wed, 16 May 2012 08:37:24 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP1|March 07, 2012) at 05/16/2012 08:37:27, Serialize complete at 05/16/2012 08:37:27 Content-Type: multipart/alternative; boundary="=_alternative 0045592085257A00_=" Received-SPF: none Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 12:37:40 -0000 Message en plusieurs parties au format MIME --=_alternative 0045592085257A00_= Content-Type: text/plain; charset="US-ASCII" >> +1, PMTUD it should be!! No MSS. > I'm not saying the solution should be MSS rewriting - I don't think it should > be. But if you're a 6rd CPE and you know your MTU to the Internet is 1480, > then giving the host an MTU of 1480 in the RA would improve TCP latency. +1 I second Lorenzo on this (no MSS req, PMTUD often doesn't work or is slow) MSS is messy and PMTUD doesn't work in many cases (by experience for 6RD). The only workable solution in the short term IMHO is reducing the LAN MTU in the RA. Several CPEs already do it, with success (the number of MTU issues is reduced to almost 0). /JF --=_alternative 0045592085257A00_= Content-Type: text/html; charset="US-ASCII"
>> +1, PMTUD it should be!! No MSS.  
> I'm not saying the solution should be MSS rewriting - I don't think it should
> be. But if you're a 6rd CPE and you know your MTU to the Internet is 1480,
> then giving the host an MTU of 1480 in the RA would improve TCP latency.

+1
I second Lorenzo on this (no MSS req, PMTUD often doesn't work or is slow)

MSS is messy and PMTUD doesn't work in many cases (by experience for 6RD).
The only workable solution in the short term IMHO is reducing the LAN MTU
in the RA. Several CPEs already do it, with success (the number of MTU
issues is reduced to almost 0).

/JF

--=_alternative 0045592085257A00_=-- From twinters@iol.unh.edu Wed May 16 08:51:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF2821F855F for ; Wed, 16 May 2012 08:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6KoeaGsPkCD for ; Wed, 16 May 2012 08:51:23 -0700 (PDT) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with SMTP id E4EF021F8557 for ; Wed, 16 May 2012 08:51:22 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKT7PM+nZVOsXvwxbCY1dmIlw0d+HmLJq/@postini.com; Wed, 16 May 2012 08:51:23 PDT Received: from mpls-dhcp-07.iol.unh.edu (mpls-dhcp-07.iol.unh.edu [132.177.118.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id EC4908F0079 for ; Wed, 16 May 2012 11:51:21 -0400 (EDT) From: Timothy Winters Content-Type: multipart/alternative; boundary="Apple-Mail=_C93AE17C-6D0B-4CA1-8E6C-DA0CA166C69C" Date: Wed, 16 May 2012 11:51:22 -0400 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 15:51:26 -0000 --Apple-Mail=_C93AE17C-6D0B-4CA1-8E6C-DA0CA166C69C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, 6204bis has a requirement (L-3) that an IPv6 CE Router use the = Route Information Option (RIO) for delegated prefixes. The RIO option = contains a lifetime field for the prefix, which should be populated with = either the preferred or valid lifetime from a DHCP IA_PD option. Using = the valid lifetime from the PD for the life in the RIO makes sense as = 4191 states the following for the route lifetime:=20 The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination.=20 The problem I'm currently seeing with this approach is L-14=20 "The IPv6 CE router MUST send an ICMPv6 Destination Unreachable message, code 5 (Source address failed ingress/egress policy) for packets forwarded to it that use an address from a prefix that has been deprecated." If the valid lifetime is used in the RIO, the host can attempt = to route a deprecated prefix to a CE Router only to have the router = respond with a ICMPv6 Error message. It may make more sense to use the = preferred lifetime as the value for the lifetime field in the RIO = option.=20 What do others think about using the preferred lifetime to = populate the RIO lifetime? Regards, Tim --Apple-Mail=_C93AE17C-6D0B-4CA1-8E6C-DA0CA166C69C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = 6204bis has a requirement (L-3) that an IPv6 CE Router use the = Route Information Option (RIO) for delegated prefixes.   The RIO = option contains a lifetime field for the prefix, which should be = populated with either the preferred or valid lifetime from a DHCP IA_PD = option.  Using the valid lifetime from the PD for the life in the = RIO makes sense as 4191 states the following for the route = lifetime: 
The length of time in seconds
(relative to the time the packet is sent) that the = prefix
      is valid for route determination. =

The problem I'm currently seeing = with this approach is L-14 
= "The IPv6 CE router MUST send an ICMPv6 Destination = Unreachable
          message, code 5 =
(Source address failed ingress/egress policy)
          for packets forwarded to it that use an address from a prefix
          that has been =
deprecated."

If the = valid lifetime is used in the RIO, the host can attempt to route a = deprecated prefix to a CE Router only to have the router respond with a = ICMPv6 Error message.   It may make more sense to use the preferred = lifetime as the value for the lifetime field in the RIO = option. 

What do others think about using = the preferred lifetime to populate the RIO = lifetime?

Regards,
Tim

= --Apple-Mail=_C93AE17C-6D0B-4CA1-8E6C-DA0CA166C69C-- From Fred.L.Templin@boeing.com Wed May 16 08:52:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFC621F84A0 for ; Wed, 16 May 2012 08:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3drjpYfxUKS9 for ; Wed, 16 May 2012 08:52:34 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6C37421F8473 for ; Wed, 16 May 2012 08:52:33 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4GFqWQ2023820 for ; Wed, 16 May 2012 10:52:32 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4GFqWBp023811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 May 2012 10:52:32 -0500 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4GFqWfL014247 for ; Wed, 16 May 2012 10:52:32 -0500 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4GFqVaf014226 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 16 May 2012 10:52:31 -0500 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; Wed, 16 May 2012 08:52:31 -0700 From: "Templin, Fred L" To: IPv6 Operations Date: Wed, 16 May 2012 08:52:30 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0zYLW4U3k2sFOuQiCcyryfe/FvsQAGoi3w Message-ID: 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 X-TM-AS-MML: No Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 15:52:36 -0000 Hi, I think we should get something clear here. PMTUD for IPv6 *works*. Were that not to be the case, then we are stuck with 1500 or smaller MTUs *forever*. 6rd is just one IPv6 hop in the path, and must support IPv6 PMTUD the same as for any IPv6 hop. In its current form, 6rd has difficulty with any MTU setting greater than 1480, and may even have problems at that level. So, PMTUD for 6rd should be fixed, which is exactly what my proposal does. Thanks - Fred fred.l.templin@boeing.com=20 From Fred.L.Templin@boeing.com Wed May 16 09:18:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F4D21F86AB for ; Wed, 16 May 2012 09:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlyvaGd8Lf-6 for ; Wed, 16 May 2012 09:18:01 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE1A21F86A8 for ; Wed, 16 May 2012 09:18:01 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4GGI1Nv001308 for ; Wed, 16 May 2012 09:18:01 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4GGI04n001297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 May 2012 09:18:00 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4GGI0Zs027086 for ; Wed, 16 May 2012 09:18:00 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4GGHxvc027060 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 16 May 2012 09:18:00 -0700 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; Wed, 16 May 2012 09:17:59 -0700 From: "Templin, Fred L" To: IPv6 Operations Date: Wed, 16 May 2012 09:17:58 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0zYLW4U3k2sFOuQiCcyryfe/FvsQAGoi3wAAD4eVA= Message-ID: 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 X-TM-AS-MML: No Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 16:18:05 -0000 Forgot to say, there is also RFC4821. So, even if there are doubts about IPv6 PMTUD the hosts still have recourse to police the PMTU themselves. But again, that is an IPv6 *path* consideration and not a 6rd consideration. Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Wednesday, May 16, 2012 8:53 AM > To: IPv6 Operations > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > Hi, >=20 > I think we should get something clear here. PMTUD for > IPv6 *works*. Were that not to be the case, then we > are stuck with 1500 or smaller MTUs *forever*. >=20 > 6rd is just one IPv6 hop in the path, and must support > IPv6 PMTUD the same as for any IPv6 hop. In its current > form, 6rd has difficulty with any MTU setting greater > than 1480, and may even have problems at that level. > So, PMTUD for 6rd should be fixed, which is exactly > what my proposal does. >=20 > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Wed May 16 09:46:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DAD21F865D for ; Wed, 16 May 2012 09:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1zZvAv5VAmG for ; Wed, 16 May 2012 09:46:36 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id CD54A21F84DD for ; Wed, 16 May 2012 09:46:36 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4GGkVhs018818 for ; Wed, 16 May 2012 09:46:31 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4GGkVXl018810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 May 2012 09:46:31 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4GGkVWD026854 for ; Wed, 16 May 2012 09:46:31 -0700 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4GGkU1f026813 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 16 May 2012 09:46:30 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Wed, 16 May 2012 09:46:30 -0700 From: "Templin, Fred L" To: "Templin, Fred L" , IPv6 Operations Date: Wed, 16 May 2012 09:46:28 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0zYLW4U3k2sFOuQiCcyryfe/FvsQAGoi3wAAD4eVAAAQl4oA== Message-ID: 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 X-TM-AS-MML: No Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 16:46:37 -0000 Forgot also to say that RFC4821 takes care of the RTT issue, since the data is delivered w/o a RTT delay even if there is an MTU restriction on the path. Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Wednesday, May 16, 2012 9:18 AM > To: IPv6 Operations > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > Forgot to say, there is also RFC4821. So, even if there > are doubts about IPv6 PMTUD the hosts still have recourse > to police the PMTU themselves. But again, that is an IPv6 > *path* consideration and not a 6rd consideration. >=20 > Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > > Templin, Fred L > > Sent: Wednesday, May 16, 2012 8:53 AM > > To: IPv6 Operations > > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis > > > > Hi, > > > > I think we should get something clear here. PMTUD for > > IPv6 *works*. Were that not to be the case, then we > > are stuck with 1500 or smaller MTUs *forever*. > > > > 6rd is just one IPv6 hop in the path, and must support > > IPv6 PMTUD the same as for any IPv6 hop. In its current > > form, 6rd has difficulty with any MTU setting greater > > than 1480, and may even have problems at that level. > > So, PMTUD for 6rd should be fixed, which is exactly > > what my proposal does. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sarikaya2012@gmail.com Wed May 16 12:54:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412D021F8575 for ; Wed, 16 May 2012 12:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fvepK3G73JT for ; Wed, 16 May 2012 12:54:01 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A30B521F85A1 for ; Wed, 16 May 2012 12:54:01 -0700 (PDT) Received: by yhq56 with SMTP id 56so1358744yhq.31 for ; Wed, 16 May 2012 12:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Mlthm5+AKhUA1Kpsi5AjA+GnAv10/11CN2su+EPRnQA=; b=qKNqxLnKT07sqpDM/Jz3nB2zokMUgrRHZmRZOJWeVWW44PctnH+SYbt3XmHNYMutsC vM1AjNMNQqZMINuW09vyuOQcmIqnxfNgX9veETPrw/wJzoa9/eyMC59s41CGKtKgTeqX odVVjGrOYjTBdZ24N6vLAMyvqtK9IHIoN3buneHSPk6H2v0Ar3vuJdtwF+7j7hw00E8H pWRVNFFvYyVuCOlzTE1qoXWsz4fj/UHQQMTwVVZstCi0tNht887gcVBXWrxSb29FMxbG Bldfy0DZ0HQlFlsVX+P7L00Sbmze94WB9QcaPPTE7YIKn/8hfHIkSRMDIsJ9lJ1heFry aiiQ== MIME-Version: 1.0 Received: by 10.42.130.7 with SMTP id t7mr2752467ics.43.1337198041007; Wed, 16 May 2012 12:54:01 -0700 (PDT) Received: by 10.231.78.10 with HTTP; Wed, 16 May 2012 12:54:00 -0700 (PDT) In-Reply-To: <52EFFB80-9AE5-41CF-8F27-8598C8EFB0EC@gmail.com> References: <4FB10D4B.60009@globis.net> <52EFFB80-9AE5-41CF-8F27-8598C8EFB0EC@gmail.com> Date: Wed, 16 May 2012 14:54:00 -0500 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat 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, 16 May 2012 19:54:02 -0000 On Wed, May 16, 2012 at 5:59 AM, jouni korhonen wr= ote: > > Hi, > > I got few comments on the draft -03.. mainly editorial. > > o Sections 3. and 6.2. first paragraphs could add a reference to [RFC6459= ], > =A0since it is already in the references section but never used in the ma= in > =A0text. My proposals: > > =A0Section 3: > =A0 =A0 =A0 ... > =A0 =A0 =A0 translation. =A0This is especially cost-effective in wireless= 3GPP > =A0 =A0 =A0 GSM and UMTS networks that would otherwise require two separa= te > =A0 =A0 =A0 PDP connections to support IPv4 and IPv6 [RFC6459]. > > =A0Section 6.2: > =A0 The vast majority of mobile wireless networks are compliant to Pre- > =A0 Release 9 3GPP standards. =A0In Pre-Release 9 3GPP networks, GSM and > =A0 UMTS networks must signal and support both IPv4 and IPv6 PDP > =A0 attachments to access IPv4 and IPv6 network destinations [RFC6459]. > =A0 ... > > o Section 3 could add a reference to TS23.203 for PCC. > > o Section 6.2 could also mention that each PDP connection also > =A0equals to a RAB, which is indeed costly when it comes to support > =A0for parallel context over the radio. > > o Section 7.5 talks about the case where there is no dedicated > =A0translation prefix. I would not say "will do NAT44.." there, > =A0rather "can do NAT44.." This is imho an implementation choice, > =A0for example, inside the UE that has to serve only a single IPv4 > =A0address. > > o Same as above for Section 7.6 > > o Section 7.5 or Section 6.2 could state for 3G case that when DHCPv6-PD > =A0is not available opening a second IPv6 PDP Connection for obtaining a > =A0dedicated translation prefix is not recommended. > Rather stick with a > =A0single prefix model.. Why? Because of PD-exclude? I don't see any reason for this restriction. We discussed single prefix issue with Maglione Roberta. There is nothing like "single prefix is required". Behcet From ichiroumakino@gmail.com Wed May 16 13:06:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DDA21F8665 for ; Wed, 16 May 2012 13:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjs3Co26q1hn for ; Wed, 16 May 2012 13:06:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C260E21F865B for ; Wed, 16 May 2012 13:06:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so932676lbb.31 for ; Wed, 16 May 2012 13:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=LJstfZA2Cs8rLAefTu5gDexUjzxPjmz3IBF7N52keu4=; b=Oily2/wrv0KcKGl3dGD7JM5dYf+fTwTTF++1vBmidcHwn499Xbn2wmKS3+B4ZdWaN6 Lf+WDo3SrHdWQ1oPx1VDmVgsHif1l8Jpkrl0A77sKbPjcpkUhbA16zOfo+hv8tKIgFix q7fUDheUOUyCbydD+Qx1P8tadLwGlQKymjSwElXJLm2zTxMNuZCl7EabjsDPrQPS2Ydl m1fuL9GB4wDo55i8Xh5LaPEE5jPZk0UHBA/TImHNtpMFmYCBhE3ynOo2zRzMOBfDVsjj CIIKSREdatrzv3PecQZb9qHDkZyiz2ExkJT5tn1PFrGRPOFnDDRk3RwlBAPUXvoastXZ SMBw== Received: by 10.152.105.173 with SMTP id gn13mr4345584lab.20.1337198787594; Wed, 16 May 2012 13:06:27 -0700 (PDT) Received: from gomlefisk.lan ([84.48.213.97]) by mx.google.com with ESMTPS id s3sm4085390lbk.11.2012.05.16.13.06.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 13:06:26 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 16 May 2012 22:06:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <282966ED-7083-43B8-AB46-222E85EE75A7@employees.org> References: To: Timothy Winters X-Mailer: Apple Mail (2.1278) Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 20:06:30 -0000 Tim, > 6204bis has a requirement (L-3) that an IPv6 CE Router use the = Route Information Option (RIO) for delegated prefixes. The RIO option = contains a lifetime field for the prefix, which should be populated with = either the preferred or valid lifetime from a DHCP IA_PD option. Using = the valid lifetime from the PD for the life in the RIO makes sense as = 4191 states the following for the route lifetime:=20 > The length of time in seconds > (relative to the time the packet is sent) that the prefix > is valid for route determination.=20 >=20 > The problem I'm currently seeing with this approach is L-14=20 > "The IPv6 CE router MUST send an ICMPv6 Destination Unreachable > message, code 5 (Source address failed ingress/egress = policy) > for packets forwarded to it that use an address from a = prefix > that has been deprecated." >=20 >=20 > If the valid lifetime is used in the RIO, the host can attempt = to route a deprecated prefix to a CE Router only to have the router = respond with a ICMPv6 Error message. It may make more sense to use the = preferred lifetime as the value for the lifetime field in the RIO = option.=20 >=20 > What do others think about using the preferred lifetime to = populate the RIO lifetime? the intention of L-14 was only for the router to send unreachable = messages after the prefix was invalid. the use of "deprecated" isn't = good, given that has a special meaning in 4861. I suggest 6204bis = replaces "deprecated" with "invalidated". would that resolve the ambiguity? cheers, Ole= From twinters@iol.unh.edu Wed May 16 13:23:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F721F8666 for ; Wed, 16 May 2012 13:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 003WxCMYp8LV for ; Wed, 16 May 2012 13:23:14 -0700 (PDT) Received: from exprod5og109.obsmtp.com (exprod5og109.obsmtp.com [64.18.0.188]) by ietfa.amsl.com (Postfix) with SMTP id 0EA6A21F865A for ; Wed, 16 May 2012 13:23:13 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob109.postini.com ([64.18.4.12]) with SMTP ID DSNKT7QMsRz1snxo8oQqljJwhDvBCopCfM+m@postini.com; Wed, 16 May 2012 13:23:14 PDT Received: from mpls-dhcp-07.iol.unh.edu (mpls-dhcp-07.iol.unh.edu [132.177.118.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 5E5EC8F0079; Wed, 16 May 2012 16:23:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Timothy Winters In-Reply-To: <282966ED-7083-43B8-AB46-222E85EE75A7@employees.org> Date: Wed, 16 May 2012 16:23:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7DE9685D-64B3-4201-B6AC-D1CBEE3767B6@iol.unh.edu> References: <282966ED-7083-43B8-AB46-222E85EE75A7@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1278) Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 20:23:15 -0000 Hi Ole, It would but my main concern in this case would be for how long = does the CE Router transmit the ICMP Unreachable message for a prefix = that isn't valid? =20 Otherwise they will have to transmit ICMP Unreachable messages = for all unrecognized addresses which seems like overkill. For some reason, I thought the purpose of L-14 was to help flash = renumbering, in that a CE Router would tell a host immediately the = address was no longer useful instead of having to wait the two hours. = If not what is the purpose of generating the error message instead of = just implementing BCP 38 [RFC 2827] and allowing the device to drop the = packet silently? =20 Regards, Tim On May 16, 2012, at 4:06 PM, Ole Tr=F8an wrote: > Tim, >=20 >> 6204bis has a requirement (L-3) that an IPv6 CE Router use the = Route Information Option (RIO) for delegated prefixes. The RIO option = contains a lifetime field for the prefix, which should be populated with = either the preferred or valid lifetime from a DHCP IA_PD option. Using = the valid lifetime from the PD for the life in the RIO makes sense as = 4191 states the following for the route lifetime:=20 >> The length of time in seconds >> (relative to the time the packet is sent) that the prefix >> is valid for route determination.=20 >>=20 >> The problem I'm currently seeing with this approach is L-14=20 >> "The IPv6 CE router MUST send an ICMPv6 Destination Unreachable >> message, code 5 (Source address failed ingress/egress = policy) >> for packets forwarded to it that use an address from a = prefix >> that has been deprecated." >>=20 >>=20 >> If the valid lifetime is used in the RIO, the host can attempt = to route a deprecated prefix to a CE Router only to have the router = respond with a ICMPv6 Error message. It may make more sense to use the = preferred lifetime as the value for the lifetime field in the RIO = option.=20 >>=20 >> What do others think about using the preferred lifetime to = populate the RIO lifetime? >=20 > the intention of L-14 was only for the router to send unreachable = messages after the prefix was invalid. the use of "deprecated" isn't = good, given that has a special meaning in 4861. I suggest 6204bis = replaces "deprecated" with "invalidated". >=20 > would that resolve the ambiguity? >=20 > cheers, > Ole From warren@kumari.net Wed May 16 13:39:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D054D21F86B7 for ; Wed, 16 May 2012 13:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.831 X-Spam-Level: X-Spam-Status: No, score=-105.831 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccmSyoZBvnji for ; Wed, 16 May 2012 13:39:15 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC1021F86B0 for ; Wed, 16 May 2012 13:39:15 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 8B5CD1B402F1; Wed, 16 May 2012 16:39:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Wed, 16 May 2012 16:39:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <25527DA4-E326-4E8C-9AB8-EF73A3E7E620@kumari.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <4ED0951D-E320-4982-892B-F541DB923A39@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1257) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 20:39:15 -0000 On May 16, 2012, at 3:36 AM, Lorenzo Colitti wrote: > On Wed, May 16, 2012 at 4:25 PM, R=E9mi Despr=E9s = wrote: > - Or is it because such prevention uses some inter-layer cooperation = (very limited but real)? >=20 > I think what he said is: >=20 > - It's superfluous > - It's a layering violation > - The IETF should not endorse it by making it optional >=20 > I would like to add that superfluous -> slow. And I'll add another -- it's a truly horrendously ugly kludge. Intermediate devices monkeying with my packet -- do not want=85. W P.S: Also, while I'm on my soapbox: This thread becoming RTF again -- do = not want... > __________________________________ > _____________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From volz@cisco.com Wed May 16 13:47:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA24B21F875C for ; Wed, 16 May 2012 13:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.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_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jyKrivs1tX4 for ; Wed, 16 May 2012 13:47:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9C321F8758 for ; Wed, 16 May 2012 13:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=3798; q=dns/txt; s=iport; t=1337201232; x=1338410832; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VlR+sfC3HOBJvCLMopQDUMP90Qc5nLjVc73YWabpQYg=; b=BGXkZuspPy4BqZpP3BSWmzIhmHNrYvYoNbOKE1jCuL64iyaaLN959FKy YbUfSpw+LWSpUPlqIgl2oMU5Rs3OgnAVmwj9q9UlcNElIH4CK0wWOYO0M H24akWmeBjlG/Zs5gTHhszMrvk44Eav+hnRKRnXxSjb8iUxHa5oEdrwUi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO4RtE+tJXG8/2dsb2JhbABEDrN8gQeCFQEBAQMBAQEBDwEdPgsFBwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggRCYdnBQubSqAEBIsThHViA4gvNJtugWmCMFc X-IronPort-AV: E=Sophos;i="4.75,604,1330905600"; d="scan'208";a="83905551" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 16 May 2012 20:47:00 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4GKl0kl024746; Wed, 16 May 2012 20:47:00 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 15:47:00 -0500 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-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 May 2012 15:46:59 -0500 Message-ID: In-Reply-To: <7DE9685D-64B3-4201-B6AC-D1CBEE3767B6@iol.unh.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Route Information Option Lifetime Thread-Index: Ac0zob4uNTW/1CFwRyeHx3fCvDaFyQAAoHYg References: <282966ED-7083-43B8-AB46-222E85EE75A7@employees.org> <7DE9685D-64B3-4201-B6AC-D1CBEE3767B6@iol.unh.edu> From: "Bernie Volz (volz)" To: "Timothy Winters" , =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 16 May 2012 20:47:00.0671 (UTC) FILETIME=[0AC1DCF0:01CD33A5] Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 20:47:13 -0000 As clocks run at different speeds, I would think that there would be = some (short) period beyond the expiration of the valid-lifetime a router = would hold onto the route in case the devices' clocks were running = slower than the router's. This is very similar to what DHCP server do - they have a grace period = (it often is configurable and can be set to 0). After a lease expires, = the server doesn't reuse the lease for a different client until the = grace period elapses just in case the client's clock ran slower. That does mean the document likely needs to suggest a value for this = grace period, or at least provide some discussion of what values might = be reasonable. (While a fixed number is easy to implement, a percentage = is likely more correct as clock drift is probably related to the = duration of the drift.) Note that ideally the CPE router and DHCP server (if their clocks ran at = the same rate) would use the same value. - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Timothy Winters Sent: Wednesday, May 16, 2012 4:23 PM To: Ole Tr=F8an Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime Hi Ole, It would but my main concern in this case would be for how long does = the CE Router transmit the ICMP Unreachable message for a prefix that = isn't valid? =20 Otherwise they will have to transmit ICMP Unreachable messages for all = unrecognized addresses which seems like overkill. For some reason, I thought the purpose of L-14 was to help flash = renumbering, in that a CE Router would tell a host immediately the = address was no longer useful instead of having to wait the two hours. = If not what is the purpose of generating the error message instead of = just implementing BCP 38 [RFC 2827] and allowing the device to drop the = packet silently? =20 Regards, Tim On May 16, 2012, at 4:06 PM, Ole Tr=F8an wrote: > Tim, >=20 >> 6204bis has a requirement (L-3) that an IPv6 CE Router use the Route = Information Option (RIO) for delegated prefixes. The RIO option = contains a lifetime field for the prefix, which should be populated with = either the preferred or valid lifetime from a DHCP IA_PD option. Using = the valid lifetime from the PD for the life in the RIO makes sense as = 4191 states the following for the route lifetime:=20 >> The length of time in seconds >> (relative to the time the packet is sent) that the prefix >> is valid for route determination.=20 >>=20 >> The problem I'm currently seeing with this approach is L-14=20 >> "The IPv6 CE router MUST send an ICMPv6 Destination Unreachable >> message, code 5 (Source address failed ingress/egress = policy) >> for packets forwarded to it that use an address from a = prefix >> that has been deprecated." >>=20 >>=20 >> If the valid lifetime is used in the RIO, the host can attempt to = route a deprecated prefix to a CE Router only to have the router respond = with a ICMPv6 Error message. It may make more sense to use the = preferred lifetime as the value for the lifetime field in the RIO = option.=20 >>=20 >> What do others think about using the preferred lifetime to populate = the RIO lifetime? >=20 > the intention of L-14 was only for the router to send unreachable = messages after the prefix was invalid. the use of "deprecated" isn't = good, given that has a special meaning in 4861. I suggest 6204bis = replaces "deprecated" with "invalidated". >=20 > would that resolve the ambiguity? >=20 > cheers, > Ole _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Wed May 16 13:54:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E0321F86BE for ; Wed, 16 May 2012 13:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhwpvf60JiEO for ; Wed, 16 May 2012 13:54:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BFFCE21F861C for ; Wed, 16 May 2012 13:54:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SUlEt-000IGu-PW; Wed, 16 May 2012 20:54:32 +0000 Date: Wed, 16 May 2012 10:54:31 -1000 Message-ID: From: Randy Bush To: Wuyts Carl In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 20:54:33 -0000 > +1, PMTUD it should be! and cash should fall from the sky let me reposition the issue whether we like it or not, many of these hacks, and hacks they are, will break. pmtud would be lovely, but no prudent op can bet on it. therefore, we need to give o warning(s) o some guidance in what document(s) and how are those best done? randy From jouni.nospam@gmail.com Wed May 16 14:38:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A325221F875E for ; Wed, 16 May 2012 14:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WwWDHMmVP5j for ; Wed, 16 May 2012 14:38:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBD5521F8755 for ; Wed, 16 May 2012 14:38:46 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so993768lbb.31 for ; Wed, 16 May 2012 14:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=criJyAnR8dr58GTqO2+YPr0nK6MSf43giRav5pEOcQI=; b=pKuFEh0JcW5W5AG52jAt8sAX3ubxpyGeMl3nOZDDa8XCLAptLT7jewz4fs4KuM1FeG 4Di8rU+daPDggdoOldKe1N6wW7bF/4IgaumcS6qi8e+EM0xuCf5rt08v6KVWLQ80erKT 26LFT4IRTHelUpS1WcPs/VXAeB5vkZjfiJ9uzarA/EJWTo78/LXU1sKk/0FAhkAUMl4O t85hwAMpumQC/L0KiH/+CkVDsyROJtCIC+iNKkPZN+mzFlw7lQjWFMbnvyzIaLBEQmNO MTSOiyk6fzG6xccLFxZn0uXEKT2qnSBXFbWfcRF/bZ4jYn/kmEWRoekvJ+miSWlI34jI j9Mg== Received: by 10.152.105.173 with SMTP id gn13mr4600730lab.20.1337204325546; Wed, 16 May 2012 14:38:45 -0700 (PDT) Received: from a88-114-71-183.elisa-laajakaista.fi (a88-114-71-183.elisa-laajakaista.fi. [88.114.71.183]) by mx.google.com with ESMTPS id j3sm4225897lbh.0.2012.05.16.14.38.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 14:38:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 17 May 2012 00:38:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <84F658CA-DD1B-4A7A-B2A8-652C4D048A41@gmail.com> References: <4FB10D4B.60009@globis.net> <52EFFB80-9AE5-41CF-8F27-8598C8EFB0EC@gmail.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 21:38:47 -0000 On May 16, 2012, at 10:54 PM, Behcet Sarikaya wrote: > On Wed, May 16, 2012 at 5:59 AM, jouni korhonen = wrote: >>=20 >> Hi, >>=20 >> I got few comments on the draft -03.. mainly editorial. >>=20 >> o Sections 3. and 6.2. first paragraphs could add a reference to = [RFC6459], >> since it is already in the references section but never used in the = main >> text. My proposals: >>=20 >> Section 3: >> ... >> translation. This is especially cost-effective in wireless = 3GPP >> GSM and UMTS networks that would otherwise require two separate >> PDP connections to support IPv4 and IPv6 [RFC6459]. >>=20 >> Section 6.2: >> The vast majority of mobile wireless networks are compliant to Pre- >> Release 9 3GPP standards. In Pre-Release 9 3GPP networks, GSM and >> UMTS networks must signal and support both IPv4 and IPv6 PDP >> attachments to access IPv4 and IPv6 network destinations [RFC6459]. >> ... >>=20 >> o Section 3 could add a reference to TS23.203 for PCC. >>=20 >> o Section 6.2 could also mention that each PDP connection also >> equals to a RAB, which is indeed costly when it comes to support >> for parallel context over the radio. >>=20 >> o Section 7.5 talks about the case where there is no dedicated >> translation prefix. I would not say "will do NAT44.." there, >> rather "can do NAT44.." This is imho an implementation choice, >> for example, inside the UE that has to serve only a single IPv4 >> address. >>=20 >> o Same as above for Section 7.6 >>=20 >> o Section 7.5 or Section 6.2 could state for 3G case that when = DHCPv6-PD >> is not available opening a second IPv6 PDP Connection for obtaining = a >> dedicated translation prefix is not recommended. >=20 >> Rather stick with a >> single prefix model.. >=20 > Why? >=20 > Because of PD-exclude? Read above "..when DHCPv6-PD is not available.." >=20 > I don't see any reason for this restriction. Recommendation !=3D restriction. One reasoning for a recommendations was given above. Opening parallel contexts, even if they all are IPv6 only consume resources (including stuff like licenses, per UE radio scheduler slots etc.) That can be (and for quite a few folks is) an issue to take into account. - Jouni > We discussed single prefix issue with Maglione Roberta. > There is nothing like "single prefix is required". >=20 > Behcet From ichiroumakino@gmail.com Wed May 16 14:55:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DBC21F87DB for ; Wed, 16 May 2012 14:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.113 X-Spam-Level: X-Spam-Status: No, score=-3.113 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT9wxsv+U1IT for ; Wed, 16 May 2012 14:55:12 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4A92321F87DA for ; Wed, 16 May 2012 14:55:11 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so5798119wgb.1 for ; Wed, 16 May 2012 14:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tsVgBdHOzsAxbNiOiAJMl2WNkbDNlkmwQ7cvsOitcKE=; b=rCVDSSWoKtszbcTFliV1D78ftJdK94wbLTrfvKHT6j7Xy4fvOnZ4v3YSQGxQZXF0+f AILcHHkGiddh+D+0UJJJnNjXWoMLz35RdKXze9psbIqqdFaX7XMfkM8iiDLJ0zkHu/Al YLSxdWX1qiS0zEo86NrFfsF9EieyqHs3KnwU/twI1Yt8FDBk34h6v3Xfjha0ooI1FVDn gkfqruhpODs0CsCf+luchFo/UX2MY8b4W1OVpNuk7Zx14wtvV6kMTa4eUtsuCcX75d5h Rkn2RDSNqbv2ss2KkQoL5ajHh/7Dawx2OnM8WH0TqXnpLrFPw6c+k31hZIs07N4XHF7g bWww== Received: by 10.180.78.164 with SMTP id c4mr44255844wix.10.1337205310419; Wed, 16 May 2012 14:55:10 -0700 (PDT) Received: from dhcp-10-61-97-154.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id g10sm43538712wiw.0.2012.05.16.14.55.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 14:55:09 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 16 May 2012 23:55:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Timothy Winters X-Mailer: Apple Mail (2.1278) Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 21:55:13 -0000 Tim, > 6204bis has a requirement (L-3) that an IPv6 CE Router use the = Route Information Option (RIO) for delegated prefixes. The RIO option = contains a lifetime field for the prefix, which should be populated with = either the preferred or valid lifetime from a DHCP IA_PD option. Using = the valid lifetime from the PD for the life in the RIO makes sense as = 4191 states the following for the route lifetime:=20 > The length of time in seconds > (relative to the time the packet is sent) that the prefix > is valid for route determination.=20 >=20 > The problem I'm currently seeing with this approach is L-14=20 > "The IPv6 CE router MUST send an ICMPv6 Destination Unreachable > message, code 5 (Source address failed ingress/egress = policy) > for packets forwarded to it that use an address from a = prefix > that has been deprecated." >=20 >=20 > If the valid lifetime is used in the RIO, the host can attempt = to route a deprecated prefix to a CE Router only to have the router = respond with a ICMPv6 Error message. It may make more sense to use the = preferred lifetime as the value for the lifetime field in the RIO = option.=20 >=20 > What do others think about using the preferred lifetime to = populate the RIO lifetime? a retake after thinking about this some more. L-14 is there to catch the case where a prefix has been invalidated or = is unknown. the purpose is to inform the host that this address is now = invalid. forwarding of packets for deprecated prefixes is perfectly = fine, that may be part of normal renumbering. which is why I think L-14 = needs clarification. the lifetime to use for the RIO option is somewhat correlated to the = lifetimes in the prefix, in that it doesn't make sense to claim to be a = router for a prefix that it has no guarantee it owns after the PD valid = lifetime has expired. I would suggest the RIO route lifetime to be the = smaller of the default router lifetime and the valid lifetime. if there is flash renumbering, there might be 'residual' connections = still happening that will follow that route, the RIO route is only used = to reach another part of the home network, and that could be made to = work if the CE kept the more specific PD routes around. if not, then the = host will get an ICMP back. I don't see how changing the RIO route life = time for the PD prefix would matter. cheers, Ole From shemant@cisco.com Wed May 16 15:08:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B0721F8622 for ; Wed, 16 May 2012 15:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.319 X-Spam-Level: X-Spam-Status: No, score=-10.319 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znARP4MZNBoD for ; Wed, 16 May 2012 15:08:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2721F8627 for ; Wed, 16 May 2012 15:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4883; q=dns/txt; s=iport; t=1337206082; x=1338415682; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=orO6Xmcle9Wevx2FfM7ctQeLujW15aYIlAjJCDBuWoU=; b=Z73ainya/eaNyEbu1nf1hNR2ZwMqOw/vNHCoKNeZoCdkfKksriz5MZGD hIL3+qKTQscgj7Anj4/AwXm3SdTtpU3fBBNzjaEs3MUI4vFzkPwb6dJxQ cy7zyQRqpkl6Bb5VRhshLcRhoMMLNbsP9nhXu66SbHC2mAqnJc9cmZcge Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADEktE+tJV2c/2dsb2JhbABEDoI3sUaBB4IVAQEBBBIBCREDSQwEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHbJthoAKLE4R1YgOILzSbboFpgjBX X-IronPort-AV: E=Sophos;i="4.75,604,1330905600"; d="scan'208,217";a="83885448" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 16 May 2012 22:08:02 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q4GM824O026698; Wed, 16 May 2012 22:08:02 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 17:08:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD33B0.5C2C254C" Date: Wed, 16 May 2012 17:08:01 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CFB2@XMB-RCD-109.cisco.com> In-Reply-To: <282966ED-7083-43B8-AB46-222E85EE75A7@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Route Information Option Lifetime Thread-Index: Ac0zn2f8R9RrZRerQZOvSCem5aM5gwADpyQA References: <282966ED-7083-43B8-AB46-222E85EE75A7@employees.org> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Timothy Winters" X-OriginalArrivalTime: 16 May 2012 22:08:02.0296 (UTC) FILETIME=[5C82F780:01CD33B0] Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 22:08:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD33B0.5C2C254C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Wednesday, May 16, 2012 4:06 PM To: Timothy Winters Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime =20 >the intention of L-14 was only for the router to send unreachable = messages after the prefix was invalid. the use of "deprecated" isn't = >good, given that has a special meaning in 4861. I suggest 6204bis = replaces "deprecated" with "invalidated". =20 RFC 4862 defines the lifetimes and the behavior. See the first = paragraph of section 5.5.4 of RFC 4862. I agree the deprecated needs to = change to invalidated in L-14. =20 =20 Hemant ------_=_NextPart_001_01CD33B0.5C2C254C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Ole Tr=F8an
Sent: = Wednesday, May 16, 2012 4:06 PM
To: Timothy Winters
Cc: IPv6 = Operations
Subject: Re: [v6ops] Route Information Option = Lifetime

 

>the = intention of L-14 was only for the router to send unreachable messages = after the prefix was invalid. the use of "deprecated" isn't = >good, given that has a special meaning in 4861. I suggest 6204bis = replaces "deprecated" with = "invalidated".

 

RFC 4862 defines the = lifetimes and the behavior.=A0 See the first paragraph of section 5.5.4 = of RFC 4862. =A0I agree the deprecated needs to change to invalidated in = L-14.=A0

 

Hemant

------_=_NextPart_001_01CD33B0.5C2C254C-- From shemant@cisco.com Wed May 16 15:58:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4F011E8072 for ; Wed, 16 May 2012 15:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.319 X-Spam-Level: X-Spam-Status: No, score=-10.319 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBkvqP6vwGbz for ; Wed, 16 May 2012 15:58:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 871D99E8020 for ; Wed, 16 May 2012 15:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7387; q=dns/txt; s=iport; t=1337209083; x=1338418683; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Trx8xolDE85r07M0Uei2gkPW0xnfoLbu5BMZUzjkGjM=; b=g67MPPMJWAWaprn0ilan6kO+FsZFj6mhZKJuay4OcfX2jbFDoKPisDvh MDEiiYpxr4LdWIgWdUGbST0+Q6dl42C/f+kRuuaHF4qTOZP8Idu5ocuP2 YIodmAMq8mg6QwHF6FbLznUbhuknjUKteg31MefFwaHqdLS1edciupjs+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHMwtE+tJXG//2dsb2JhbABEDoI3sUaBB4IVAQEBBBIBCREDSQwEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBEJh2ybXp98ixOEdWIDiC80m26BaYIwVw X-IronPort-AV: E=Sophos;i="4.75,604,1330905600"; d="scan'208,217";a="83935299" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 16 May 2012 22:58:03 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4GMw3qp019628; Wed, 16 May 2012 22:58:03 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 17:58:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: E9a/ FDKg GFWu GuIi H1El Io4x JGKj LTZA Qv3u T2HZ UP5X VOLU XsD3 aVg4 d1rz fZEN; 3; bwB0AHIAbwBhAG4AQABlAG0AcABsAG8AeQBlAGUAcwAuAG8AcgBnADsAdAB3AGkAbgB0AGUAcgBzAEAAaQBvAGwALgB1AG4AaAAuAGUAZAB1ADsAdgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {F5DFAC43-9305-4BCD-9471-373AE41DA385}; cwBoAGUAbQBhAG4AdABAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Wed, 16 May 2012 22:57:55 GMT; UgBFADoAIABbAHYANgBvAHAAcwBdACAAUgBvAHUAdABlACAASQBuAGYAbwByAG0AYQB0AGkAbwBuACAATwBwAHQAaQBvAG4AIABMAGkAZgBlAHQAaQBtAGUA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD33B7.5887BED8" x-cr-puzzleid: {F5DFAC43-9305-4BCD-9471-373AE41DA385} Content-class: urn:content-classes:message Date: Wed, 16 May 2012 17:57:55 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CFD2@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Route Information Option Lifetime Thread-Index: Ac0zrrPYlXfvF7SoSnu4DPfqUeLurAAAay+w References: From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Timothy Winters" X-OriginalArrivalTime: 16 May 2012 22:58:02.0452 (UTC) FILETIME=[58BE7140:01CD33B7] Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 22:58:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD33B7.5887BED8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Wednesday, May 16, 2012 5:55 PM To: Timothy Winters Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime =20 =20 >the lifetime to use for the RIO option is somewhat correlated to the = lifetimes in the prefix, in that it doesn't make sense to claim to be >a = router for a prefix that it has no guarantee it owns after the PD valid = lifetime has expired. I would suggest the RIO route lifetime to >be the = smaller of the default router lifetime and the valid lifetime. =20 Default router lifetime is likely to me the winner in being small most = of the time since RFC 4861 recommends the parameter to be 9000 secs. =20 =20 >if there is flash renumbering, there might be 'residual' connections = still happening that will follow that route, the RIO route is only >used = to reach another part of the home network, and that could be made to = work if the CE kept the more specific PD routes around. if not, >then = the host will get an ICMP back. I don't see how changing the RIO route = life time for the PD prefix would matter. =20 Correct. Specifically the MSR (RFC4191) was added to rfc 6204 to deal = with hosts assigned with a ULA and ipv4 address and the hosts were using = the ULA as source to reach the global Internet since the ULA has global = scope. =20 =20 Hemant ------_=_NextPart_001_01CD33B7.5887BED8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet= f.org] On Behalf Of Ole Tr=F8an

Sent: = Wednesday, May 16, 2012 5:55 PM

To: = Timothy Winters

Cc: IPv6 = Operations

Subject: Re: [v6ops] Route = Information Option Lifetime

 

 

>the = lifetime to use for the RIO option is somewhat correlated to the = lifetimes in the prefix, in that it doesn't make sense to claim to be = >a router for a prefix that it has no guarantee it owns after the PD = valid lifetime has expired. I would suggest the RIO route lifetime to = >be the smaller of the default router lifetime and the valid = lifetime.

 

Default = router lifetime is likely to me the winner in being small most of the = time since RFC 4861 recommends the parameter to be 9000 secs.=A0 =

 

>if = there is flash renumbering, there might be 'residual' connections still = happening that will follow that route, the RIO route is only >used to = reach another part of the home network, and that could be made to work = if the CE kept the more specific PD routes around. if not, >then the = host will get an ICMP back. I don't see how changing the RIO route life = time for the PD prefix would matter.

 

Correct.=A0 Specifically the MSR = (RFC4191) was added to rfc 6204 to deal with hosts assigned with a ULA = and ipv4 address and the hosts were using the ULA as source to reach the = global Internet since the ULA has global scope.=A0 =

 

Hemant

------_=_NextPart_001_01CD33B7.5887BED8-- From shemant@cisco.com Wed May 16 16:26:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50621F86CA for ; Wed, 16 May 2012 16:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyIMfJo+-UkI for ; Wed, 16 May 2012 16:26:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B497F21F86BE for ; Wed, 16 May 2012 16:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7783; q=dns/txt; s=iport; t=1337210762; x=1338420362; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Abd3zJ+1h8lze+W6cBQ8ohJGxTR1j6cdBmVFqOK5IYo=; b=TmkpN81Hm6OJDcYNNzAJV0YYOf06fkJ0U8AgRaEsHvrUYG8/ut9hhINa 4j3wcyUN58vdHHo8GwOSIIebzfd3G5wRgud1f69lZfuVIzcp6cb/9o6g5 0xygevvfY1HK9OiywW3BfO+kE4CG+ugexi9SR7ndzoZ0++YShPOM3dNFU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADQ3tE+tJXG+/2dsb2JhbABEgkWxRoEHghUBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodsm2WfeIsThHViA4hjm26BaYMH X-IronPort-AV: E=Sophos;i="4.75,604,1330905600"; d="scan'208,217";a="83946658" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 16 May 2012 23:26:00 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4GNQ0Iv005219; Wed, 16 May 2012 23:26:00 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 18:25:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD33BB.402B3800" Date: Wed, 16 May 2012 18:25:58 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CFE9@XMB-RCD-109.cisco.com> In-Reply-To: <25527DA4-E326-4E8C-9AB8-EF73A3E7E620@kumari.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0zo/uCBLiPGi6pRd+V37JYV26LtAAE6UZA References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com><301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org><4ED0951D-E320-4982-892B-F541DB923A39@laposte.net> <25527DA4-E326-4E8C-9AB8-EF73A3E7E620@kumari.net> From: "Hemant Singh (shemant)" To: "Warren Kumari" , "Lorenzo Colitti" X-OriginalArrivalTime: 16 May 2012 23:25:59.0795 (UTC) FILETIME=[4084AC30:01CD33BB] Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 23:26:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD33BB.402B3800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Wednesday, May 16, 2012 4:39 PM To: Lorenzo Colitti Cc: v6ops@ietf.org WG Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis =20 >Intermediate devices monkeying with my packet -- do not want.... =20 For over a decade the middlebox edited the TCP MSS for IPv4 and saved one's PPPOE Internet connection from getting dropped. Hmm, which is worse? No Internet connection vs. the wish above. =20 PMTUD is not an option since the protocol uses ICMPv6 that can be blocked in the Internet path. Fred Templin has ideas along the right track but none of those ideas are in a Standards Track RFC that rfc6204bis can reference for a technology. Don't know how many hosts implement RFC 4821 and PLPMTUD. That leaves only two options at the table.=20 =20 (a) The SP knows exactly what MTU to sent in an RA to the CPE WAN. The MTU is the effective MTU for DS-Lite and the MTU can be used in the RA on the CPE LAN segment. Daniel Rosen and Gert dislike the WAN MTU to mess with the LAN MTU - if they can clarify why, that would be helpful. Anyway, 6rd does not have an RA from the SP to the CPE WAN. So the CPE has some internal magic that if the CPE uses 6rd, the CPE uses a certain conservative MTU such as 1280 on the CPE LAN or the CPE has a manual configuration which is not good. If Daniel and Gert find important reasons then (a) is not a good option. Note for DS-Lite the SP has another alternative in that the SP sets the TCP MSS at the AFTR. =20 (b) Use TCP MSS Rewrite in the CPE because there are certain cases (6rd CPE to CPE communication) where the SP cannot set the TCP MSS and hosts in the CPE LAN send packets larger than the protocol MTU used in the Internet connection from the CPE WAN to the SP. Who signals to the hosts to reduce MTU? =20 =20 Hemant =20 ------_=_NextPart_001_01CD33BB.402B3800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Warren Kumari
Sent: Wednesday, May 16, 2012 4:39 PM
To: Lorenzo = Colitti
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] proposed TCP = MSS text for rfc6204bis

 

>Intermediate devices monkeying = with my packet -- do not want….

 

For over a decade the middlebox edited the TCP MSS for = IPv4 and saved one's PPPOE Internet connection from getting = dropped.  Hmm, which is worse?  No Internet connection vs. the = wish above.

 

PMTUD is not an option since the protocol uses ICMPv6 = that can be blocked in the Internet path.  Fred Templin has ideas = along the right track but none of those ideas are in a Standards Track = RFC that rfc6204bis can reference for a technology.  Don't know how = many hosts implement RFC 4821 and PLPMTUD.  That leaves only two = options at the table.

 

(a) The SP knows exactly what MTU to sent in an RA to = the CPE WAN.  The MTU is the effective MTU for DS-Lite and the MTU = can be used in the RA on the CPE LAN segment.  Daniel Rosen and = Gert dislike the WAN MTU to mess with the LAN MTU - if they can clarify = why, that would be helpful.  Anyway, 6rd does not have an RA from = the SP to the CPE WAN.  So the CPE has some internal magic that if = the CPE uses 6rd, the CPE uses a certain conservative MTU such as 1280 = on the CPE LAN or the CPE has a manual configuration which is not = good.  If Daniel and Gert find important reasons then (a) is not a = good option.  Note for DS-Lite the SP has another alternative in = that the SP sets the TCP MSS at the AFTR.

 

(b) Use TCP MSS Rewrite in the CPE because there are = certain cases (6rd CPE to CPE communication) where the SP cannot set the = TCP MSS and hosts in the CPE LAN send packets larger than the protocol = MTU used in the Internet connection from the CPE WAN to the SP.  = Who signals to the hosts to reduce MTU? 

 

Hemant

 

------_=_NextPart_001_01CD33BB.402B3800-- From marka@isc.org Wed May 16 16:39:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C9321F8755 for ; Wed, 16 May 2012 16:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks46cJc+2hUk for ; Wed, 16 May 2012 16:39:05 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5785521F8753 for ; Wed, 16 May 2012 16:39:05 -0700 (PDT) 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 9DB115F98B9; Wed, 16 May 2012 23:38:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4d9d:63d1:95fc:acb8]) (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 BCD90216C33; Wed, 16 May 2012 23:38:47 +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 1121C20AD1EA; Thu, 17 May 2012 09:38:42 +1000 (EST) To: Randy Bush From: Mark Andrews References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> In-reply-to: Your message of "Wed, 16 May 2012 10:54:31 -1000." Date: Thu, 17 May 2012 09:38:42 +1000 Message-Id: <20120516233843.1121C20AD1EA@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 23:39:06 -0000 In message , Randy Bush writes: > > +1, PMTUD it should be! > > and cash should fall from the sky > > let me reposition the issue > > whether we like it or not, many of these hacks, and hacks they are, will > break. pmtud would be lovely, but no prudent op can bet on it. > therefore, we need to give > o warning(s) > o some guidance > > in what document(s) and how are those best done? You got Comcast, ATT, etc. to look at whom their customers are talking to and to configure a low MTU link and try to talk to those boxes through it. If they break then you report it. Having 20+ major ISPs all complain at the same time that PMTUD is broken may well have a positive effect. Issue a CVE against all IPv6 boxes that don't implement RFC 4821. RFC 4821 support should be manditory for IPv6. The one exception permitted is boxes that fragment *all* IPv6 packets at 1280. This really is at the level where a CVE needs to be issued. RFC 4821 is already mentioned in node requirements (RFC 6434) though I think we could make the wording stronger. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From randy@psg.com Wed May 16 16:53:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C2B9E802A for ; Wed, 16 May 2012 16:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Aer1+bjAne2 for ; Wed, 16 May 2012 16:53:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D66529E8027 for ; Wed, 16 May 2012 16:53:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SUo21-000IgA-MV; Wed, 16 May 2012 23:53:27 +0000 Date: Wed, 16 May 2012 13:53:15 -1000 Message-ID: From: Randy Bush To: Mark Andrews In-Reply-To: <20120516233843.1121C20AD1EA@drugs.dv.isc.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> <20120516233843.1121C20AD1EA@drugs.dv.isc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 May 2012 23:53:28 -0000 >>> +1, PMTUD it should be! >> >> and cash should fall from the sky >> >> let me reposition the issue >> >> whether we like it or not, many of these hacks, and hacks they are, will >> break. pmtud would be lovely, but no prudent op can bet on it. >> therefore, we need to give >> o warning(s) >> o some guidance >> >> in what document(s) and how are those best done? > > You got Comcast, ATT, etc. to look at whom their customers are > talking to and to configure a low MTU link and try to talk to those > boxes through it. If they break then you report it. Having 20+ > major ISPs all complain at the same time that PMTUD is broken may > well have a positive effect. > > Issue a CVE against all IPv6 boxes that don't implement RFC 4821. > RFC 4821 support should be manditory for IPv6. The one exception > permitted is boxes that fragment *all* IPv6 packets at 1280. > > This really is at the level where a CVE needs to be issued. > > RFC 4821 is already mentioned in node requirements (RFC 6434) though > I think we could make the wording stronger. amazingly us-centric for an aussie. and thank you for the example of waiting for cash to fall from the sku. randy From Fred.L.Templin@boeing.com Wed May 16 17:00:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EF711E8072 for ; Wed, 16 May 2012 17:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX1i4z0xFNXt for ; Wed, 16 May 2012 17:00:21 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id DBD709E8024 for ; Wed, 16 May 2012 17:00:21 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4H00FXJ029221 for ; Wed, 16 May 2012 17:00:15 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4H00EP8029192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 May 2012 17:00:14 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4H00JT8007617; Wed, 16 May 2012 17:00:19 -0700 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4H00IGn007580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 16 May 2012 17:00:19 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 16 May 2012 17:00:18 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , Warren Kumari , Lorenzo Colitti Date: Wed, 16 May 2012 17:00:17 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0zo/uCBLiPGi6pRd+V37JYV26LtAAE6UZAAAE2szA= Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com><301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org><4ED0951D-E320-4982-892B-F541DB923A39@laposte.net> <25527DA4-E326-4E8C-9AB8-EF73A3E7E620@kumari.net> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CFE9@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CFE9@XMB-RCD-109.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-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 00:00:23 -0000 >> Intermediate devices monkeying with my packet -- do not want.. > > For over a decade the middlebox edited the TCP MSS for IPv4 > and saved one's PPPOE Internet connection from getting dropped. > Hmm, which is worse?=A0 No Internet connection vs. the wish above. > > PMTUD is not an option since the protocol uses ICMPv6 that can > be blocked in the Internet path. PMTUD is mandatory in IPv6 unless the minimum MTU of 1280 is used. The 6rd ISP has no way of controlling the IPv6 PMTU "in the wild" beyond its own boundaries, so there is no way for it to avoid dependence on ICMPv6 PMTUD even if the CPE router rewrites the MSS. (Unless the CPE rewrites the MSS to a "silly" value such as 1240 or smaller). > Fred Templin has ideas along the right track but none > of those ideas are in a Standards Track RFC that rfc6204bis > can reference for a technology. It should not be a problem to put them into a standards-track document especially given customer pull such as from rfc6204bis. > Don't know how many hosts implement RFC 4821 and PLPMTUD. I believe at least one major OS vendor implements RFC4821. Like Mark Andrews said, the recommendation for implementing RFC4821 should be made as strong as possible. > That leaves only two options at the table.=20 > (a) The SP knows exactly what MTU to sent in an RA to the=20 > CPE WAN.=A0 The MTU is the effective MTU for DS-Lite and the=20 > MTU can be used in the RA on the CPE LAN segment.=A0 Daniel > Rosen and Gert dislike the WAN MTU to mess with the LAN > MTU - if they can clarify why, that would be helpful. > Anyway, 6rd does not have an RA from the SP to the CPE > WAN.=A0 So the CPE has some internal magic that if the CPE > uses 6rd, the CPE uses a certain conservative MTU such as > 1280 on the CPE LAN or the CPE has a manual configuration > which is not good.=A0 If Daniel and Gert find important > reasons then (a) is not a good option.=A0 Note for DS-Lite > the SP has another alternative in that the SP sets the > TCP MSS at the AFTR. > (b) Use TCP MSS Rewrite in the CPE because there are certain > cases (6rd CPE to CPE communication) where the SP cannot set > the TCP MSS and hosts in the CPE LAN send packets larger than > the protocol MTU used in the Internet connection from the CPE > WAN to the SP.=A0 Who signals to the hosts to reduce MTU? If the CPE rewrites TCP MSS to something larger than the MTU of the smallest link on the path to the final destination (minus 40 bytes), then ICMPv6 PMTUD will ensue. If TCP MSS rewrite alone is the only mechanism used to avoid PMTUD issues, then the only safe rewrite value would by 1240, which is unacceptable. Fred PS As Warren said, please stick to plaintext to make this easier for everyone. > Hemant From hesham@elevatemobile.com Wed May 16 18:17:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6E511E8093 for ; Wed, 16 May 2012 18:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjFiIsngAkuL for ; Wed, 16 May 2012 18:17:58 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 902C511E8091 for ; Wed, 16 May 2012 18:17:57 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SUpLQ-0004Sa-9F for ; Thu, 17 May 2012 11:17:44 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 17 May 2012 11:17:24 +1000 From: Hesham Soliman To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 01:17:59 -0000 Can I ask a naive question on this, I haven't read the whole thread so someone might have dismissed this already, but why can't the CPE advertise a lower MTU if it knows that it's going to add tunnels ..etc? This way the user's device will make sure whatever it sends (including et headers) fits into the advertised MTU and the CPE can add the needed tunnels. Just curious if this was already discussed. Hesham From shemant@cisco.com Wed May 16 18:35:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D5121F8713 for ; Wed, 16 May 2012 18:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.172 X-Spam-Level: X-Spam-Status: No, score=-10.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65AdPAFpqkd7 for ; Wed, 16 May 2012 18:35:43 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 12E0C21F8712 for ; Wed, 16 May 2012 18:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1725; q=dns/txt; s=iport; t=1337218540; x=1338428140; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0ouyT+ZvPD4XDtXgu40QhY6sSGdsXBMxFxpIPfIFjqY=; b=WwiX6PjE9f7T5jWnjENJX8fC8ETCl9Lf/ZZXsgr7WFWpAWnnvGl6NklV LKKhKQoxS8ODDfhNzxRdUBLTdqDpdgS/6BVuGRZ3Apik8Wexa7Y5BbqZM J253L4zkYIrOyos9SiF8j3rQ9v16+vFJu35EUjoxdnhE6DpZkiuctp8fu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANFUtE+tJXHA/2dsb2JhbABEtAuBB4IVAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHbAubb6AABIsThHViA4hjm26BaYMH X-IronPort-AV: E=Sophos;i="4.75,605,1330905600"; d="scan'208";a="83752793" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 17 May 2012 01:35:39 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q4H1ZdO8005736; Thu, 17 May 2012 01:35:39 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 20:35:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 May 2012 20:35:38 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8D035@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0zyuxDJtYxdwWFSPCUR1MT/AdBfAAAVNuQ References: From: "Hemant Singh (shemant)" To: "Hesham Soliman" , "IPv6 Operations" X-OriginalArrivalTime: 17 May 2012 01:35:39.0949 (UTC) FILETIME=[5DD9F5D0:01CD33CD] Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 01:35:44 -0000 That is precisely what I and some of us have asked of in the thread. The tunneled Internet connection from the CPE WAN to the SP is a well-known connection to the CPE. For example, the CPE knows the connection is using the PPPOE protocol over 6rd. PPPOE has a protocol MTU of 1492 while the host behind the CPE has a default MTU of 1500. So the CPE computes the effective MTU and edits the TCP MSS option with the effective MTU and thus a TCP client on the host also changes to the new MTU. The TCP MSS edit is also a stateless operation in the CPE. =20 However, folks are asking, does the CPE do TCP packet inspection for all time to come since the proposed text says the "CPE performs TCP MSS edit on traversing the CPE". My answer to such a question is, as far as the tunneled Internet connections is up, the TCP packet inspection and TCP MSS edit is enabled for the SYN packets. Cheers, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hesham Soliman Sent: Wednesday, May 16, 2012 9:17 PM To: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis Can I ask a naive question on this, I haven't read the whole thread so someone might have dismissed this already, but why can't the CPE advertise a lower MTU if it knows that it's going to add tunnels ..etc? This way the user's device will make sure whatever it sends (including et headers) fits into the advertised MTU and the CPE can add the needed tunnels. Just curious if this was already discussed. Hesham _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Wed May 16 18:42:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322F121F84FB for ; Wed, 16 May 2012 18:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmGdqx3VjHVK for ; Wed, 16 May 2012 18:42:29 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B413421F84E7 for ; Wed, 16 May 2012 18:42:29 -0700 (PDT) Received: by dacx6 with SMTP id x6so1767511dac.31 for ; Wed, 16 May 2012 18:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+PHzdkrYR//q/Vt0fozIEHKXN6fHEQuxGxmYQiyKf34=; b=v/Vw5i+C0RDYGoBu6XJ0N+U1ELGbx9mp3uEAKHfjfZ/SCvQmSXAnvZ8u9Oe2MU7sH/ 1StsCZG3PuY89HIr/l3jsrrPmj1fuT2LwVFkHQJuaEibJDGgDCm0ZkC/8EDrtKuy5ZM4 ttYvxBfpxhMGIazKkd40egaOiQgWMI7dmFHDaMHKiFPz4IHyKTcN4IECGhrbrSjax+rr e5yXr0FxdciSQJh8qbOpXpegq8HUHc9OIpF8cwBQSMpiI8nW345HUWJ4u1jCsMvJbIY5 SK8HCUCfR7QrVNXeWqbWegtAssd4TI6xVBfFSiXNxNPDwtuNMwATYKwhaqG6WGkoSxCn fdwQ== MIME-Version: 1.0 Received: by 10.68.238.228 with SMTP id vn4mr21844146pbc.132.1337218949389; Wed, 16 May 2012 18:42:29 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Wed, 16 May 2012 18:42:29 -0700 (PDT) Received: by 10.143.66.2 with HTTP; Wed, 16 May 2012 18:42:29 -0700 (PDT) In-Reply-To: <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C4DE@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C916@XMB-RCD-109.cisco.com> <301F2A03-5F84-4147-B902-E1FA43A3096E@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C304A8CA9A@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD10E233289D@MOPESMBX01.eu.thmulti.com> Date: Wed, 16 May 2012 18:42:29 -0700 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=047d7b33d950771bb804c0318c8a Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 01:42:30 -0000 --047d7b33d950771bb804c0318c8a Content-Type: text/plain; charset=ISO-8859-1 I largely agree that icmpv6 must be a solution. RA MTU perhaps too. But my largest concern is ds-lite moving ipv4 in a tunnel across Docsis with max mtu of 1522 While not yet in scope, MAP-E will have the same issues, no? And mss adjusting is the only tenable solution for this case of ipv4 in v6? Sorry if i missed something obvious Cb --047d7b33d950771bb804c0318c8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


I largely agree that icmpv6 must be a solution. RA MTU perhaps too.

But my largest concern is ds-lite moving ipv4 in a tunnel across Docsis = with max mtu of 1522=A0

While not yet in scope, MAP-E will have the same issues, no?

And mss adjusting=A0 is the only tenable solution for this case=A0 of ip= v4 in v6?

Sorry if i missed something obvious

Cb

--047d7b33d950771bb804c0318c8a-- From internet-drafts@ietf.org Wed May 16 19:08:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E0411E80A1; Wed, 16 May 2012 19:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W32re-iB9m5A; Wed, 16 May 2012 19:08:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB89811E8073; Wed, 16 May 2012 19:08:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120517020810.6182.47066.idtracker@ietfa.amsl.com> Date: Wed, 16 May 2012 19:08:10 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 17 May 2012 02:08: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 : Basic Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Filename : draft-ietf-v6ops-6204bis-09.txt Pages : 22 Date : 2012-05-16 This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis/ From lorenzo@google.com Wed May 16 19:29:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E66C11E8096 for ; Wed, 16 May 2012 19:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.778 X-Spam-Level: X-Spam-Status: No, score=-102.778 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqgDBHhUUet2 for ; Wed, 16 May 2012 19:29:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 802CF11E8073 for ; Wed, 16 May 2012 19:29:50 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2212779obb.31 for ; Wed, 16 May 2012 19:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=FDmK7IVsJxYUvR7uItTZSo4m5H//cNX3M/+y0zyYD0s=; b=ffOILqEthnXobp2zyBSxbHiB6wZ8gfzlvDHOiQms2TRm6cdt8S6kJ/yrNoitu/bZPT ubXVEOm0qXhJsLmUVUjI16S5LEX9FNEldJs8b2I9lrAI6BL1nkCZ+0KPqrCZ7gcAFMVk McvRbwH4JZbUCF6BR/fY6sStgr2A/CIpQt5yg0NYhaOX/90cwGFkUtfJvMMhpOve6ObI ogOyIiZsQ6Ht7xqq8SCRnBM+wlNdQtx2ukxd8wo5a5gwMw7NkrqXmlHKPp8YRsYoPO8C 0LocRTh3aQqEM+8f27wUJKekzQ6nQ2leCZH/qETxD/RZfpjBVWJ2tfQi2ixQOucmykl4 RXrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=FDmK7IVsJxYUvR7uItTZSo4m5H//cNX3M/+y0zyYD0s=; b=XmU82/+EQggcHO+rirEKYsGRuzenZIeV4ClSJ4u4h/P50UcFiEwUcFEbTVXXjo9Z/A s0YulyQ24Of1JzEisliN5IW2YaHUfGTxrlkQt/Jss90ePXuPm1eNOUfhQjgrkekB05sP BPlbzmxAx/G0ocWKAgQtN1xJyvAuiPT2kiHjC1oB7MHBiwOC7p3stMJEPNrhCTg8bMJI L/fvgtU2jqErWzqqU5EHKF9/wgPBuUMwcPCqu8FkosWH+bM9mb+cnPErIDNfI1zjrthH oTERdX/03BVS5lXw9idzTOyoBR9/AHzis3YCyQvHrDsL4bXq55So8Db3tgLIDhnlfG1Q aEZw== Received: by 10.182.74.42 with SMTP id q10mr4870491obv.52.1337221790173; Wed, 16 May 2012 19:29:50 -0700 (PDT) Received: by 10.182.74.42 with SMTP id q10mr4870484obv.52.1337221790056; Wed, 16 May 2012 19:29:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Wed, 16 May 2012 19:29:29 -0700 (PDT) In-Reply-To: References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8C35D@XMB-RCD-109.cisco.com> <10e101cd3002$4917d960$db478c20$@com> From: Lorenzo Colitti Date: Thu, 17 May 2012 11:29:29 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04447129c841ed04c03235a0 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlrDASGlQQZe6D/jdAPn7oGmEPu9wP39aTwUhzHpLtk1WzEG9JARGky5o3j7zsVfX5V9hwwXJ4eepdP28EF39VHQ/nK4quiAhG1GjCvnGATkar/vs7WKtbdK2A8idSpzUOL2Kjm Cc: IPv6 Operations Subject: Re: [v6ops] 6204 bis and mtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 02:29:51 -0000 --f46d04447129c841ed04c03235a0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2012 at 9:30 PM, R=E9mi Despr=E9s wrote: > if the MSS advertised in a received TCP SYN packet exceeds the link MTU > minus the TCP/IP header length (40 octets in IPv4, 60 in IPv6), reduce it > to this value, and adjust IP and TCP checksums accordingly. > Do whatever you want in IPv4, but please don't touch the IPv6 packets. It's slow, it breaks end-to-end, and there are better ways of doing thign. --f46d04447129c841ed04c03235a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 15, 2012 at 9:30 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
if the MSS advertised in a received TCP SYN packet exceeds the link MTU min= us the TCP/IP header length (40 octets in IPv4, 60 in IPv6), reduce it to t= his value, and adjust IP and TCP checksums accordingly.

Do whatever you want in IPv4, but please don't touc= h the IPv6 packets. It's slow, it breaks end-to-end, and there are bett= er ways of doing thign.
--f46d04447129c841ed04c03235a0-- From hesham@elevatemobile.com Wed May 16 20:41:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FC621F861C for ; Wed, 16 May 2012 20:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBZNf1rWtOU0 for ; Wed, 16 May 2012 20:41:46 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id E460521F8585 for ; Wed, 16 May 2012 20:41:45 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SUrao-0004kk-KX; Thu, 17 May 2012 13:41:44 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 17 May 2012 13:41:21 +1000 From: Hesham Soliman To: "Hemant Singh (shemant)" , IPv6 Operations Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8D035@XMB-RCD-109.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 03:41:46 -0000 -----Original Message----- From: "Hemant Singh (shemant)" Date: Wed, 16 May 2012 20:35:38 -0500 To: Hesham Soliman , IPv6 Operations Subject: RE: [v6ops] proposed TCP MSS text for rfc6204bis >That is precisely what I and some of us have asked of in the thread. >The tunneled Internet connection from the CPE WAN to the SP is a >well-known connection to the CPE. For example, the CPE knows the >connection is using the PPPOE protocol over 6rd. PPPOE has a protocol >MTU of 1492 while the host behind the CPE has a default MTU of 1500. So >the CPE computes the effective MTU and edits the TCP MSS option with the >effective MTU and thus a TCP client on the host also changes to the new >MTU. The TCP MSS edit is also a stateless operation in the CPE. => But why edit the MSS instead of simply advertising that link MTU to the client? That way there is no need to edit the MSS. Hesham >-----Original Message----- >From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >Of Hesham Soliman >Sent: Wednesday, May 16, 2012 9:17 PM >To: IPv6 Operations >Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis > >Can I ask a naive question on this, I haven't read the whole thread so >someone might have dismissed this already, but why can't the CPE >advertise >a lower MTU if it knows that it's going to add tunnels ..etc? This way >the >user's device will make sure whatever it sends (including et headers) >fits >into the advertised MTU and the CPE can add the needed tunnels. > >Just curious if this was already discussed. > >Hesham > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From marka@isc.org Wed May 16 22:34:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2690F21F866D for ; Wed, 16 May 2012 22:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+rRMiDe4CCz for ; Wed, 16 May 2012 22:34:40 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9138B21F865B for ; Wed, 16 May 2012 22:34:40 -0700 (PDT) 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 id BAA6FC992C; Thu, 17 May 2012 05:34:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4d9d:63d1:95fc:acb8]) (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 58602216C33; Thu, 17 May 2012 05:34:26 +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 898C120AF96F; Thu, 17 May 2012 15:34:18 +1000 (EST) To: Hesham Soliman From: Mark Andrews References: In-reply-to: Your message of "Thu, 17 May 2012 13:41:21 +1000." Date: Thu, 17 May 2012 15:34:17 +1000 Message-Id: <20120517053418.898C120AF96F@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 05:34:41 -0000 In message , Hesham Soliman writes: > >That is precisely what I and some of us have asked of in the thread. > >The tunneled Internet connection from the CPE WAN to the SP is a > >well-known connection to the CPE. For example, the CPE knows the > >connection is using the PPPOE protocol over 6rd. PPPOE has a protocol > >MTU of 1492 while the host behind the CPE has a default MTU of 1500. So > >the CPE computes the effective MTU and edits the TCP MSS option with the > >effective MTU and thus a TCP client on the host also changes to the new > >MTU. The TCP MSS edit is also a stateless operation in the CPE. > > => But why edit the MSS instead of simply advertising that link MTU to the > client? > That way there is no need to edit the MSS. > > Hesham Why should internal traffic be constrained by external mtu requirements? Don't you think jumbo frames should be allowed to work? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hesham@elevatemobile.com Wed May 16 22:42:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A90521F85BE for ; Wed, 16 May 2012 22:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU2hs7lHKSaQ for ; Wed, 16 May 2012 22:42:57 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 81F6221F8596 for ; Wed, 16 May 2012 22:42:56 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SUtUD-0002HZ-IX; Thu, 17 May 2012 15:42:53 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 17 May 2012 15:42:32 +1000 From: Hesham Soliman To: Mark Andrews Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: <20120517053418.898C120AF96F@drugs.dv.isc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 05:42:58 -0000 > >In message , Hesham Soliman >writes: >> >That is precisely what I and some of us have asked of in the thread. >> >The tunneled Internet connection from the CPE WAN to the SP is a >> >well-known connection to the CPE. For example, the CPE knows the >> >connection is using the PPPOE protocol over 6rd. PPPOE has a protocol >> >MTU of 1492 while the host behind the CPE has a default MTU of 1500. >>So >> >the CPE computes the effective MTU and edits the TCP MSS option with >>the >> >effective MTU and thus a TCP client on the host also changes to the new >> >MTU. The TCP MSS edit is also a stateless operation in the CPE. >> >> => But why edit the MSS instead of simply advertising that link MTU to >>the >> client? >> That way there is no need to edit the MSS. >> >> Hesham > >Why should internal traffic be constrained by external mtu requirements? >Don't you think jumbo frames should be allowed to work? => No I don't think that should be a factor in our decisions. We're talking about deployments that are typically done in small home networks. And we're talking about a small reduction in MTU (tunnel overhead). So I don't think it's worth going for a hack like MSS rewrite to allow for jumbo frames in this particular scenario. We have a well defined tool for letting hosts know what the link MTU is, and I don't think we should be resorting to muddle box hacks unless we have to. In this home/small office scenario, it's perfectly fine to the link MTU. In a more complex network with multiple routers within a site, the leaf routers could advertise a higher MTU. Hesham > >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From achatz@forthnetgroup.gr Wed May 16 23:54:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D5C21F8603 for ; Wed, 16 May 2012 23:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 GTAcUsljUfru for ; Wed, 16 May 2012 23:54:01 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id C506621F8604 for ; Wed, 16 May 2012 23:54:00 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q4H6rr2I009995; Thu, 17 May 2012 09:53:53 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id q4H6rr9a007320; Thu, 17 May 2012 09:53:53 +0300 Received: from [192.168.1.2] (77.49.179.249.dsl.dyn.forthnet.gr [77.49.179.249]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q4H6rgEr016741; Thu, 17 May 2012 09:53:43 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4FB4A071.2050908@forthnetgroup.gr> Date: Thu, 17 May 2012 09:53:37 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 06:54:02 -0000 I had expressed similar concerns in the past too. http://www.ietf.org/mail-archive/web/v6ops/current/msg10716.html Imho, i don't like the idea of CPE doing the MSS clamping. -- Tassos Hesham Soliman wrote on 17/5/2012 08:42: >> In message, Hesham Soliman >> writes: >>>> That is precisely what I and some of us have asked of in the thread. >>>> The tunneled Internet connection from the CPE WAN to the SP is a >>>> well-known connection to the CPE. For example, the CPE knows the >>>> connection is using the PPPOE protocol over 6rd. PPPOE has a protocol >>>> MTU of 1492 while the host behind the CPE has a default MTU of 1500. >>> So >>>> the CPE computes the effective MTU and edits the TCP MSS option with >>> the >>>> effective MTU and thus a TCP client on the host also changes to the new >>>> MTU. The TCP MSS edit is also a stateless operation in the CPE. >>> => But why edit the MSS instead of simply advertising that link MTU to >>> the >>> client? >>> That way there is no need to edit the MSS. >>> >>> Hesham >> Why should internal traffic be constrained by external mtu requirements? >> Don't you think jumbo frames should be allowed to work? > => No I don't think that should be a factor in our decisions. We're > talking about deployments that are typically done in small home networks. > And we're talking about a small reduction in MTU (tunnel overhead). So I > don't think it's worth going for a hack like MSS rewrite to allow for > jumbo frames in this particular scenario. > > We have a well defined tool for letting hosts know what the link MTU is, > and I don't think we should be resorting to muddle box hacks unless we > have to. In this home/small office scenario, it's perfectly fine to the > link MTU. In a more complex network with multiple routers within a site, > the leaf routers could advertise a higher MTU. > > > Hesham > >> -- >> 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 shemant@cisco.com Thu May 17 02:25:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53BC21F8657 for ; Thu, 17 May 2012 02:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.167 X-Spam-Level: X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bARsMPn959B8 for ; Thu, 17 May 2012 02:25:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1007421F8664 for ; Thu, 17 May 2012 02:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3027; q=dns/txt; s=iport; t=1337246717; x=1338456317; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=IBGc781rzkMiZtz4GA1Z+U1z3uv5ZPkHyoIWyL/7gAo=; b=cVXHHdhXx99OtBKvRV5sODxi2o5spsvTMaTliwe5mOTiiaJwT6RfxPsZ 6xNo/Gob8brS5DHwbJPiA1atjtIOhxBGmJR5LgBBF9dkhADGr7X4Uj+YS VSVLfZ13bmiiNpKvksNGtIjluE2gnNQxsEcxfWKShmYjyUQY9AVhi7ElM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJXDtE+tJV2Y/2dsb2JhbABEs0eBB4IVAQEBBAEBAQ8BHQo0CwwCAgIBCA4DBAEBCwYXAQYBGgwfCQgBAQQBEggBGYdsC5t9n38Eiw8ZhFxiA4hjm26BaYMHgUE X-IronPort-AV: E=Sophos;i="4.75,608,1330905600"; d="scan'208";a="84049959" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 17 May 2012 09:25:16 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4H9PGE3010377; Thu, 17 May 2012 09:25:16 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 04:25:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 May 2012 04:25:14 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8D078@XMB-RCD-109.cisco.com> In-Reply-To: <4FB4A071.2050908@forthnetgroup.gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac0z+d67fOblp1jfSRaxlA7kOidiqgAFK0Ng References: <4FB4A071.2050908@forthnetgroup.gr> From: "Hemant Singh (shemant)" To: "Tassos Chatzithomaoglou" , "Hesham Soliman" X-OriginalArrivalTime: 17 May 2012 09:25:16.0038 (UTC) FILETIME=[F81BF260:01CD340E] Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 09:25:17 -0000 Since there was no clear consensus on adding TCP MSS rewrite to rfc6204bis, we released the -09 version yesterday with no TCP MSS Rewrite. =20 Joel, if the -09 goes to the IESG, please add Tim Winters to the Acknowledgements list. I realized I had to add his name but by then I had already hit the "Post" button to ship the -09. Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tassos Chatzithomaoglou Sent: Thursday, May 17, 2012 2:54 AM To: Hesham Soliman Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis I had expressed similar concerns in the past too. http://www.ietf.org/mail-archive/web/v6ops/current/msg10716.html Imho, i don't like the idea of CPE doing the MSS clamping. -- Tassos Hesham Soliman wrote on 17/5/2012 08:42: >> In message, Hesham Soliman >> writes: >>>> That is precisely what I and some of us have asked of in the thread. >>>> The tunneled Internet connection from the CPE WAN to the SP is a >>>> well-known connection to the CPE. For example, the CPE knows the >>>> connection is using the PPPOE protocol over 6rd. PPPOE has a protocol >>>> MTU of 1492 while the host behind the CPE has a default MTU of 1500. >>> So >>>> the CPE computes the effective MTU and edits the TCP MSS option with >>> the >>>> effective MTU and thus a TCP client on the host also changes to the new >>>> MTU. The TCP MSS edit is also a stateless operation in the CPE. >>> =3D> But why edit the MSS instead of simply advertising that link = MTU to >>> the >>> client? >>> That way there is no need to edit the MSS. >>> >>> Hesham >> Why should internal traffic be constrained by external mtu requirements? >> Don't you think jumbo frames should be allowed to work? > =3D> No I don't think that should be a factor in our decisions. We're > talking about deployments that are typically done in small home networks. > And we're talking about a small reduction in MTU (tunnel overhead). So I > don't think it's worth going for a hack like MSS rewrite to allow for > jumbo frames in this particular scenario. > > We have a well defined tool for letting hosts know what the link MTU is, > and I don't think we should be resorting to muddle box hacks unless we > have to. In this home/small office scenario, it's perfectly fine to the > link MTU. In a more complex network with multiple routers within a site, > the leaf routers could advertise a higher MTU. > > > Hesham > >> --=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 dr@cluenet.de Thu May 17 04:33:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E87D21F8596 for ; Thu, 17 May 2012 04:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0zTQEuUdeWh for ; Thu, 17 May 2012 04:33:25 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id DBD1721F858E for ; Thu, 17 May 2012 04:33:24 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id A571D10837A; Thu, 17 May 2012 13:33:22 +0200 (CEST) Date: Thu, 17 May 2012 13:33:22 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120517113322.GA9640@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8D035@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 11:33:25 -0000 On Thu, May 17, 2012 at 01:41:21PM +1000, Hesham Soliman wrote: > => But why edit the MSS instead of simply advertising that link MTU to the > client? > That way there is no need to edit the MSS. Because you mess with LAN-internal communications then. I don't want a router to mess with my home network's MTU around just because the WAN link properties change. My LAN has MTU 1500. If the WAN connection behind some random router has a lower MTU, that's a standard scenario PMTUD deals with. And as we operators know, PMTUD in the IPv4 Internet is FUBAR (a fact the whole DSL industry has accepted and thus TCP MSS clamping is the norm), the operator community WILL require vendors to do what it takes to make DS-Lite as pain free to the enduser as possible: perform TCP MSS clamping. It works for the whole PPPoE DSL industry "reasonably fine" since over a decade. BTW, also think about LANs with multiple routers present. Do you want to have all of them mess around the LAN MTU in their RAs to their own liking? One having a DS-Lite uplink (advertising LAN MTU 1460) and another one having a 1500 octet uplink (advertising LAN MTU 1500)? And your LAN-internal TCP sessions resetting all the time because hosts adjust their interface MTU setting (and usually flap the link while doing so) upon RA reception? Don't. Mess. With. LAN MTU. It's horribly misguided to do so. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From gert@space.net Thu May 17 04:42:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8327721F861B for ; Thu, 17 May 2012 04:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgwncQpRUOAN for ; Thu, 17 May 2012 04:42:54 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id DD02F21F85CD for ; Thu, 17 May 2012 04:42:53 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 34273F8C4A for ; Thu, 17 May 2012 13:42:52 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 213F6F8C37 for ; Thu, 17 May 2012 13:42:52 +0200 (CEST) Received: (qmail 74906 invoked by uid 1007); 17 May 2012 13:42:52 +0200 Date: Thu, 17 May 2012 13:42:52 +0200 From: Gert Doering To: Hesham Soliman Message-ID: <20120517114252.GI84425@Space.Net> References: <20120517053418.898C120AF96F@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 11:42:54 -0000 Hi, On Thu, May 17, 2012 at 03:42:32PM +1000, Hesham Soliman wrote: > We have a well defined tool for letting hosts know what the link MTU is, Yes. The *link* MTU. Which has nothing to do whatsoever with "the minimum MTU a packet might encounter somewhere on the Internet". 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 hesham@elevatemobile.com Thu May 17 05:00:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2ED321F866D for ; Thu, 17 May 2012 05:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiieNAHL9+Ea for ; Thu, 17 May 2012 05:00:18 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id E3ECC21F8659 for ; Thu, 17 May 2012 05:00:17 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SUzMq-0006of-Lf; Thu, 17 May 2012 22:00:03 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 17 May 2012 21:59:26 +1000 From: Hesham Soliman To: Daniel Roesen , Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: <20120517113322.GA9640@srv03.cluenet.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 12:00:18 -0000 >On Thu, May 17, 2012 at 01:41:21PM +1000, Hesham Soliman wrote: >> => But why edit the MSS instead of simply advertising that link MTU to >>the >> client? >> That way there is no need to edit the MSS. > >Because you mess with LAN-internal communications then. I don't want a >router to mess with my home network's MTU around just because the WAN >link properties change. => But you're ok with it messing with most of the communication outside the LAN? > >My LAN has MTU 1500. If the WAN connection behind some random router has >a lower MTU, that's a standard scenario PMTUD deals with. And as we >operators know, PMTUD in the IPv4 Internet is FUBAR (a fact the whole >DSL industry has accepted and thus TCP MSS clamping is the norm), the >operator community WILL require vendors to do what it takes to make >DS-Lite as pain free to the enduser as possible: perform TCP MSS >clamping. It works for the whole PPPoE DSL industry "reasonably fine" >since over a decade. => How many home users do you know who would feel the pain of reducing their internal LAN MTU by 10 bytes? I just don't find this reason serious for the scenarios being discussed. Engineering is about tradeoffs, the tradeoff here is to have a hack in the GW for TCP only, Vs reducing the internal MTU by an insignificant amount that none of the average users would ever care about or even care to know what MTU is. > >BTW, also think about LANs with multiple routers present. Do you want to >have all of them mess around the LAN MTU in their RAs to their own >liking? => As I mentioned in an earlier email, those were not the scenarios we're discussing, if someone is setting such a network then it's a very different scenario from the home network or small office networks we're discussing which are typically single router networks. If someone is setting up a multi-router network they can afford to be more involved in the router config. >One having a DS-Lite uplink (advertising LAN MTU 1460) and >another one having a 1500 octet uplink (advertising LAN MTU 1500)? And >your LAN-internal TCP sessions resetting all the time because hosts >adjust their interface MTU setting (and usually flap the link while >doing so) upon RA reception? > >Don't. Mess. With. LAN MTU. It's horribly misguided to do so. => I think it's misguided to have routers do this hack to avoid losing a handful of bytes on the LAN's MTU. Hesham > >Best regards, >Daniel > >-- >CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From hesham@elevatemobile.com Thu May 17 05:00:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7087C21F8670 for ; Thu, 17 May 2012 05:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye0nmbujj+gt for ; Thu, 17 May 2012 05:00:56 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id CD85C21F86A6 for ; Thu, 17 May 2012 05:00:55 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SUzNm-0006sH-5L; Thu, 17 May 2012 22:00:38 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 17 May 2012 22:00:27 +1000 From: Hesham Soliman To: Gert Doering Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: <20120517114252.GI84425@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 12:00:56 -0000 -----Original Message----- From: Gert Doering Date: Thu, 17 May 2012 13:42:52 +0200 To: Hesham Soliman Cc: Mark Andrews , IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >Hi, > >On Thu, May 17, 2012 at 03:42:32PM +1000, Hesham Soliman wrote: >> We have a well defined tool for letting hosts know what the link MTU is, > >Yes. The *link* MTU. Which has nothing to do whatsoever with "the >minimum >MTU a packet might encounter somewhere on the Internet". => Yes of course, so what's the comment? MSS editing has nothing to do with any other MTU on the Internet either. Hesham > >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 twinters@iol.unh.edu Thu May 17 05:45:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15DD21F85E4 for ; Thu, 17 May 2012 05:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwgjHO9x+E7F for ; Thu, 17 May 2012 05:45:34 -0700 (PDT) Received: from exprod5og115.obsmtp.com (exprod5og115.obsmtp.com [64.18.0.246]) by ietfa.amsl.com (Postfix) with SMTP id 18EBE21F85D5 for ; Thu, 17 May 2012 05:45:34 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob115.postini.com ([64.18.4.12]) with SMTP ID DSNKT7Ty7NVgbnpOrU9jImhOEFNsmpCitf/m@postini.com; Thu, 17 May 2012 05:45:34 PDT Received: from optimus.iol.unh.edu (optimus.iol.unh.edu [132.177.118.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 6F43C8F0079; Thu, 17 May 2012 08:45:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_42F61896-E1F9-4C59-AD0C-E6C74DDBEC74" From: Timothy Winters In-Reply-To: Date: Thu, 17 May 2012 08:45:32 -0400 Message-Id: <20EA9BD5-F05C-44EE-8046-6CF992D413C2@iol.unh.edu> References: To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1278) Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 12:45:35 -0000 --Apple-Mail=_42F61896-E1F9-4C59-AD0C-E6C74DDBEC74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Ole, Thanks for taking the time, so If I'm understanding you = correctly a CE Router is expected to generate a ICMPv6 Unreachable = message for all invalidated or unknown prefixes on the LAN interface? = This makes sense to me, I'm just making sure we don't expect a CE Router = to know the difference between recently invalidated and unknown. Regards, Tim Timothy Winters UNH-IOL Senior IP Manager 603-421-4987 On May 16, 2012, at 5:55 PM, Ole Tr=F8an wrote: > Tim, >=20 >> 6204bis has a requirement (L-3) that an IPv6 CE Router use the = Route Information Option (RIO) for delegated prefixes. The RIO option = contains a lifetime field for the prefix, which should be populated with = either the preferred or valid lifetime from a DHCP IA_PD option. Using = the valid lifetime from the PD for the life in the RIO makes sense as = 4191 states the following for the route lifetime:=20 >> The length of time in seconds >> (relative to the time the packet is sent) that the prefix >> is valid for route determination.=20 >>=20 >> The problem I'm currently seeing with this approach is L-14=20 >> "The IPv6 CE router MUST send an ICMPv6 Destination Unreachable >> message, code 5 (Source address failed ingress/egress = policy) >> for packets forwarded to it that use an address from a = prefix >> that has been deprecated." >>=20 >>=20 >> If the valid lifetime is used in the RIO, the host can attempt = to route a deprecated prefix to a CE Router only to have the router = respond with a ICMPv6 Error message. It may make more sense to use the = preferred lifetime as the value for the lifetime field in the RIO = option.=20 >>=20 >> What do others think about using the preferred lifetime to = populate the RIO lifetime? >=20 > a retake after thinking about this some more. >=20 > L-14 is there to catch the case where a prefix has been invalidated or = is unknown. the purpose is to inform the host that this address is now = invalid. forwarding of packets for deprecated prefixes is perfectly = fine, that may be part of normal renumbering. which is why I think L-14 = needs clarification. >=20 > the lifetime to use for the RIO option is somewhat correlated to the = lifetimes in the prefix, in that it doesn't make sense to claim to be a = router for a prefix that it has no guarantee it owns after the PD valid = lifetime has expired. I would suggest the RIO route lifetime to be the = smaller of the default router lifetime and the valid lifetime. >=20 > if there is flash renumbering, there might be 'residual' connections = still happening that will follow that route, the RIO route is only used = to reach another part of the home network, and that could be made to = work if the CE kept the more specific PD routes around. if not, then the = host will get an ICMP back. I don't see how changing the RIO route life = time for the PD prefix would matter. >=20 > cheers, > Ole >=20 --Apple-Mail=_42F61896-E1F9-4C59-AD0C-E6C74DDBEC74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Ole,
= Thanks for taking the time, so If I'm understanding you correctly = a CE Router is expected to generate a ICMPv6 Unreachable message for all = invalidated or unknown prefixes on the LAN interface?  This makes = sense to me, I'm just making sure we don't expect a CE Router to know = the difference between recently invalidated and = unknown.

Regards,
Tim

Timothy Winters
UNH-IOL Senior = IP = Manager
603-421-4987
<= /span>

On May 16, 2012, at 5:55 PM, Ole Tr=F8an wrote:

Tim,

6204bis = has a requirement (L-3) that an IPv6 CE Router use the Route Information = Option (RIO) for delegated prefixes.   The RIO option contains = a lifetime field for the prefix, which should be populated with either = the preferred or valid lifetime from a DHCP IA_PD option.  Using = the valid lifetime from the PD for the life in the RIO makes sense as = 4191 states the following for the route lifetime: =
The length of time in = seconds
=      (relative to the time the packet is sent) = that the prefix
=      is valid for route determination. =

= The problem I'm currently seeing with this approach is L-14 =
"The IPv6 CE router MUST send an = ICMPv6 Destination Unreachable
=          message, code 5 = (Source address failed ingress/egress = policy)
=          for packets = forwarded to it that use an address from a = prefix
=          that has been = deprecated."


If the = valid lifetime is used in the RIO, the host can attempt to route a = deprecated prefix to a CE Router only to have the router respond with a = ICMPv6 Error message.   It may make more sense to use the = preferred lifetime as the value for the lifetime field in the RIO = option.

What do = others think about using the preferred lifetime to populate the RIO = lifetime?

a retake after thinking about this some = more.

L-14 is there to catch the case where a prefix has been = invalidated or is unknown. the purpose is to inform the host that this = address is now invalid. forwarding of packets for deprecated prefixes is = perfectly fine, that may be part of normal renumbering. which is why I = think L-14 needs clarification.

the lifetime to use for the RIO = option is somewhat correlated to the lifetimes in the prefix, in that it = doesn't make sense to claim to be a router for a prefix that it has no = guarantee it owns after the PD valid lifetime has expired. I would = suggest the RIO route lifetime to be the smaller of the default router = lifetime and the valid lifetime.

if there is flash renumbering, = there might be 'residual' connections still happening that will follow = that route, the RIO route is only used to reach another part of the home = network, and that could be made to work if the CE kept the more specific = PD routes around. if not, then the host will get an ICMP back. I don't = see how changing the RIO route life time for the PD prefix would = matter.

cheers,
Ole


= --Apple-Mail=_42F61896-E1F9-4C59-AD0C-E6C74DDBEC74-- From Jean-Francois.TremblayING@videotron.com Thu May 17 06:04:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A341F21F85EE; Thu, 17 May 2012 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6csEtM0iiNd; Thu, 17 May 2012 06:04:18 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70B21F85ED; Thu, 17 May 2012 06:04:17 -0700 (PDT) In-Reply-To: To: hesham@elevatemobile.com MIME-Version: 1.0 X-KeepSent: 3488F7C7:B77D3CC1-85257A01:004430BB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 17 May 2012 09:04:03 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP1|March 07, 2012) at 05/17/2012 09:04:07, Serialize complete at 05/17/2012 09:04:07 Content-Type: multipart/alternative; boundary="=_alternative 0047C9CD85257A01_=" Received-SPF: none Cc: v6ops@ietf.org, v6ops-bounces@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 13:04:18 -0000 Message en plusieurs parties au format MIME --=_alternative 0047C9CD85257A01_= Content-Type: text/plain; charset="US-ASCII" >>Don't. Mess. With. LAN MTU. It's horribly misguided to do so. >=> I think it's misguided to have routers do this hack to avoid losing a >handful of bytes on the LAN's MTU. >Hesham 100% agreement with Hesham here. While it's a noble goal to push for jumbo frames in the home, the reality is that over 99.9% of Internet users could not care less. What they care about is having their "Internet connection" working. And some people on this list actually get paid at $dayjob to make sure this happens. I purchased a Cisco E4200v1 a while ago. Put it at home, turned on 6RD. 6 minutes later, the tablet complained it can't download from Google Market. Fired a snoop: PMTUD problem, and the router doesn't send a lowered MTU in RAs either (heard the E4200v2 does it though). One minute later I disabled 6RD, although I am the one who actually deployed it for my ISP and pushing for customers to use it. I now use a router that sends a lowered MTU in RAs when 6RD is on and I lived happily everafter. Bottom line: if it doesn't work right away out of the box for the average and not-so-average Internet user out there, we've collectively failed as a group to deliver specifications for an interoperable and working Internet. Operational issues do matter. Just make it work. /JF --=_alternative 0047C9CD85257A01_= Content-Type: text/html; charset="US-ASCII"
>>Don't. Mess. With. LAN MTU. It's horribly misguided to do so.
>=> I think it's misguided to have routers do this hack to avoid losing a
>handful of bytes on the LAN's MTU.
>Hesham

100% agreement with Hesham here.

While it's a noble goal to push for jumbo frames in the home, the
reality is that over 99.9% of Internet users could not care less.
What they care about is having their "Internet connection" working.
And some people on this list actually get paid at $dayjob to make
sure this happens.

<personnal experience>
I purchased a Cisco E4200v1 a while ago. Put it at home, turned on
6RD. 6 minutes later, the tablet complained it can't download
from Google Market. Fired a snoop: PMTUD problem, and the router doesn't
send a lowered MTU in RAs either (heard the E4200v2 does it though).
One minute later I disabled 6RD, although I am the one who actually
deployed it for my ISP and pushing for customers to use it. I now
use a router that sends a lowered MTU in RAs when 6RD is on and
I lived happily everafter.
</tranche de vie>

Bottom line: if it doesn't work right away out of the box for the
average and not-so-average Internet user out there, we've collectively
failed as a group to deliver specifications for an interoperable and
working Internet. Operational issues do matter. Just make it work.

/JF
</ranting>

--=_alternative 0047C9CD85257A01_=-- From mark@townsley.net Thu May 17 06:15:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C91E21F8550 for ; Thu, 17 May 2012 06:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGvgb9Do1RBc for ; Thu, 17 May 2012 06:15:06 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B321F854F for ; Thu, 17 May 2012 06:15:06 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so4277082wib.13 for ; Thu, 17 May 2012 06:15:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dzLl3un0uvuuvCh4kHrOA5ByiwhXo6ocu4yW/6Yr/wM=; b=NXjhpN65OJH+TJHlxfJGQSMjLye1MEGFuR0cqEl+l9Oz6IwklEZ6CnVLBnAJdp6f90 UvjeqNF/yneuEcZ/sYDUDdRwLlvA+A8O43a8aET+UXTKSlo/VIPvBO50HPMfbr+/zYY2 xVZ+MNfCfTlOLsIMjdshwBP01rgI8tb2Y6C0c7ntBUsahEdvKs1L9esAgzvQ9CfjLETf ceU63kOTlUrrYkEXrCuIk1/dH3E3c0f/vWAeTKx+qJuB/WOKeDRJvolly8YdgNvYJEfc 1tVOI3IKvUnnwV8P7KmWa1GbGCIoSBj1RRh9h80Jb6fgdYFlnWLrZ+m9K6ZbB89bbnd+ gepQ== Received: by 10.180.83.196 with SMTP id s4mr18196385wiy.15.1337260505204; Thu, 17 May 2012 06:15:05 -0700 (PDT) Received: from ams-townsley-8915.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gv4sm15018044wib.8.2012.05.17.06.14.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 06:15:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: Date: Thu, 17 May 2012 15:14:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B8E85A2-8BF0-4408-AB8C-FB7F4C306B3B@townsley.net> References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <4FA81137.7070907@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkusO9jyVeakBBXLlE3TBhJXNr9N+2mYGY3Sd5r9TRhm0uGFmnO8NW8urq6UAl8I9gfPU5t Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (for -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: Thu, 17 May 2012 13:15:07 -0000 FYI:=20 6RD-5 in the -09 text out today did not include the clarification = requested by Gert and Randy mentioned below: -09 reads: "the upstream network the WAN interface is connected to" It should be: "the particular interface from which the packet is being sent"=20 Seems to just be an editorial oversight.=20 - Mark On May 8, 2012, at 1:29 AM, Mark Townsley wrote: >=20 >=20 > On May 7, 2012, at 8:15 PM, Joel jaeggli wrote: >=20 >> I'm sitting here waiting for an 09 version of the draft so that I can >> expose the diffs to the list, test whether we need to need to = reconsider >> the WGLC, and send a shepherds report to the IESG if not. The longer >> temporally and the more diveregent the document gets the more likely = it >> is imho that we need to reconsider the wg consensus on publication, = but >> we don't know because it's not in the tool yet. >=20 > Here are the latest requirements that Chris, Hemant, Wes and I finally = agreed upon (posted at "version 3" the other day), plus the specific = text changes to 6RD-5 as suggested by Gert and Randy. I believe Hemant = has the draft pen.=20 >=20 > 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to = be active alone as well as simultaneously in order to support = coexistence of the two technologies during an incremental migration = period from 6rd to native IPv6.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that the packet's source IP address is derived from a = delegated prefix associated with the particular interface from which the = packet is being sent [Section 4.3 [RFC3704]]. >=20 > 6RD-6: The CE router MUST allow different as well as identical = delegated prefixes to be configured via each (6rd or native) WAN = interface. =20 >=20 > 6RD-7: In the event that forwarding rules produce a tie between 6rd = and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. >=20 From shemant@cisco.com Thu May 17 07:08:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1602C21F861D for ; Thu, 17 May 2012 07:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpEbdPV1-rGd for ; Thu, 17 May 2012 07:08:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2597621F8616 for ; Thu, 17 May 2012 07:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2290; q=dns/txt; s=iport; t=1337263734; x=1338473334; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0IDlvNq/ip0bqSB4hINZeXAna2UGIdPIM51OZQttPMs=; b=h0tVDDglj5Jc/Xj1DgEH7s5EGfirWBwPxVbthQEPVyHDoMStb8+nvGqS XVl3AuMHtv4Z17ip7vPBpTyLg5UQ/THA1w/E06GRws84B2YRx+UkSHniO jHVDSBqkzZBqDWePBtn91Y/oG385BdMGK/i6MnnsLoAYFWUKrrjrtKnbF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABwGtU+tJXG8/2dsb2JhbABEs0GBB4IVAQEBAwESAR0KPwwEAgEIEQQBAQEKBhcBBgFFCQgBAQQBEggah2cFnAGgB4sThHViA4hjm26BaYMH X-IronPort-AV: E=Sophos;i="4.75,610,1330905600"; d="scan'208";a="84124644" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 17 May 2012 14:08:42 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4HE8cIg012210; Thu, 17 May 2012 14:08:41 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 09:08:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 May 2012 09:08:30 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8D107@XMB-RCD-109.cisco.com> In-Reply-To: <5B8E85A2-8BF0-4408-AB8C-FB7F4C306B3B@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements (for -09) Thread-Index: Ac00LxTrD6ODqE7aTtaAhzJc9wSo0wAB24uA References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <4FA81137.7070907@bogus.com> <5B8E85A2-8BF0-4408-AB8C-FB7F4C306B3B@townsley.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" , "Joel jaeggli" X-OriginalArrivalTime: 17 May 2012 14:08:31.0620 (UTC) FILETIME=[8A43F440:01CD3436] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (for -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: Thu, 17 May 2012 14:08:55 -0000 Mark, Will fix it. Thanks, Hemant -----Original Message----- From: Mark Townsley [mailto:mark@townsley.net]=20 Sent: Thursday, May 17, 2012 9:15 AM To: Joel jaeggli Cc: Hemant Singh (shemant); Chris Donley; Gert Doering; Randy Bush; IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (for -09) FYI:=20 6RD-5 in the -09 text out today did not include the clarification requested by Gert and Randy mentioned below: -09 reads: "the upstream network the WAN interface is connected to" It should be: "the particular interface from which the packet is being sent"=20 Seems to just be an editorial oversight.=20 - Mark On May 8, 2012, at 1:29 AM, Mark Townsley wrote: >=20 >=20 > On May 7, 2012, at 8:15 PM, Joel jaeggli wrote: >=20 >> I'm sitting here waiting for an 09 version of the draft so that I can >> expose the diffs to the list, test whether we need to need to reconsider >> the WGLC, and send a shepherds report to the IESG if not. The longer >> temporally and the more diveregent the document gets the more likely it >> is imho that we need to reconsider the wg consensus on publication, but >> we don't know because it's not in the tool yet. >=20 > Here are the latest requirements that Chris, Hemant, Wes and I finally agreed upon (posted at "version 3" the other day), plus the specific text changes to 6RD-5 as suggested by Gert and Randy. I believe Hemant has the draft pen.=20 >=20 > 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that the packet's source IP address is derived from a delegated prefix associated with the particular interface from which the packet is being sent [Section 4.3 [RFC3704]]. >=20 > 6RD-6: The CE router MUST allow different as well as identical delegated prefixes to be configured via each (6rd or native) WAN interface. =20 >=20 > 6RD-7: In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. >=20 From Fred.L.Templin@boeing.com Thu May 17 08:39:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7566321F858A for ; Thu, 17 May 2012 08:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUalR1THpIJY for ; Thu, 17 May 2012 08:39:25 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 52C4221F8582 for ; Thu, 17 May 2012 08:39:22 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4HFdF7U020224 for ; Thu, 17 May 2012 08:39:15 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4HFdFlN020221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 17 May 2012 08:39:15 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4HFdKbU012175 for ; Thu, 17 May 2012 08:39:20 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4HFdKsI011935 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 17 May 2012 08:39:20 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 17 May 2012 08:39:20 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Date: Thu, 17 May 2012 08:39:18 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00LaLdLMvjzCcwRq6Tbz0GWRGQogAERNlQ Message-ID: 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 X-TM-AS-MML: No Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 15:39:26 -0000 Folks, it's not just about MSS clamping at the 6rd CPE; the MTU of the whole IPv6 path has to be considered. Let's say the CPE rewrites MSS to 1440, but there is a 1400 IPv6 link somewhere in the Internet path to the final destination. The result is IPv6 PMTUD invocation, but folks here seem to have doubts about the viability of IPv6 PMTDU. But let's look at that: if IPv6 PMTUD is broken then tunnels or no tunnels we are sunk - if we do nothing else, then the only choice is to set all IPv6 host interfaces to 1280. If we push for host deployment of RFC4821, however, hosts get to live in the MTU diversity world. Jumbogram support becomes a natural benefit of that, but we can leave jumbograms out of the discussion since the problem exists for *any* MTU greater than 1280. Again, tunnels or no tunnels if we can't rely on IPv6 PMTUD the only recourse is for IPv6 hosts to set their IPv6 interface MTUs to 1280 - unless they use RFC4821. Turning back to 6rd tunnels, if the tunnel picks an MTU and/or MSS clamping value that it *thinks* will be safe, then there will always be cases when it guesses wrong. If the 6rd egress tunnel endpoint has a way of returning reliable IPv6 PMTUD feedback to the 6rd ingress tunnel endpoint, however, then the tunnel can safely forget about MSS clamping and can even set a larger MTU without fear of black holing. We have an opportunity here to fix IPv6 PMTUD once and for all rather than apply a best-guess band-aid solution and pass the buck to someone else. Fred fred.l.templin@boeing.com From dr@cluenet.de Thu May 17 09:25:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5921F862B for ; Thu, 17 May 2012 09:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOtYSpGLQ7Ga for ; Thu, 17 May 2012 09:25:29 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id A631A21F85F0 for ; Thu, 17 May 2012 09:25:29 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 43527108379; Thu, 17 May 2012 18:25:26 +0200 (CEST) Date: Thu, 17 May 2012 18:25:26 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120517162526.GA4385@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 16:25:30 -0000 On Thu, May 17, 2012 at 08:39:18AM -0700, Templin, Fred L wrote: > We have an opportunity here to fix IPv6 PMTUD once > and for all rather than apply a best-guess band-aid > solution and pass the buck to someone else. For IPv6, perhaps. But not for IPv4, and that's what needs to be considered for the DS-Lite case. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Fred.L.Templin@boeing.com Thu May 17 09:28:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D49C21F85D6 for ; Thu, 17 May 2012 09:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt4MN4THpCvP for ; Thu, 17 May 2012 09:28:44 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE0121F85D5 for ; Thu, 17 May 2012 09:28:44 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4HGSiTi024915 for ; Thu, 17 May 2012 09:28:44 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4HGShsV024911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 May 2012 09:28:43 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4HGShlN013272; Thu, 17 May 2012 09:28:43 -0700 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4HGSg4B013242 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 May 2012 09:28:42 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 17 May 2012 09:28:42 -0700 From: "Templin, Fred L" To: Daniel Roesen , "v6ops@ietf.org" Date: Thu, 17 May 2012 09:28:41 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00SbH4oeDBcLPqRyCsQeZk5j+3DAAABR2A Message-ID: References: <20120517162526.GA4385@srv03.cluenet.de> In-Reply-To: <20120517162526.GA4385@srv03.cluenet.de> 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] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 16:28:45 -0000 Hi Daniel, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Daniel Roesen > Sent: Thursday, May 17, 2012 9:25 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > On Thu, May 17, 2012 at 08:39:18AM -0700, Templin, Fred L wrote: > > We have an opportunity here to fix IPv6 PMTUD once > > and for all rather than apply a best-guess band-aid > > solution and pass the buck to someone else. >=20 > For IPv6, perhaps. But not for IPv4, and that's what needs to be > considered for the DS-Lite case. AFAICT, RFC4821 works for IPv4 paths the same as it does for IPv6 paths. Or, maybe you are concerned as to what role the DS-Lite tunnel has to play in MTU handling. Can you educate me on the issues? Thanks - Fred fred.l.templin@boeing.com > Best regards, > Daniel >=20 > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Thu May 17 09:45:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B50621F8680 for ; Thu, 17 May 2012 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.866 X-Spam-Level: X-Spam-Status: No, score=-9.866 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz8Fu2i-s69b for ; Thu, 17 May 2012 09:45:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAB921F8630 for ; Thu, 17 May 2012 09:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3363; q=dns/txt; s=iport; t=1337273101; x=1338482701; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zZ2Iv6XBoVKuTc+FtM9RALSCaXcEUVAtHu0Py+e01yA=; b=UktEFvNMJJu9obSmZdw+c7SSbdvLq6oMJsXA5pvnWGWvwVDmCFlX39ei AcBznZMMcm1i5PaAiSqK/kbznVVkxJvnGR7CpgnUR7eUACKZUjZBvbyp8 lcOrrhOyMFN+sY5roRtrNVOsfjjryzyX3JH0+s//7P4eTLCTundrrmv4k A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABMqtU+tJV2a/2dsb2JhbABEsz2BB4IVAQEBAwESAR0KPwwEAgEIEQQBAQEKBhcBBgFFCQgBAQQBEggah2cFnAGgCYsThHViA4hjm26BaYMH X-IronPort-AV: E=Sophos;i="4.75,611,1330905600"; d="scan'208";a="84177888" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 17 May 2012 16:45:00 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4HGj0k5016863; Thu, 17 May 2012 16:45:00 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 11:45:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 May 2012 11:44:59 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304A8D21C@XMB-RCD-109.cisco.com> In-Reply-To: <5B8E85A2-8BF0-4408-AB8C-FB7F4C306B3B@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements (for -09) Thread-Index: Ac00LxTrD6ODqE7aTtaAhzJc9wSo0wAHSLVg References: <4FA29E69.1040304@viagenie.ca> <2D09D61DDFA73D4C884805CC7865E6110BC4C4@GAALPA1MSGUSR9N.ITServices.sbc.com> <4FA2B838.6000703@viagenie.ca> <0D55D394-6DB6-47EC-8F29-5132627687BF@townsley.net> <4FA3D663.8080708@viagenie.ca> <867F4B6A1672E541A94676D556793ACD10E2185811@MOPESMBX01.eu.thmulti.com> <4FA3DC3C.7090602@viagenie.ca> <50B4D10A-7367-4821-B81F-8B8648C2FE92@huawei.com> <867F4B6A1672E541A94676D556793ACD10E2185908@MOPESMBX01.eu.thmulti.com> <20120507093834.GI84425@Space.Net> <867F4B6A1672E541A94676D556793ACD10E2185AD9@MOPESMBX01.eu.thmulti.com> <4FA81137.7070907@bogus.com> <5B8E85A2-8BF0-4408-AB8C-FB7F4C306B3B@townsley.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" , "Joel jaeggli" X-OriginalArrivalTime: 17 May 2012 16:45:00.0380 (UTC) FILETIME=[666709C0:01CD344C] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (for -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: Thu, 17 May 2012 16:45:03 -0000 Mark, Please see if this revised text works for you? In the -09 I had incorporated what was version -03 mailed out by you to v6ops. Once you approve, I can post a -10. 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migration period such as a migration from 6rd to native IPv6. 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the particular interface from which the packet is being sent[Section 4.3 [RFC3704]]. 6RD-6: The CE router MUST allow different as well as identical delegated prefixes to be configured via each (6rd or native) WAN interface. 6RD-7: In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. Thanks, Hemant -----Original Message----- From: Mark Townsley [mailto:mark@townsley.net]=20 Sent: Thursday, May 17, 2012 9:15 AM To: Joel jaeggli Cc: Hemant Singh (shemant); Chris Donley; Gert Doering; Randy Bush; IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (for -09) FYI:=20 6RD-5 in the -09 text out today did not include the clarification requested by Gert and Randy mentioned below: -09 reads: "the upstream network the WAN interface is connected to" It should be: "the particular interface from which the packet is being sent"=20 Seems to just be an editorial oversight.=20 - Mark On May 8, 2012, at 1:29 AM, Mark Townsley wrote: >=20 >=20 > On May 7, 2012, at 8:15 PM, Joel jaeggli wrote: >=20 >> I'm sitting here waiting for an 09 version of the draft so that I can >> expose the diffs to the list, test whether we need to need to reconsider >> the WGLC, and send a shepherds report to the IESG if not. The longer >> temporally and the more diveregent the document gets the more likely it >> is imho that we need to reconsider the wg consensus on publication, but >> we don't know because it's not in the tool yet. >=20 > Here are the latest requirements that Chris, Hemant, Wes and I finally agreed upon (posted at "version 3" the other day), plus the specific text changes to 6RD-5 as suggested by Gert and Randy. I believe Hemant has the draft pen.=20 >=20 > 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that the packet's source IP address is derived from a delegated prefix associated with the particular interface from which the packet is being sent [Section 4.3 [RFC3704]]. >=20 > 6RD-6: The CE router MUST allow different as well as identical delegated prefixes to be configured via each (6rd or native) WAN interface. =20 >=20 > 6RD-7: In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. >=20 From Jean-Francois.TremblayING@videotron.com Thu May 17 09:46:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6D21F865C; Thu, 17 May 2012 09:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4HmLt+s2jnH; Thu, 17 May 2012 09:46:32 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8193C21F8652; Thu, 17 May 2012 09:46:32 -0700 (PDT) In-Reply-To: To: Fred.L.Templin@boeing.com MIME-Version: 1.0 X-KeepSent: 7F75066D:7153D4D3-85257A01:005A8AB0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 17 May 2012 12:46:23 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP1|March 07, 2012) at 05/17/2012 12:46:27, Serialize complete at 05/17/2012 12:46:27 Content-Type: multipart/alternative; boundary="=_alternative 005C24BA85257A01_=" Received-SPF: none Cc: "v6ops@ietf.org" , v6ops-bounces@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 16:46:33 -0000 Message en plusieurs parties au format MIME --=_alternative 005C24BA85257A01_= Content-Type: text/plain; charset="US-ASCII" > Turning back to 6rd tunnels, if the tunnel picks an > MTU and/or MSS clamping value that it *thinks* will > be safe, then there will always be cases when it > guesses wrong. Agreed. Whatever value is picked will always end up wrong in some cases. But speaking of 6RD, we can guess one that will be right most of the time (1480!). > If the 6rd egress tunnel endpoint has > a way of returning reliable IPv6 PMTUD feedback to the > 6rd ingress tunnel endpoint, however, then the tunnel > can safely forget about MSS clamping and can even set > a larger MTU without fear of black holing. Not sure I get your point. The issue with PMTUD is not within the tunnel domain most of the time. It is between the egress point and any host on the Internet that blocks ICMPv6 (in short, any content provider behind a firewall blocking incoming ICMPv6). > We have an opportunity here to fix IPv6 PMTUD once > and for all rather than apply a best-guess band-aid > solution and pass the buck to someone else. There's no opportunity to fix IPv6 PMTUD here. Fixing it will be a constant and long-term battle to educate content holders and other actors they have to let ICMPv6 through or rate-limit it in a reasonable way (my opinion). /JF --=_alternative 005C24BA85257A01_= Content-Type: text/html; charset="US-ASCII"
> Turning back to 6rd tunnels, if the tunnel picks an
> MTU and/or MSS clamping value that it *thinks* will
> be safe, then there will always be cases when it
> guesses wrong.

Agreed. Whatever value is picked will always end up
wrong in some cases. But speaking of 6RD, we can
guess one that will be right most of the time (1480!).

> If the 6rd egress tunnel endpoint has
> a way of returning reliable IPv6 PMTUD feedback to the
> 6rd ingress tunnel endpoint, however, then the tunnel
> can safely forget about MSS clamping and can even set
> a larger MTU without fear of black holing.
Not sure I get your point. The issue with PMTUD is
not within the tunnel domain most of the time. It is
between the egress point and any host on the Internet
that blocks ICMPv6 (in short, any content provider
behind a firewall blocking incoming ICMPv6).

> We have an opportunity here to fix IPv6 PMTUD once
> and for all rather than apply a best-guess band-aid
> solution and pass the buck to someone else.

There's no opportunity to fix IPv6 PMTUD here. Fixing
it will be a constant and long-term battle to educate
content holders and other actors they have to let ICMPv6
through or rate-limit it in a reasonable way (my opinion).

/JF

--=_alternative 005C24BA85257A01_=-- From Fred.L.Templin@boeing.com Thu May 17 10:06:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B77221F86BB; Thu, 17 May 2012 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nop+EbLZQqlj; Thu, 17 May 2012 10:06:54 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 78B4721F86C6; Thu, 17 May 2012 10:06:54 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4HH6s8Q022129; Thu, 17 May 2012 10:06:54 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4HH6r7x022126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 May 2012 10:06:53 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4HH6r9x014365; Thu, 17 May 2012 10:06:53 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4HH6qDJ014333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 May 2012 10:06:52 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Thu, 17 May 2012 10:06:52 -0700 From: "Templin, Fred L" To: "Jean-Francois.TremblayING@videotron.com" Date: Thu, 17 May 2012 10:06:50 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00TJ22nplpUxbVT7WW3DPpWXmWegAAPSsg Message-ID: 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 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 17:06:55 -0000 From: Jean-Francois.TremblayING@videotron.com [mailto:Jean-Francois.TremblayING@videotron.com]=20 Sent: Thursday, May 17, 2012 9:46 AM To: Templin, Fred L Cc: v6ops@ietf.org; v6ops-bounces@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >> Turning back to 6rd tunnels, if the tunnel picks an >> MTU and/or MSS clamping value that it *thinks* will >> be safe, then there will always be cases when it >> guesses wrong.=20 > > Agreed. Whatever value is picked will always end up=20 > wrong in some cases. But speaking of 6RD, we can=20 > guess one that will be right most of the time (1480!). 6rd can only guess for a single IPv6 hop. There may be many IPv6 hops in the path, but 6rd can only control one of them. The only guiding standard we have is that the IPv6 minMTU is 1280, so there is no way for 6rd to assume anything more. >> If the 6rd egress tunnel endpoint has >> a way of returning reliable IPv6 PMTUD feedback to the >> 6rd ingress tunnel endpoint, however, then the tunnel >> can safely forget about MSS clamping and can even set >> a larger MTU without fear of black holing. > > Not sure I get your point. The issue with PMTUD is=20 > not within the tunnel domain most of the time. It is=20 > between the egress point and any host on the Internet=20 > that blocks ICMPv6 (in short, any content provider=20 > behind a firewall blocking incoming ICMPv6). The tunnel ingress needs to know when it needs to send an ICMP PTB message back to a host within the 6rd site. Choices are for the ingress to set a conservative MTU (e.g., 1280) or set an unbounded MTU if it has a way of getting reliable PMTUD feedback from the tunnel egress. That way, hosts can expect to see 1500 or more in most cases. =20 >> We have an opportunity here to fix IPv6 PMTUD once >> and for all rather than apply a best-guess band-aid >> solution and pass the buck to someone else.=20 > > There's no opportunity to fix IPv6 PMTUD here. Fixing Why not? We have outlined tools and strategies that will get the job done. =20 > it will be a constant and long-term battle to educate=20 > content holders and other actors they have to let ICMPv6=20 > through or rate-limit it in a reasonable way (my opinion). That kind of strategy is doomed to failure. We can't tell the operators how to configure their links and middleboxes - the right approach is to control the hosts and to control the links that we have control over (e.g., the 6rd tunnel). Fred fred.l.templin@boeing.com PS Please can we stop with the html/rtf text and stick to plaintext?=20 From Jean-Francois.TremblayING@videotron.com Thu May 17 10:23:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD9121F8549; Thu, 17 May 2012 10:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er9uqAAnfmq8; Thu, 17 May 2012 10:23:34 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id A602221F8546; Thu, 17 May 2012 10:23:33 -0700 (PDT) In-Reply-To: To: Fred.L.Templin@boeing.com MIME-Version: 1.0 X-KeepSent: 0C03D2E9:2ED77774-85257A01:005ECBB0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 17 May 2012 13:23:18 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP1|March 07, 2012) at 05/17/2012 13:23:22, Serialize complete at 05/17/2012 13:23:22 Content-Type: multipart/alternative; boundary="=_alternative 005F860C85257A01_=" Received-SPF: none Cc: "v6ops@ietf.org" , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 17:23:36 -0000 Message en plusieurs parties au format MIME --=_alternative 005F860C85257A01_= Content-Type: text/plain; charset="US-ASCII" > The tunnel ingress needs to know when it needs to send > an ICMP PTB message back to a host within the 6rd site. This is not an issue. In a residential scenario, the tunnel ingress is the CPE and it's usually a single L2 domain. There's nothing block PTB in that case, as long as the CPE sends it. You have to look at it the other way. When a content provider starts sending large packets, the PTB will be generated at the 6RD BR back to the server. This is where it gets blocked IMO. > That kind of strategy is doomed to failure. We can't > tell the operators how to configure their links and > middleboxes - the right approach is to control the > hosts and to control the links that we have control > over (e.g., the 6rd tunnel). Glad that you see it that way. However the issue is not operators, this is a relatively small and educated crowd. The issue is the much larger crowd of "content providers" out there, which is basically any native IPv6 host with a firewall. /JF --=_alternative 005F860C85257A01_= Content-Type: text/html; charset="US-ASCII"
> The tunnel ingress needs to know when it needs to send
> an ICMP PTB message back to a host within the 6rd site.

This is not an issue. In a residential scenario, the
tunnel ingress is the CPE and it's usually a single
L2 domain. There's nothing block PTB in that case,
as long as the CPE sends it.

You have to look at it the other way. When a content
provider starts sending large packets, the PTB will
be generated at the 6RD BR back to the server. This
is where it gets blocked IMO.

> That kind of strategy is doomed to failure. We can't
> tell the operators how to configure their links and
> middleboxes - the right approach is to control the
> hosts and to control the links that we have control
> over (e.g., the 6rd tunnel).

Glad that you see it that way. However the issue is
not operators, this is a relatively small and educated
crowd. The issue is the much larger crowd of "content
providers" out there, which is basically any native
IPv6 host with a firewall.

/JF
--=_alternative 005F860C85257A01_=-- From Fred.L.Templin@boeing.com Thu May 17 10:36:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156C921F86EE; Thu, 17 May 2012 10:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIRqYZHX6JB9; Thu, 17 May 2012 10:36:32 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5680C21F8643; Thu, 17 May 2012 10:36:32 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4HHaVvx018492; Thu, 17 May 2012 12:36:31 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4HHaUdr018198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 May 2012 12:36:31 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4HHaUrh014288; Thu, 17 May 2012 10:36:30 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4HHaUsS014274 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 May 2012 10:36:30 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Thu, 17 May 2012 10:36:29 -0700 From: "Templin, Fred L" To: "Jean-Francois.TremblayING@videotron.com" Date: Thu, 17 May 2012 10:36:29 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00UdKnFfU5TIdfR4q1bTUT1RWOogAAEp/A Message-ID: 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 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 17:36:33 -0000 Looks like you ignored my request for plaintext (thus making two-way conversation difficult) but see below: From: Jean-Francois.TremblayING@videotron.com [mailto:Jean-Francois.TremblayING@videotron.com]=20 Sent: Thursday, May 17, 2012 10:23 AM To: Templin, Fred L Cc: v6ops@ietf.org; v6ops-bounces@ietf.org Subject: RE: [v6ops] proposed TCP MSS text for rfc6204bis >> The tunnel ingress needs to know when it needs to send >> an ICMP PTB message back to a host within the 6rd site.=20 > > This is not an issue. In a residential scenario, the=20 > tunnel ingress is the CPE and it's usually a single=20 > L2 domain. There's nothing block PTB in that case,=20 > as long as the CPE sends it. Yes, the going-in assumption is that the ICMP PTB coming from the CPE will not be blocked from reaching the host within the CPE's site. But, the hosts would be much better off if they saw a solid 1500 or larger MTU. The only way the CPE's 6rd tunnel can do that is by statelessly measuring the path MTU from the tunnel ingress to tunnel egress.=20 > You have to look at it the other way. When a content=20 > provider starts sending large packets, the PTB will=20 > be generated at the 6RD BR back to the server. This=20 > is where it gets blocked IMO. Sure. In that case, the CPE's 6rd tunnel endpoint becomes the egress. Since the 6rd tunnel has absolutely no control over the path MTU outside of the 6rd ISP, however, the best the 6rd tunnel can do is 1280 - that is, if we assume IPv6 PMTUD is broken. In that case, the Internet servers should also implement RFC4821.=20 >> That kind of strategy is doomed to failure. We can't >> tell the operators how to configure their links and >> middleboxes - the right approach is to control the >> hosts and to control the links that we have control >> over (e.g., the 6rd tunnel).=20 > > Glad that you see it that way. However the issue is=20 > not operators, this is a relatively small and educated=20 > crowd. The issue is the much larger crowd of "content=20 > providers" out there, which is basically any native=20 > IPv6 host with a firewall. The content providers deploy servers that will help them make money. If they want to avoid complaints from customers and loss of revenues, they will implement RFC4821. Thanks - Fred fred.l.templin@boeing.com From Jean-Francois.TremblayING@videotron.com Thu May 17 11:19:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592AE21F870E; Thu, 17 May 2012 11:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z4DbDhh5WGx; Thu, 17 May 2012 11:19:02 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 9D58C21F8720; Thu, 17 May 2012 11:19:02 -0700 (PDT) In-Reply-To: To: Fred.L.Templin@boeing.com MIME-Version: 1.0 X-KeepSent: 1AE27B29:004A8B88-85257A01:00629FA3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 17 May 2012 14:18:48 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP1|March 07, 2012) at 05/17/2012 14:18:51, Serialize complete at 05/17/2012 14:18:51 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Received-SPF: none Cc: "v6ops@ietf.org" , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 18:19:03 -0000 "Templin, Fred L" a =E9crit sur 17/05/2012=20 01:36:29 PM : > Looks like you ignored my request for plaintext > (thus making two-way conversation difficult) but > see below: Apologies. Working with a weird email client (is this better?).=20 > The only way the CPE's 6rd tunnel can do that is > by statelessly measuring the path MTU from the tunnel > ingress to tunnel egress.=20 Statelessness and measuring are self-conflicting. No need to reinvent PMTUD here, it usually works fine locally to=20 the ISP toward the client.=20 > The content providers deploy servers that will help > them make money. If they want to avoid complaints from > customers and loss of revenues, they will implement > RFC4821. Service providers feel the pain first here. Residential customers will call tech support before complaining to=20 the content provider.=20 We converged to the same conclusion here, content providers have to make sure PTMUD works. We only disagree on the=20 timing where they *most* will be compliant, which is=20 "not any time soon" in my opinion. This is why the CPE running 6RD should just lower the MTU in the RA and not=20 rely on the content providers.=20 /JF From Fred.L.Templin@boeing.com Thu May 17 12:41:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED1B21F8838; Thu, 17 May 2012 12:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qslr5Z46BahP; Thu, 17 May 2012 12:41:53 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 13BEB21F8835; Thu, 17 May 2012 12:41:53 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4HJfqfd020604; Thu, 17 May 2012 12:41:52 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4HJfpHg020594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 May 2012 12:41:52 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4HJfpKE020565; Thu, 17 May 2012 12:41:51 -0700 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4HJfp4V020542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 May 2012 12:41:51 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Thu, 17 May 2012 12:41:50 -0700 From: "Templin, Fred L" To: "Jean-Francois.TremblayING@videotron.com" Date: Thu, 17 May 2012 12:41:49 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00WYaEp54KSfJdSNqeWMG7knmFcwABYf/w Message-ID: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 19:41:53 -0000 Hi JF, > -----Original Message----- > From: Jean-Francois.TremblayING@videotron.com [mailto:Jean- > Francois.TremblayING@videotron.com] > Sent: Thursday, May 17, 2012 11:19 AM > To: Templin, Fred L > Cc: v6ops@ietf.org; v6ops-bounces@ietf.org > Subject: RE: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > "Templin, Fred L" a =E9crit sur 17/05/2012 > 01:36:29 PM : > > Looks like you ignored my request for plaintext > > (thus making two-way conversation difficult) but > > see below: >=20 > Apologies. Working with a weird email client (is this better?). Much better - thanks. > > The only way the CPE's 6rd tunnel can do that is > > by statelessly measuring the path MTU from the tunnel > > ingress to tunnel egress. >=20 > Statelessness and measuring are self-conflicting. No need No - not at all. If the egress sees a fragment of an IPv6-in-IPv4 encapsulated packet, it can tell the ingress how big the fragment was and the ingress can use that size to statelessly report back to the original source. Or, if the size of the fragment is not helpful then the ingress consults a plateau table and again statelessly reports back to the original source. > to reinvent PMTUD here, it usually works fine locally to > the ISP toward the client. No reinvention; just a link-local adaptation to determine the MTU of the link. It observes RFC1981 PMTUD in all senses. > > The content providers deploy servers that will help > > them make money. If they want to avoid complaints from > > customers and loss of revenues, they will implement > > RFC4821. >=20 > Service providers feel the pain first here. Residential > customers will call tech support before complaining to > the content provider. >=20 > We converged to the same conclusion here, content providers > have to make sure PTMUD works. We only disagree on the > timing where they *most* will be compliant, which is > "not any time soon" in my opinion. This is why the CPE > running 6RD should just lower the MTU in the RA and not > rely on the content providers. In an IPv6 PMTUD-broken world, lowering MTU is imperfect unless you lower it all the way down to 1280. You'd be better off leaving it at 1500 if you can get the 6rd tunnel to do 1500. Thanks - Fred fred.l.templin@boeing.com > /JF From gert@space.net Thu May 17 12:51:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8C521F8828 for ; Thu, 17 May 2012 12:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9fNqMM7jbh2 for ; Thu, 17 May 2012 12:51:14 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F03121F8826 for ; Thu, 17 May 2012 12:51:13 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2E848F8BE1 for ; Thu, 17 May 2012 21:51:12 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 45B2DF8BDE for ; Thu, 17 May 2012 21:51:10 +0200 (CEST) Received: (qmail 10247 invoked by uid 1007); 17 May 2012 21:51:10 +0200 Date: Thu, 17 May 2012 21:51:10 +0200 From: Gert Doering To: Hesham Soliman Message-ID: <20120517195110.GJ84425@Space.Net> References: <20120517114252.GI84425@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+I6ex9Au3CY2gPfG" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 19:51:14 -0000 --+I6ex9Au3CY2gPfG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, May 17, 2012 at 10:00:27PM +1000, Hesham Soliman wrote: > =3D> Yes of course, so what's the comment? MSS editing has nothing to do > with any other MTU on the Internet either. I'm not advocating MSS editing for IPv6. IPv6 PMTU works - and where it breaks, it needs to be fixed. For IPv4 (ds-lite etc.), MSS rewriting is unavoidable as IPv4 PMTU doesn't work. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --+I6ex9Au3CY2gPfG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT7VWrqkuBuNlUUl1AQIATgP+J3Dwdf0UW+LxpyMNBvWR8gaE7ZOI2F0M DHis6t+fe/VIZHPuba6pf+mnda2LHLmFwm9r23GoN/08R5dLJI3wguZIheuEazHy Q4x7MdKhGlBY44owqhqyUIKZs2qPBicW3yAa1MvKWIdqegHs7vryWm9RIqdobX0f N4TU2E0IUmE= =uI5f -----END PGP SIGNATURE----- --+I6ex9Au3CY2gPfG-- From Fred.L.Templin@boeing.com Thu May 17 12:52:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B1921F8775; Thu, 17 May 2012 12:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4TbaO8qXdIT; Thu, 17 May 2012 12:52:49 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED4421F86BA; Thu, 17 May 2012 12:52:49 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4HJqkHa012107; Thu, 17 May 2012 12:52:46 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4HJqk5c012104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 May 2012 12:52:46 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4HJqkiu021598; Thu, 17 May 2012 12:52:46 -0700 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4HJqjwF021558 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 May 2012 12:52:46 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 17 May 2012 12:52:45 -0700 From: "Templin, Fred L" To: "Jean-Francois.TremblayING@videotron.com" Date: Thu, 17 May 2012 12:52:44 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00WYaEp54KSfJdSNqeWMG7knmFcwABYf/wAAHU84A= Message-ID: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 May 2012 19:52:50 -0000 BTW, the reason for my delay in responding is that I am on a confcall with a major Internet firewall product manufacturer. I just asked him "does your product by default block ICMPv6 messages coming into and out of the site", and his answer was "no - you cannot operate an IPv6 network w/o ICMPs". Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Thursday, May 17, 2012 12:42 PM > To: Jean-Francois.TremblayING@videotron.com > Cc: v6ops@ietf.org; v6ops-bounces@ietf.org > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > Hi JF, >=20 > > -----Original Message----- > > From: Jean-Francois.TremblayING@videotron.com [mailto:Jean- > > Francois.TremblayING@videotron.com] > > Sent: Thursday, May 17, 2012 11:19 AM > > To: Templin, Fred L > > Cc: v6ops@ietf.org; v6ops-bounces@ietf.org > > Subject: RE: [v6ops] proposed TCP MSS text for rfc6204bis > > > > "Templin, Fred L" a =E9crit sur 17/05/2012 > > 01:36:29 PM : > > > Looks like you ignored my request for plaintext > > > (thus making two-way conversation difficult) but > > > see below: > > > > Apologies. Working with a weird email client (is this better?). >=20 > Much better - thanks. >=20 > > > The only way the CPE's 6rd tunnel can do that is > > > by statelessly measuring the path MTU from the tunnel > > > ingress to tunnel egress. > > > > Statelessness and measuring are self-conflicting. No need >=20 > No - not at all. If the egress sees a fragment of an > IPv6-in-IPv4 encapsulated packet, it can tell the > ingress how big the fragment was and the ingress > can use that size to statelessly report back to the > original source. Or, if the size of the fragment is > not helpful then the ingress consults a plateau > table and again statelessly reports back to the > original source. >=20 > > to reinvent PMTUD here, it usually works fine locally to > > the ISP toward the client. >=20 > No reinvention; just a link-local adaptation to determine > the MTU of the link. It observes RFC1981 PMTUD in all > senses. >=20 > > > The content providers deploy servers that will help > > > them make money. If they want to avoid complaints from > > > customers and loss of revenues, they will implement > > > RFC4821. > > > > Service providers feel the pain first here. Residential > > customers will call tech support before complaining to > > the content provider. > > > > We converged to the same conclusion here, content providers > > have to make sure PTMUD works. We only disagree on the > > timing where they *most* will be compliant, which is > > "not any time soon" in my opinion. This is why the CPE > > running 6RD should just lower the MTU in the RA and not > > rely on the content providers. >=20 > In an IPv6 PMTUD-broken world, lowering MTU is imperfect > unless you lower it all the way down to 1280. You'd be > better off leaving it at 1500 if you can get the 6rd > tunnel to do 1500. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > /JF >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marka@isc.org Thu May 17 17:26:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31E021F8736 for ; Thu, 17 May 2012 17:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJV7cvo-QR-B for ; Thu, 17 May 2012 17:26:51 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 49A7321F870F for ; Thu, 17 May 2012 17:26:50 -0700 (PDT) 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 id B16C8C971A for ; Fri, 18 May 2012 00:26:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:bd04:a487:7cc9:3875]) (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 733C9216C33 for ; Fri, 18 May 2012 00:26:38 +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 B26BB20B53D3 for ; Fri, 18 May 2012 10:26:37 +1000 (EST) To: v6ops@ietf.org From: Mark Andrews References: <20120517162526.GA4385@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org In-reply-to: Your message of "Thu, 17 May 2012 18:25:26 +0200." <20120517162526.GA4385@srv03.cluenet.de> Date: Fri, 18 May 2012 10:26:37 +1000 Message-Id: <20120518002637.B26BB20B53D3@drugs.dv.isc.org> Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 00:26:51 -0000 In message <20120517162526.GA4385@srv03.cluenet.de>, Daniel Roesen writes: > On Thu, May 17, 2012 at 08:39:18AM -0700, Templin, Fred L wrote: > > We have an opportunity here to fix IPv6 PMTUD once > > and for all rather than apply a best-guess band-aid > > solution and pass the buck to someone else. > > For IPv6, perhaps. But not for IPv4, and that's what needs to be > considered for the DS-Lite case. IPv4 will still be in use for a decade or more. The same fix works for TCP for both IPv4 and IPv6. Get the OS vendors to deploy and back port RFC4821 support to all boxes that support IPv6. This will pickup mose IPv4 stacks in use as well. Remember PMTUD works unless people deliberately stuff it up by blocking ICMP messages which are part of the base protocol. If you start filtering you really need to know what you are doing. A directed broadcast ping bomb from 2 decades ago is no excuse to block ICMP today. Firewall have selective ICMP filtering. > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > 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 shtsuchi@cisco.com Thu May 17 18:14:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0F21F881A for ; Thu, 17 May 2012 18:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc-LotQf0j3t for ; Thu, 17 May 2012 18:14:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7663421F8811 for ; Thu, 17 May 2012 18:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=953; q=dns/txt; s=iport; t=1337303697; x=1338513297; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lXaoLpluH0nkaqWD76oIHKKzjqPWvbjji+KO6JpfqbQ=; b=Rj8OQsGt9xRE0r55hfk9XruJJQWFXG03XVM7khLiHEySMc8bWV2r6hz9 1pQjLAKqd5cRPGW/j9WEdcRAKj6epH86esaG7/mq5Kkaya5TQ/IeUjuG0 9XXd44Jrtumk0funiXQMtCwKoBE7W3MvU+TMb09V7oQOVH8OH9/HM2mb5 I=; X-IronPort-AV: E=Sophos;i="4.75,613,1330905600"; d="scan'208";a="138098591" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 May 2012 01:14:56 +0000 Received: from [10.141.32.141] (dhcp-10-141-32-141.cisco.com [10.141.32.141]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4I1EsDJ029932; Fri, 18 May 2012 01:14:55 GMT Message-ID: <4FB5A28B.8000701@cisco.com> Date: Fri, 18 May 2012 10:14:51 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: gert@space.net References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> In-Reply-To: <20120517195110.GJ84425@Space.Net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 01:14:58 -0000 (2012/05/18 4:51), Gert Doering wrote: > Hi, > > On Thu, May 17, 2012 at 10:00:27PM +1000, Hesham Soliman wrote: >> => Yes of course, so what's the comment? MSS editing has nothing to do >> with any other MTU on the Internet either. > > I'm not advocating MSS editing for IPv6. > > IPv6 PMTU works - and where it breaks, it needs to be fixed. I hope so ,but there is problem analysis of IPv6 PMTD. Path MTU Discovery$B!>(B failure cases $B!>(B http://www.attn.jp/maz/p/t/tmp/pmtud-failure-cases-maz.pdf RIPE60 Measurements of IPv6 Path MTU Discovery Behaviour http://ripe60.ripe.net/presentations/Stasiewicz-Measurements_of_IPv6_Path_MTU_Discovery_Behaviour.pdf World IPv6 day report,5%(11/241) websites may have IPv6 Path MTU Discovery problem. http://hide.dnsalias.net/aaaa/worldipv6day.cgi I think the data should not ignore,so CPE requirement document should mention MSS editing as *optional*. Regard, -Shishio From lorenzo@google.com Thu May 17 19:37:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A48F21F8669 for ; Thu, 17 May 2012 19:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBIT1XnF6xa5 for ; Thu, 17 May 2012 19:37:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74F4D21F859A for ; Thu, 17 May 2012 19:37:37 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4001226obb.31 for ; Thu, 17 May 2012 19:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=xUyGn9et1s8KdWH0aNgZhEKUS926qwUKXA9sbTuKpQY=; b=lz2wBCAzR082Ack4UXMuxuwk8zCXzacLJubXDpcIsirYWkqWLM2tZ+dsZZQxk2+8DH koSdWzUjFsVG9Gwr9xKY5lyhtX9HqtM7dIXNoKvvZ33ojr97sKCPaLkwyZmGo+BeOZil ZzHaZxiZ6WwRlOUYNRCphSX/knaunHGSR4Tj7Y24LXGvBHBZSIJxfaF9T4434OvjiAKU 9MI/iAdaGbpZ2FKdGyv/gZofEc/cJXhR1sx9rj2LrjW3zfEuQwVs574bHRxn/Qm+vT8G nRT4IXU/B63Zd/yo893iJGrhKSFpBMzA0kkONMC02RbrlJzrG6fUEKo/r6P1HbhYY8KY FJeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=xUyGn9et1s8KdWH0aNgZhEKUS926qwUKXA9sbTuKpQY=; b=GgRLZ3LPjbXf2XgRLelogoKsNjGun8EwTVsuMiVZKk6iiAArzUEvvHdbVEnH6KzYbT pYFt39+0VTmMhaV0cBbioipm9d0t1ef4bf4kNeOTgpYobWSuX1nILxw15yrcVyruXlJ0 mcRmDrO/IdyU6FEveWf6WHYnBmPwuw39Phk8jiZNcZSXbR9KSg64jrvhExaCt4ePBxWT /uYj33JMRsaxvNXvE9wCWyyrcim9r9L1M+TmDLXdirlEamvy0xPMPWWZ15Gfgp8cffD2 HYiwMZ3aUY92zmiFimABILHmn7oujpooRvGCzGwuK4Y2dWjarNCcbb2I1hktVMz+fE6b 3VYw== Received: by 10.60.14.169 with SMTP id q9mr8820818oec.19.1337308657119; Thu, 17 May 2012 19:37:37 -0700 (PDT) Received: by 10.60.14.169 with SMTP id q9mr8820808oec.19.1337308656924; Thu, 17 May 2012 19:37:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Thu, 17 May 2012 19:37:16 -0700 (PDT) In-Reply-To: <20120518002637.B26BB20B53D3@drugs.dv.isc.org> References: <20120517162526.GA4385@srv03.cluenet.de> <20120518002637.B26BB20B53D3@drugs.dv.isc.org> From: Lorenzo Colitti Date: Fri, 18 May 2012 11:37:16 +0900 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1ee0e73770a04c0466fd4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkYkNGPyPuheSNZHRotKYdGh9OAsqPBWCKFGc6tKsxTmUo4ScXxOvhAHUI3NFbOfqUdS8HkcAt/Dsh0nbW6AcbM7/J1q2dS5fGYSKFyvEEs7tygckaWUNz7TFLk8SgLmk0e3pyB Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 02:37:38 -0000 --e89a8fb1ee0e73770a04c0466fd4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 18, 2012 at 9:26 AM, Mark Andrews wrote: > IPv4 will still be in use for a decade or more. The same fix works > for TCP for both IPv4 and IPv6. Get the OS vendors to deploy and > back port RFC4821 support to all boxes that support IPv6. This > will pickup mose IPv4 stacks in use as well. > > Remember PMTUD works unless people deliberately stuff it up by > blocking ICMP messages which are part of the base protocol. If > you start filtering you really need to know what you are doing. > Lowering the MTU is not a reliability fix, it's a performance optimization. Path MTU discovery needs to work. But path MTU discovery is slow - 1 RTT for every new host you connect to. In the case of 6rd, you know that 100% of hosts outside the home will incur a packet too big, MTU=1480 response, every time, forever. So you can improve performance by lowering the link MTU to 1480. That will have an overhead of 1.3% on LAN-LAN communications compared to 1500 bytes, and will avoid the above latency impact. Path MTU discovery is still needed for the case where there are MTU=1280 (or MTU=x, x<1480) links along the path. What's wrong with this? --e89a8fb1ee0e73770a04c0466fd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 18, 2012 at 9:26 AM, Mark Andrews <mark= a@isc.org> wrote:
IPv4 will still be in use for a decade or more. =A0The sa= me fix works
for TCP for both IPv4 and IPv6. =A0Get the OS vendors to deploy and
back port RFC4821 support to all boxes that support IPv6. =A0This
will pickup mose IPv4 stacks in use as well.

Remember PMTUD works unless people deliberately stuff it up by
blocking ICMP messages which are part of the base protocol. =A0If
you start filtering you really need to know what you are doing.

Lowering the MTU is not a reliability fix, it'= s a performance optimization.

Path MTU discovery n= eeds to work.=A0But path MTU discovery is slow - 1 RTT for every new host y= ou connect to.

In the case of 6rd, you know that 100% of hosts outside= the home will incur a packet too big, MTU=3D1480 response, every time, for= ever. So you can=A0improve performance by lowering the link MTU to 1480.

That will have an overhead of 1.3% on LAN-LAN communica= tions compared to 1500 bytes, and will avoid the above latency impact.

Path MTU discovery is still needed for the case where = there are MTU=3D1280 (or MTU=3Dx, x<1480) links along the path.

What's wrong with this?
--e89a8fb1ee0e73770a04c0466fd4-- From hesham@elevatemobile.com Thu May 17 19:58:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6DB21F8748 for ; Thu, 17 May 2012 19:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=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 RFFk4z24oA3r for ; Thu, 17 May 2012 19:58:40 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 299FF21F873E for ; Thu, 17 May 2012 19:58:39 -0700 (PDT) Received: from [124.188.44.26] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SVDOO-0001wa-R3; Fri, 18 May 2012 12:58:13 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 18 May 2012 12:58:01 +1000 From: Hesham Soliman To: Lorenzo Colitti , Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 02:58:40 -0000 Nothing is wrong with this, it's a simple and logical way of doing things IMO. I find part of the problem here is that people seem to be confused about the role of PMTUD. In the context of the "MSS editing" thread, PMTUD _is_not_relevant_ to the discussion. The discussion is about MSS editing by the CPE to avoid the tunnelling impacts, which are known upfront and have nothing to do with the impacts for the entire path. I don't understand why people keep injecting PMTUD into the discussion when we're talking about this specific case. Hesham -----Original Message----- From: Lorenzo Colitti Date: Fri, 18 May 2012 11:37:16 +0900 To: Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >On Fri, May 18, 2012 at 9:26 AM, Mark Andrews wrote: > >IPv4 will still be in use for a decade or more. The same fix works >for TCP for both IPv4 and IPv6. Get the OS vendors to deploy and >back port RFC4821 support to all boxes that support IPv6. This >will pickup mose IPv4 stacks in use as well. > >Remember PMTUD works unless people deliberately stuff it up by >blocking ICMP messages which are part of the base protocol. If >you start filtering you really need to know what you are doing. > > > >Lowering the MTU is not a reliability fix, it's a performance >optimization. > >Path MTU discovery needs to work. But path MTU discovery is slow - 1 RTT >for every new host you connect to. > >In the case of 6rd, you know that 100% of hosts outside the home will >incur a packet too big, MTU=1480 response, every time, forever. So you >can improve performance by lowering the link MTU to 1480. > >That will have an overhead of 1.3% on LAN-LAN communications compared to >1500 bytes, and will avoid the above latency impact. > >Path MTU discovery is still needed for the case where there are MTU=1280 >(or MTU=x, x<1480) links along the path. > > >What's wrong with this? > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu May 17 20:09:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA1421F8766 for ; Thu, 17 May 2012 20:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=0.061, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzjGcfugl500 for ; Thu, 17 May 2012 20:09:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69EDB21F8759 for ; Thu, 17 May 2012 20:09:30 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4038911obb.31 for ; Thu, 17 May 2012 20:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=rcb8qHKH+lJkRg3DE5QBN5cNajTcGEYROc9wp6pGM8Y=; b=R7LWUdbwUDVGr9X+FKVNxjOBREur3r7q5qRE8+eXJtJrV3IGDVl+KdNIQHYH0B3kR0 4qwofzAx+d7Wh+hHmk+0x0iYENLkvmpaMBkUO9APDD+kJ4aaEwzeRaovIc5d5RoO254b Y4S98DYD+p2WH/Npu6YfEf1BpHjkP8ndlwaRIrfoP3a+kEdCt7a+8uP+9HyJBjQr8qhF MAIM/DtSrR7nlLGNuPjc7+WRuzaWPnn35Rgt80hSwM4qT5j16i/UDcPqAvP8XBBQRS0g 7KF8+hO4lNgVCAd79EZWpWmbjBlyMclmXwVNVA+kigwvHBd4HsQXe4ugdmgMJdSiYjXZ 6Eww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=rcb8qHKH+lJkRg3DE5QBN5cNajTcGEYROc9wp6pGM8Y=; b=TAp7uZ36AYAy5ELt04nI/dI3H85AGVL7tXfOQs9tWiiVSvb8JMk+XVZ4QoeHMg7kqc DoUwtIuoSDuMgxvKUip+R+Bxp+9NdIXmUx/6tzyWuyVy6zV69xGVHTRId+xglYOwNWTo +TLBkbPQF7+VLtJgVtAgtlR6uW20qfjD4Yvo0OuSFcy1rW1al8tU/MSJN7hXBjImoREJ mQEEYsuo7EkMqsbsaon3VeAjO+ySAB+sSIpNxqdBW2RjsEuDx2vJs54IE2VPjbh5mPpF UEhyXt4Uoyre2wBEXX0J7Ud2D/BV4HdsDkOnoMqvrCmwegsRHFRPnlSK15ZFBAnwY/uq QH6g== Received: by 10.182.169.68 with SMTP id ac4mr8727291obc.19.1337310570047; Thu, 17 May 2012 20:09:30 -0700 (PDT) Received: by 10.182.169.68 with SMTP id ac4mr8727284obc.19.1337310569912; Thu, 17 May 2012 20:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Thu, 17 May 2012 20:09:09 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 18 May 2012 12:09:09 +0900 Message-ID: To: Hesham Soliman Content-Type: multipart/alternative; boundary=e89a8f646a21795b0004c046e1af X-System-Of-Record: true X-Gm-Message-State: ALoCoQlLpk+CibptYzxWCtK4NuqSrVwkyhToSOJlO6z9l8uq1cHzeyo51lm5zhXjbFW47CFKsEvdBpHiwOvaKiXmFm52vUEb3FDJqVYYo1GOlV7dR+D1018MZ/mBWrqtxvxVEAWlw169 Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 03:09:31 -0000 --e89a8f646a21795b0004c046e1af Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 18, 2012 at 11:58 AM, Hesham Soliman wrote: > In the context of the "MSS editing" thread, PMTUD _is_not_relevant_ to > the discussion. The discussion is about MSS editing by the CPE to avoid > the tunnelling impacts, which are known upfront and have nothing to do > with the impacts for the entire path. > I think what people are saying is "don't rewrite MSS for IPv6 packets, ever", and they end up talking about PMTUD because MSS rewriting is just a hack to avoid PMTUD (and its possible failures). --e89a8f646a21795b0004c046e1af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 18, 2012 at 11:58 AM, Hesham Soliman= <hesham@elevatemobile.com> wrote:
In the context of the "MSS editing" thread, PMTUD _is_not_relevan= t_ to the=A0discussion. The discussion is about MSS editing by the CPE to a= void the=A0tunnelling impacts, which are known upfront and have nothing to = do with=A0the impacts for the entire path.

I think what people are saying is "do= n't rewrite MSS for IPv6 packets, ever", and they end up talking a= bout PMTUD because MSS rewriting is just a hack to avoid PMTUD (and its pos= sible failures).
--e89a8f646a21795b0004c046e1af-- From hesham@elevatemobile.com Thu May 17 20:40:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C280D21F8684 for ; Thu, 17 May 2012 20:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH-itnrDLShC for ; Thu, 17 May 2012 20:40:45 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43C21F8674 for ; Thu, 17 May 2012 20:40:44 -0700 (PDT) Received: from [124.188.44.26] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SVE3H-00086j-3w; Fri, 18 May 2012 13:40:28 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 18 May 2012 13:40:09 +1000 From: Hesham Soliman To: Lorenzo Colitti Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 03:40:45 -0000 >On Fri, May 18, 2012 at 11:58 AM, Hesham Soliman > wrote: > > >In the context of the "MSS editing" thread, PMTUD _is_not_relevant_ to >the discussion. The discussion is about MSS editing by the CPE to avoid >the tunnelling impacts, which are known upfront and have nothing to do >with the impacts for the entire path. > > > >I think what people are saying is "don't rewrite MSS for IPv6 packets, >ever", and they end up talking about PMTUD because MSS rewriting is just >a hack to avoid PMTUD (and its possible failures). => It seems to be wrongly perceived as a "hack to avoid PMTUD". MSS rewriting only considers a single link, the one connected to the CPE. So it can't be seen as a hack to avoid PMTUD. Just a hack period. Hesham > From marka@isc.org Thu May 17 20:51:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E358021F876A for ; Thu, 17 May 2012 20:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtuvpkutQRq0 for ; Thu, 17 May 2012 20:51:22 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 539DB21F8766 for ; Thu, 17 May 2012 20:51:22 -0700 (PDT) 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 0EBB35F9949; Fri, 18 May 2012 03:51:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1169:dc53:6d84:662b]) (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 5B0A5216C36; Fri, 18 May 2012 03:51:04 +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 4240C20B87F5; Fri, 18 May 2012 13:50:57 +1000 (EST) To: Lorenzo Colitti From: Mark Andrews References: In-reply-to: Your message of "Fri, 18 May 2012 12:09:09 +0900." Date: Fri, 18 May 2012 13:50:56 +1000 Message-Id: <20120518035057.4240C20B87F5@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 03:51:23 -0000 In message , Lorenzo Colitti writes: > On Fri, May 18, 2012 at 11:58 AM, Hesham Soliman > wrote: > > > In the context of the "MSS editing" thread, PMTUD _is_not_relevant_ to > > the discussion. The discussion is about MSS editing by the CPE to avoid > > the tunnelling impacts, which are known upfront and have nothing to do > > with the impacts for the entire path. > > > > I think what people are saying is "don't rewrite MSS for IPv6 packets, > ever", and they end up talking about PMTUD because MSS rewriting is just a > hack to avoid PMTUD (and its possible failures). Also if we want to record lowest path mtu we can do it with a per hop IP{v6} option. Doing this would help both TCP and UDP. This doesn't have to be sent for every packet. TCP SYN/SYN ACK and the first packet each way in a UDP exchange. If the incoming and outgoing interfaces differ in MTU you set the value to the lower of the lower of the two interfaces and the existing value. Routers when have equal sized MTU's can ignore the option. I'd much rather have support for something like this made manditory for home routers than MSS re-write. If we do add MSS re-write set a sunset date. Kludges like this should go away. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mawatari@jpix.ad.jp Thu May 17 22:44:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AB221F8624 for ; Thu, 17 May 2012 22:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 5-4PykT76Rxh for ; Thu, 17 May 2012 22:44:14 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 98A9F21F8658 for ; Thu, 17 May 2012 22:44:14 -0700 (PDT) Received: from [192.168.0.228] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id D377DFC021 for ; Fri, 18 May 2012 14:44:12 +0900 (JST) Date: Fri, 18 May 2012 14:44:11 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: References: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> Message-Id: <20120518144411.F83E.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 05:44:15 -0000 Dear v6ops, Sorry for delay. We, 464XLAT co-authors, had discussed about following comments. --- > > We think > > that is depending on v6ops members and chairs. > > If the proposed simplification based on on a CLAT well-known interface ID is not included, I personally object to BCP status, but have no objection against Informational (the originally proposed status). --- IANA's EUI-64 ID is a reasonable solution. We will write 2 models ("no dedicated IPv6 prefix model by using NAT44 with IANA's EUI-64 ID" and "dedicated IPv6 prefix model without NAT44") on the 464XLAT document as a BCP text. We are thinking that "no dedicated IPv6 prefix model by using NAT44 with IANA's EUI-64 ID" is appropriate for the mobile services that can not utilize DHCPv6-PD yet and "dedicated IPv6 prefix model without NAT44" is appropriate for the service that can utilize DHCPv6-PD (e.g. most of wireline services). However, using NAT44 with IANA's EUI-64 ID is not comply RFC 6145. So we would like to write the requirement language as a "MAY". It is for keeping selectivity of operator's priority. If we have any missing points, please let us know. Kind Regards, Masataka MAWATARI * On Wed, 16 May 2012 09:35:33 +0200 * Remi Despres wrote: > Le 2012-05-15 a 22:23, MAWATARI Masataka a ecrit : > > > Dear Remi-san and all, > > > > We appreciate your comments. > > > > > > 1. > > There were some comments about deleting dedicated IPv6 prefix model > > without NAT44 from the 464XLAT document on v6ops mailing list. > > > > But, we, 464XLAT co-authors, would like to keep the dedicated IPv6 > > prefix model without NAT44 on the 464XLAT document. > > > > Our beliefs are simple as below. > > > > - We insist that we should eliminate implement complexity on CPE > > and reduce the cost (memory resources on CPE, operation cost > > (troubleshooting, user support)) for IPv4 long life during a > > period of transition from IPv4 to IPv6 as far as possible. > > > > - 464XLAT using a dedicated IPv6 prefix can do that instead of > > assigning a dedicated IPv6 prefix for translation. > > > > We would not like to write specific descriptions for keeping > > selectivity of operator's priority. So we think we should write > > 2 models (dedicated IPv6 prefix and no dedicated IPv6 prefix). > > Honestly, we do not care about the document category. > > > We think > > that is depending on v6ops members and chairs. > > If the proposed simplification based on on a CLAT well-known interface ID is not included, I personally object to BCP status, but have no objection against Informational (the originally proposed status). > > > > 2. > > We will add following sentence. > > --- > > By combining 464XLAT with BIH [RFC6535], it is also possible to > > provide single IPv4/IPv6 translation service, which will be needed in > > the future case of IPv6-only servers and peers to be reached from > > legacy IPv4-only hosts across IPv6-only networks. > > --- > > A useful clarification IMHO. > Thanks. > > Regards, > RD From lorenzo@google.com Thu May 17 23:35:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE9021F8684 for ; Thu, 17 May 2012 23:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.059, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9vpSVkhTXJo for ; Thu, 17 May 2012 23:35:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E39E21F8683 for ; Thu, 17 May 2012 23:35:48 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4313305obb.31 for ; Thu, 17 May 2012 23:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Yc41bA/nLYI01AFZLbwKIfqTyugwTJIa4uUsu26fr0w=; b=ky2rSZmT2l5SgQQHfOe3yX6rFWEHPqrn6PMUk+68qeDnVpHQgv5dKPkefUYuuHsu5p DwVktxJdvu72FOxo2Ja1ZhwNTig+FkZq6t1zx4YzzMskjPD1KHqjkC1Lr14EpEPVJPII CwGnzh1Evyg7n4mJMd1NIKp6QAwwV0MFYoly5HrjX4R4f/RslOLvIWJ3V6YbtMKTC6uD jVyI2i3p3dd2fqmCaQ2gGRE9PMkjZAXvRpheDJgaxUvb8GFgAb4rDftZzQDG0/yjZoOL xNWnAdGZcUU2ppB7SVCOKz6pGm64y+vd8AbQzYAiC6u98WwXZm43mZ8mYnE9TWepEx5L 8/4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Yc41bA/nLYI01AFZLbwKIfqTyugwTJIa4uUsu26fr0w=; b=ggRcl368qQzy7C2kriEWSq4CmkOC9SjFFtMLXHzgULilzYQFN1f4Aw8t3+PqsP6OaA BYTfe1f/mrHshmu1uH26gDTbAcUb98I0zCjigp1cGkv1Ip6psz/aqqrpDwExqSCXTb2p VSnoik/dphZyOJvok3NsASFeczPGxqXDuV6qrVj3cEPlxV2tTB7h956pY7pQ6/1HTemU XLirogYTkf7j0Ke4mpZLHpkYDDo8ypDUfHBW5d47AyWS7S0MpJsSlybY1WiLRr9xFS0J oZfTLdXmxAjSliUc+zrAONwTIAPOsxfpWLF1+8EWFKgbFp/KIRQTnrITGXUA2hjsEZW6 pHYQ== Received: by 10.60.14.169 with SMTP id q9mr9287092oec.19.1337322937130; Thu, 17 May 2012 23:35:37 -0700 (PDT) Received: by 10.60.14.169 with SMTP id q9mr9287081oec.19.1337322936975; Thu, 17 May 2012 23:35:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Thu, 17 May 2012 23:35:16 -0700 (PDT) In-Reply-To: <20120518144411.F83E.8FE1F57E@jpix.ad.jp> References: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> <20120518144411.F83E.8FE1F57E@jpix.ad.jp> From: Lorenzo Colitti Date: Fri, 18 May 2012 15:35:16 +0900 Message-ID: To: MAWATARI Masataka Content-Type: multipart/alternative; boundary=e89a8fb1ee0e9bbf9204c049c23a X-System-Of-Record: true X-Gm-Message-State: ALoCoQmCd8mXh0dYAEPVXuldl84Z6uZQCZwBXbCk3F+ow4Izil7QspNls88HteoPMpZ4PHfv+38En6V8mVt3eB38RIsgqxSXULmaPkWQrD0RaFrm8hlOWyLFCjuocKBMCnDzUUDyS4SL Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 06:35:48 -0000 --e89a8fb1ee0e9bbf9204c049c23a Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 18, 2012 at 2:44 PM, MAWATARI Masataka wrote: > However, using NAT44 with IANA's EUI-64 ID is not comply RFC 6145. > So we would like to write the requirement language as a "MAY". > It is for keeping selectivity of operator's priority. > Hmm. Can you explain a bit more how that conflicts with RFC 6145? --e89a8fb1ee0e9bbf9204c049c23a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 18, 2012 at 2:44 PM, MAWATARI Masata= ka <mawatari@jpix.ad.jp> wrote:
However, using NAT44 with IANA's EUI-64 ID is not comply RFC 6145.
So we would like to write the requirement language as a "MAY". It is for keeping selectivity of operator's priority.
<= div>
Hmm. Can you explain a bit more how that conflicts with = RFC 6145?
--e89a8fb1ee0e9bbf9204c049c23a-- From despres.remi@laposte.net Thu May 17 23:43:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3CF21F866A for ; Thu, 17 May 2012 23:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qknJrWf9Vf5 for ; Thu, 17 May 2012 23:42:53 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 119BB21F8669 for ; Thu, 17 May 2012 23:42:52 -0700 (PDT) Received: from [192.168.1.28] ([89.170.204.45]) by mwinf8510-out with ME id BJip1j0070zHM1D03Jiqud; Fri, 18 May 2012 08:42:51 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Admin In-Reply-To: <20120518144411.F83E.8FE1F57E@jpix.ad.jp> Date: Fri, 18 May 2012 08:42:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> <20120518144411.F83E.8FE1F57E@jpix.ad.jp> To: MAWATARI Masataka X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 06:43:04 -0000 2012-05-18 07:44, MAWATARI : > Dear v6ops, >=20 > Sorry for delay. > We, 464XLAT co-authors, had discussed about following comments. >=20 > --- >>> We think >>> that is depending on v6ops members and chairs. >>=20 >> If the proposed simplification based on on a CLAT well-known = interface ID is not included, I personally object to BCP status, but = have no objection against Informational (the originally proposed = status). > --- >=20 > IANA's EUI-64 ID is a reasonable solution. >=20 > We will write 2 models ("no dedicated IPv6 prefix model by using > NAT44 with IANA's EUI-64 ID" and "dedicated IPv6 prefix model > without NAT44") on the 464XLAT document as a BCP text. >=20 > We are thinking that "no dedicated IPv6 prefix model by using > NAT44 with IANA's EUI-64 ID" is appropriate for the mobile services > that can not utilize DHCPv6-PD yet > and "dedicated IPv6 prefix model > without NAT44" is appropriate for the service that can utilize > DHCPv6-PD (e.g. most of wireline services). Don't understand why the IANA's EUI-64 ID wouldn't be appropriate for = this case too. Could you explain? > However, using NAT44 with IANA's EUI-64 ID is not comply RFC 6145. Don't see where RFC 6145 would conflict. Can you be more precise? > So we would like to write the requirement language as a "MAY". > It is for keeping selectivity of operator's priority. >=20 > If we have any missing points, please let us know. Clarifications on the above are IMHO needed. Regards, RD >=20 >=20 > Kind Regards, > Masataka MAWATARI >=20 >=20 > * On Wed, 16 May 2012 09:35:33 +0200 > * Remi Despres wrote: >=20 >> Le 2012-05-15 a 22:23, MAWATARI Masataka a ecrit : >>=20 >>> Dear Remi-san and all, >>>=20 >>> We appreciate your comments. >>>=20 >>>=20 >>> 1. >>> There were some comments about deleting dedicated IPv6 prefix model >>> without NAT44 from the 464XLAT document on v6ops mailing list. >>>=20 >>> But, we, 464XLAT co-authors, would like to keep the dedicated IPv6 >>> prefix model without NAT44 on the 464XLAT document. >>>=20 >>> Our beliefs are simple as below. >>>=20 >>> - We insist that we should eliminate implement complexity on CPE >>> and reduce the cost (memory resources on CPE, operation cost >>> (troubleshooting, user support)) for IPv4 long life during a >>> period of transition from IPv4 to IPv6 as far as possible. >>>=20 >>> - 464XLAT using a dedicated IPv6 prefix can do that instead of >>> assigning a dedicated IPv6 prefix for translation. >>>=20 >>> We would not like to write specific descriptions for keeping >>> selectivity of operator's priority. So we think we should write >>> 2 models (dedicated IPv6 prefix and no dedicated IPv6 prefix). >>> Honestly, we do not care about the document category. >>=20 >>> We think >>> that is depending on v6ops members and chairs. >>=20 >> If the proposed simplification based on on a CLAT well-known = interface ID is not included, I personally object to BCP status, but = have no objection against Informational (the originally proposed = status). >>=20 >>=20 >>> 2. >>> We will add following sentence. >>> --- >>> By combining 464XLAT with BIH [RFC6535], it is also possible to >>> provide single IPv4/IPv6 translation service, which will be needed = in >>> the future case of IPv6-only servers and peers to be reached from >>> legacy IPv4-only hosts across IPv6-only networks. >>> --- >>=20 >> A useful clarification IMHO. >> Thanks. >>=20 >> Regards, >> RD >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu May 17 23:45:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B055921F86A3 for ; Thu, 17 May 2012 23:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7+WRW6Yauqe for ; Thu, 17 May 2012 23:45:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3760C21F866A for ; Thu, 17 May 2012 23:45:50 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4326951obb.31 for ; Thu, 17 May 2012 23:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=hLl0mm8wyBCVGmv/IRh7yB6aVO8v24Df2lSMUJpQJf4=; b=LduDbhpjmpiZE7LdOAZm3z/BwFOvLaMCK7z7Oze2LzRXmo/a5WP00PqkHqMAOr/7MY DF0aCq2jmAUv3iupCg20pxEtQ0lzmeiP4VZQmRLWsbI83o8W4YGdQOR/81n658qcgF41 FeryBK+ttcIUsXb51o7yo8kO9ZNsO4QtUX6E8LMfeG3lDGHWxRWg7KHApmgW7739JUnm McCNvL46+FSbub9rZI2lXohfRtulPTS3cY3BEpavVTEuqA9U0hL2SI0mgloOqxiRVaiG QMGoBDnsNjhYC2ipVlhVUqCVurJLAYFt8nrrt2tWB2xdTTpUmnMGUsV+QApgoHRJSqfg I/uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=hLl0mm8wyBCVGmv/IRh7yB6aVO8v24Df2lSMUJpQJf4=; b=T3eBDkHDEfFOGaOqCcAEgZDCQXiJEWNnl9Klh/tezvktW2OUujbptk4FKsBtIfYSkk pFty7udbsQa1XOyDttTxqu5ZLNn6yAqDeuhRMMDUyLfg2iIyKU9tSO8ItcGREZi/C2jZ i89LtN0pPUuZJhkic/JYs98510DrHlyLS29ek/7Xg0zzocW5ivT76B8qeGnxGA4HecGM XwbOr81XijgjOX5O67G1GvsFcDOdBywdH+RyszxOd8ZSO8v4hMvDgDeZJl6foYNPPlSe zulKoa/S4BC72wzS1Nn3IjNj6n0ZrHKjJpUuV36Pwygu8qogwe6yhAbepJ3pzNlV7PVJ BkTg== Received: by 10.182.46.36 with SMTP id s4mr8990981obm.58.1337323549876; Thu, 17 May 2012 23:45:49 -0700 (PDT) Received: by 10.182.46.36 with SMTP id s4mr8990974obm.58.1337323549754; Thu, 17 May 2012 23:45:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Thu, 17 May 2012 23:45:29 -0700 (PDT) In-Reply-To: References: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> <20120518144411.F83E.8FE1F57E@jpix.ad.jp> From: Lorenzo Colitti Date: Fri, 18 May 2012 15:45:29 +0900 Message-ID: To: Admin Content-Type: multipart/alternative; boundary=f46d0444ec672203b104c049e733 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmKj8+uORUgdZFSDkJwQ8qRLMxj1sMlxhAC/NynKh6bz8oZ0leWhVNUn2kBH700CxN+gcHcQi1MtOUHhauoJqJ68tk5VBzA3S5Af7LTPZUCFtSGXq63RHkT6yvcCXGLUo3uTlr2 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 06:45:50 -0000 --f46d0444ec672203b104c049e733 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 18, 2012 at 3:42 PM, Admin wrote: > > and "dedicated IPv6 prefix model > > without NAT44" is appropriate for the service that can utilize > > DHCPv6-PD (e.g. most of wireline services). > > Don't understand why the IANA's EUI-64 ID wouldn't be appropriate for this > case too. > Could you explain? This model works by statelessly mapping the IPv4 addresses of CLAT clients into IPv6 addresses of the given prefix. So it obviously doesn't use a fixed interface ID. --f46d0444ec672203b104c049e733 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 18, 2012 at 3:42 PM, Admin <= despres.remi@laposte.net> wrote:
> and "dedicated IPv6 prefix model
> without NAT44" is appropriate for the service that can utilize > DHCPv6-PD (e.g. most of wireline services).

Don't understand why the IANA's EUI-64 ID wouldn't be app= ropriate for this case too.
Could you explain?

This model works by stat= elessly mapping the IPv4 addresses of CLAT clients into IPv6 addresses of t= he given prefix. So it obviously doesn't use a fixed interface ID.
--f46d0444ec672203b104c049e733-- From despres.remi@laposte.net Thu May 17 23:59:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9A121F86B7 for ; Thu, 17 May 2012 23:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIaR2mOEULmP for ; Thu, 17 May 2012 23:59:19 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 0350F21F8674 for ; Thu, 17 May 2012 23:59:18 -0700 (PDT) Received: from [192.168.1.28] ([89.170.204.45]) by mwinf8510-out with ME id BJzH1j0050zHM1D03JzHR5; Fri, 18 May 2012 08:59:17 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3-387388073 From: Admin In-Reply-To: Date: Fri, 18 May 2012 08:59:17 +0200 Message-Id: <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> References: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> <20120518144411.F83E.8FE1F57E@jpix.ad.jp> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 06:59:20 -0000 --Apple-Mail-3-387388073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 18 mai 2012 =E0 08:45:29, Lorenzo Colitti a =E9crit : > On Fri, May 18, 2012 at 3:42 PM, Admin = wrote: > > and "dedicated IPv6 prefix model > > without NAT44" is appropriate for the service that can utilize > > DHCPv6-PD (e.g. most of wireline services). >=20 > Don't understand why the IANA's EUI-64 ID wouldn't be appropriate for = this case too. > Could you explain? >=20 > This model works by statelessly mapping the IPv4 addresses of CLAT = clients into IPv6 addresses of the given prefix. So it obviously doesn't = use a fixed interface ID. This isn't an answer to my question: "why using the IANA's EUI + NAT44 = model wouldn't work also if DHCPv6 is operational"? RD --Apple-Mail-3-387388073 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, May 18, 2012 at 3:42 = PM, Admin <despres.remi@laposte.net> = wrote:
> and "dedicated IPv6 prefix model
> without NAT44" is appropriate for the service that can utilize
> DHCPv6-PD (e.g. most of wireline services).

Don't understand why the IANA's EUI-64 ID wouldn't be appropriate = for this case too.
Could you explain?

This model works by = statelessly mapping the IPv4 addresses of CLAT clients into IPv6 = addresses of the given prefix. So it obviously doesn't use a fixed = interface ID.

This isn't an answer to my question: "why = using the IANA's EUI + NAT44 model wouldn't work also if DHCPv6 is = operational"?

RD

= --Apple-Mail-3-387388073-- From lorenzo@google.com Fri May 18 00:19:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B8621F860D for ; Fri, 18 May 2012 00:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.055, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsDLSclEI0h7 for ; Fri, 18 May 2012 00:19:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1426A21F8505 for ; Fri, 18 May 2012 00:19:53 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4374649obb.31 for ; Fri, 18 May 2012 00:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=uvQ+EETiJ471wAAln0D/raWYM/0BxzmCQXwpq/mErsk=; b=ajkKaBpQGQzZm0Y/qrg53YvBs8A8M5zVFm/LGeWZIn7KHuqH2NYbTHR0Wet7XIuH8V /F3zXoztuY0TY7NG4diI73afGWq4rwWua8j5BcIPB5IwZxG9Yhhp+T5e8M3G/Tufskfv kpwuZS4Lr2UEuXQBWJnyZO6tc2ija5Mdd5gDzChvep0poN2eKeAX+odI9AXPsIEHN4mQ PsTKa1rOhiq83njus+vy4HV8IONRGpB80/4kVa1HucT3721Ofn1GfEE7dZEZtoGwTVPg cGqEsEVXfopZ52gToVQmyDbsJVqWRLCeBDf+wZ0pUwmbImRm2DbhKWGrR14pyI0jmuXR 1j2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=uvQ+EETiJ471wAAln0D/raWYM/0BxzmCQXwpq/mErsk=; b=dMtygpst5yy/rBtZ9eX589cAIWomFjWUSsn5Fc8/6Fp3QI9T1S95owm4uoi3NtwXdI Dx5M4fujwh3Qh5pkgQKfOM3UsngUjjZz+tiuwxYqAbtu31Oq3T3kDeTdweeKbXXkfyt6 QRZvIa5jhel+dUWc7iMtK13B51qdM8OcSHhIvq5hPuJPwiatLi8FTDncEBWt9QMixU4C 1rVXl1FZNNcBZRBTthfktCE9xN+J7aNWMi0SjRCqXoUId6cbWx3aldn27mhfBnSrC01P f0f/h7m/mDmqWn1c4W7csogph4x1nI22IHHsDdO6iltuF457R1m2ykjZ16KXdXw8mOO4 l35Q== Received: by 10.60.13.134 with SMTP id h6mr9264480oec.11.1337325593605; Fri, 18 May 2012 00:19:53 -0700 (PDT) Received: by 10.60.13.134 with SMTP id h6mr9264470oec.11.1337325593485; Fri, 18 May 2012 00:19:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Fri, 18 May 2012 00:19:33 -0700 (PDT) In-Reply-To: <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> References: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> <20120518144411.F83E.8FE1F57E@jpix.ad.jp> <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> From: Lorenzo Colitti Date: Fri, 18 May 2012 16:19:33 +0900 Message-ID: To: Admin Content-Type: multipart/alternative; boundary=e89a8fb1ebb6f2dfdb04c04a6053 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmG6jDoDG2kU3Ykjeq4mDVQ2NUtG2g/hr+I3cjorZnAJpVFS3f47XmSVFzE0TpGWMVZSZWHp6w5ySALjBV4DwhfhSKXvzK5suDuAWL7mIQdJmiyl6Cfli+LJc1axmhVivT0vv7f Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 07:19:57 -0000 --e89a8fb1ebb6f2dfdb04c04a6053 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 18, 2012 at 3:59 PM, Admin wrote: > This model works by statelessly mapping the IPv4 addresses of CLAT clients > into IPv6 addresses of the given prefix. So it obviously doesn't use a > fixed interface ID. > > This isn't an answer to my question: "why using the IANA's EUI + NAT44 > model wouldn't work also if DHCPv6 is operational"? > I believe that the reason is to support the use case of a shared, large-scale CLAT that serves a large number of users, possibly from many different operators. In that case, the NAT444 is a significant bottleneck compared to stateless operation. --e89a8fb1ebb6f2dfdb04c04a6053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 18, 2012 at 3:59 PM, Admin <= despres.remi@laposte.net> wrote:
This model works by stateles= sly mapping the IPv4 addresses of CLAT clients into IPv6 addresses of the g= iven prefix. So it obviously doesn't use a fixed interface ID.
This isn't an answer to my qu= estion: "why using the IANA's EUI + NAT44 model wouldn't work = also if DHCPv6 is operational"?

I believe that the reason is to support the use case of a shared, larg= e-scale CLAT that serves a large number of users, possibly from many differ= ent operators. In that case, the NAT444 is a significant bottleneck compare= d to stateless operation.
--e89a8fb1ebb6f2dfdb04c04a6053-- From brian.e.carpenter@gmail.com Fri May 18 00:39:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034AB21F864B for ; Fri, 18 May 2012 00:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.589 X-Spam-Level: X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50siC3a7FLI8 for ; Fri, 18 May 2012 00:39:01 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E103C21F8636 for ; Fri, 18 May 2012 00:39:00 -0700 (PDT) Received: by eaaq13 with SMTP id q13so762189eaa.31 for ; Fri, 18 May 2012 00:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5WUuxBijQQ5bDDWdmwmJ/FwHFRDpzhOM7Ro0zs5r/l8=; b=uCrdD42e3cFSWnJE3E2DcHONi8uOCU0ZDqQTlyeL3zM/QP7QDKaMm/GhtooRHUi1fD puyla2rWLWvJE83JRBFcLPJNV6QekJWcgvDc8BNn1Bax1X2tj5oMQVVe/a9AYg5327Sc umVd29wppU6uPS+yiONHARXrqG71fRy/gse8htO0Abmh/sjoa2k6xjLPCFPw3Nk3jseY ayPa9kNgjqiY+BnzUXdTxpvJHo10d7Mi6MIeXFWIg90Wo3u4uTBd7j+vOudVsJCyWEKx SUGmt0WEZS3e0fvCVMw3hDH3XbSLWVP9SAUthznEw5A4cn2uo9ocQx0etWf6Wlw4iZ9w c5sQ== Received: by 10.213.112.139 with SMTP id w11mr2802269ebp.32.1337326740066; Fri, 18 May 2012 00:39:00 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-67.as13285.net. [2.102.216.67]) by mx.google.com with ESMTPS id a16sm40960128eeg.0.2012.05.18.00.38.57 (version=SSLv3 cipher=OTHER); Fri, 18 May 2012 00:38:58 -0700 (PDT) Message-ID: <4FB5FC8B.8040806@gmail.com> Date: Fri, 18 May 2012 08:38:51 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> In-Reply-To: <20120517195110.GJ84425@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 07:39:02 -0000 On 2012-05-17 20:51, Gert Doering wrote: > IPv6 PMTU works - and where it breaks, it needs to be fixed. Yes, it works except where it doesn't. Now is surely the time to develop a BCP on what everybody must do to make it work. Brian From ichiroumakino@gmail.com Fri May 18 00:40:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8621F8669 for ; Fri, 18 May 2012 00:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.118 X-Spam-Level: X-Spam-Status: No, score=-3.118 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoDdQiIfFKdY for ; Fri, 18 May 2012 00:40:27 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 642F421F8657 for ; Fri, 18 May 2012 00:40:27 -0700 (PDT) Received: by eekd4 with SMTP id d4so777450eek.31 for ; Fri, 18 May 2012 00:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Mu72L1qO9YBLHCcDF+jXXbOKhki31m0mYi438tN73rg=; b=poS9MQ4ZkZQ1KRDp6xVv+uILlkacx9UUr4HHPy+WgyFOCWOgKpN6pICBuzyaIgEaXw /jW0QwiRBWTPYcS7xSXc7I8UKw5rVQDZi8EKVFnFj0qkAt1Dg/irnQjLVZMTZgLABQVz R0I36E5FBrfxGRWbBOkSXQ3nnE3LaLJqKXTjHMOqbVXId39b3U3y8CN30HNxsbe7xHnX UKt5uq2Hd2buIlsVu95m1NKrCHFrisclRzMERHAu4ONm7OHUzthXR8CTyly35zSftmoI QHPyCj572KVxyRkGrKMo0m5a1MrEKCeqBTOtbZqeif6W2L0IuR4BLunUQmXWqLnwPElv UrYw== Received: by 10.213.113.137 with SMTP id a9mr2837296ebq.59.1337326826331; Fri, 18 May 2012 00:40:26 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id v46sm40902806eef.11.2012.05.18.00.40.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 00:40:25 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <20EA9BD5-F05C-44EE-8046-6CF992D413C2@iol.unh.edu> Date: Fri, 18 May 2012 09:40:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20EA9BD5-F05C-44EE-8046-6CF992D413C2@iol.unh.edu> To: Timothy Winters X-Mailer: Apple Mail (2.1278) Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 07:40:28 -0000 Tim, > Thanks for taking the time, so If I'm understanding you = correctly a CE Router is expected to generate a ICMPv6 Unreachable = message for all invalidated or unknown prefixes on the LAN interface? = This makes sense to me, I'm just making sure we don't expect a CE Router = to know the difference between recently invalidated and unknown. yes, agree we should make no such expectation. cheers, Ole= From kawashimam@vx.jp.nec.com Fri May 18 02:34:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FB121F854D for ; Fri, 18 May 2012 02:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k3BhOP5tTlx for ; Fri, 18 May 2012 02:34:52 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id B62DE21F851E for ; Fri, 18 May 2012 02:34:52 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q4I9Yn9E029062; Fri, 18 May 2012 18:34:49 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q4I9Ync19588; Fri, 18 May 2012 18:34:49 +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 q4I9Ymqm001897; Fri, 18 May 2012 18:34:48 +0900 (JST) Received: from chojiro.jp.nec.com ([10.26.220.28] [10.26.220.28]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-1191946; Fri, 18 May 2012 18:33:43 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-50605; Fri, 18 May 2012 18:33:42 +0900 To: Admin In-reply-to: <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> References: <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> Message-Id: <20120518183342kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Fri, 18 May 2012 18:33:41 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 09:34:53 -0000 Hi Remi, Thank you for your comment. >This isn't an answer to my question: "why using the IANA's EUI + > NAT44 model wouldn't work also if DHCPv6 is operational"? I think that it would work even if DHCPv6-PD is operational. However, using the IANA's EUI + NAT44 model does not comply the following part of RFC6145. Quote of section 4.1. in RFC6145. "Translating IPv4 Headers into IPv6 Headers" (snip) Source Address: The IPv4-converted address derived from the IPv4 source address per [RFC6052], Section 2.3. If the translator gets an illegal source address (e.g., 0.0.0.0, 127.0.0.1, etc.), the translator SHOULD silently drop the packet (as discussed in Section 5.3.7 of [RFC1812]). Addition to this, some operators or implementors will choose dedicated IPv6 prefix model in order to avoid operational difficulty and implementation complexity. Therefore, we need two models. I prefer simple combination with RFC6145 and RFC6146. That is our essential motivation. Regards, Masanobu > >Le 18 mai 2012 08:45:29, Lorenzo Colitti a $BqD(Brit : > >> On Fri, May 18, 2012 at 3:42 PM, Admin wrote: >> > and "dedicated IPv6 prefix model >> > without NAT44" is appropriate for the service that can utilize >> > DHCPv6-PD (e.g. most of wireline services). >> >> Don't understand why the IANA's EUI-64 ID wouldn't be appropriate for this case too. >> Could you explain? >> >> This model works by statelessly mapping the IPv4 addresses of CLAT clients into IPv6 addresses of the given prefix. So it obviously doesn't use a fixed interface ID. > >This isn't an answer to my question: "why using the IANA's EUI + NAT44 model wouldn't work also if DHCPv6 is operational"? > >RD > > ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From despres.remi@laposte.net Fri May 18 05:54:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A968121F8665 for ; Fri, 18 May 2012 05:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH5RYKcDsZPI for ; Fri, 18 May 2012 05:54:27 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id B48ED21F8610 for ; Fri, 18 May 2012 05:54:26 -0700 (PDT) Received: from [192.168.1.28] ([89.170.204.45]) by mwinf8504-out with ME id BQuP1j0040zHM1D03QuPhz; Fri, 18 May 2012 14:54:24 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-408693411 From: Admin In-Reply-To: Date: Fri, 18 May 2012 14:54:22 +0200 Message-Id: References: <20120516052346.63F1.8FE1F57E@jpix.ad.jp> <20120518144411.F83E.8FE1F57E@jpix.ad.jp> <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 12:54:27 -0000 --Apple-Mail-1-408693411 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 18 mai 2012 =E0 09:19:33, Lorenzo Colitti a =E9crit : > On Fri, May 18, 2012 at 3:59 PM, Admin = wrote: >> This model works by statelessly mapping the IPv4 addresses of CLAT = clients into IPv6 addresses of the given prefix. So it obviously doesn't = use a fixed interface ID. >=20 > This isn't an answer to my question: "why using the IANA's EUI + NAT44 = model wouldn't work also if DHCPv6 is operational"? >=20 > I believe that the reason is to support the use case of a shared, = large-scale CLAT that serves a large number of users, possibly from many = different operators. In that case, the NAT444 is a significant = bottleneck compared to stateless operation. Documenting a little more one configuration you (or they) have in mind = would be useful. Any justification for two solutions instead of one should be well = understood.=20 In the draft, a CLAT "has also IPv6 router function that can forward = IPv6 packet for IPv6 hosts in end-user network". The CLAT you refer to = doesn't seem to be in an end-user network. RD --Apple-Mail-1-408693411 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, May 18, 2012 at 3:59 = PM, Admin <despres.remi@laposte.net> = wrote:
This model works by statelessly mapping the = IPv4 addresses of CLAT clients into IPv6 addresses of the given prefix. = So it obviously doesn't use a fixed interface ID.
This isn't an answer to my = question: "why using the IANA's EUI + NAT44 model wouldn't work also if = DHCPv6 is operational"?

I believe that the reason is to support the use case of a shared, = large-scale CLAT that serves a large number of users, possibly from many = different operators. In that case, the NAT444 is a significant = bottleneck compared to stateless operation.

Documenting a little more one configuration = you (or they) have in mind would be useful.
Any justification = for two solutions instead of one should be well = understood. 

In the draft, a CLAT "has = also IPv6 router function that can forward IPv6 packet for IPv6 hosts in = end-user network". The CLAT you refer to doesn't seem to be in an = end-user = network.

RD


= --Apple-Mail-1-408693411-- From despres.remi@laposte.net Fri May 18 07:03:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C3721F865A for ; Fri, 18 May 2012 07:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mux4hr+Kh8S8 for ; Fri, 18 May 2012 07:03:17 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4B721F868A for ; Fri, 18 May 2012 07:03:16 -0700 (PDT) Received: from [192.168.1.28] ([89.170.204.45]) by mwinf8504-out with ME id BS391j0020zHM1D03S3BVS; Fri, 18 May 2012 16:03:15 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-2022-jp From: Admin In-Reply-To: <20120518183342kawashimam@mail.jp.nec.com> Date: Fri, 18 May 2012 16:03:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F5B353B-D92E-44F8-8211-300C463EB4C3@laposte.net> References: <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> <20120518183342kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 14:03:18 -0000 18 mai 2012 b11:33, Masanobu Kawashima : >=20 > Hi Remi, >=20 > Thank you for your comment. >=20 >> This isn't an answer to my question: "why using the IANA's EUI + >> NAT44 model wouldn't work also if DHCPv6 is operational"? >=20 > I think that it would work even if DHCPv6-PD is operational. > However, using the IANA's EUI + NAT44 model does not comply > the following part of RFC6145. >=20 > Quote of section 4.1. in RFC6145. >=20 > "Translating IPv4 Headers into IPv6 Headers" >=20 > (snip) >=20 > Source Address: The IPv4-converted address derived from the IPv4 > source address per [RFC6052], Section 2.3. >=20 > If the translator gets an illegal source address (e.g., 0.0.0.0, > 127.0.0.1, etc.), the translator SHOULD silently drop the packet > (as discussed in Section 5.3.7 of [RFC1812]). >=20 > Addition to this, some operators or implementors will choose > dedicated IPv6 prefix model in order to avoid operational difficulty > and implementation complexity. Not understood where IANA's CLAT IID would introduce "operational = difficulty and implementation complexity" (in my understanding, = negligible implementation difference, and simpler operation with the = IANA CLAT IID). Documenting at least one configuration where you this to apply would be = clarifying. RD > Therefore, we need two models. >=20 > I prefer simple combination with RFC6145 and RFC6146. > That is our essential motivation. >=20 > Regards, > Masanobu >=20 >=20 >>=20 >> Le 18 mai 2012 08:45:29, Lorenzo Colitti a =1B$BqD=1B(Brit : >>=20 >>> On Fri, May 18, 2012 at 3:42 PM, Admin = wrote: >>>> and "dedicated IPv6 prefix model >>>> without NAT44" is appropriate for the service that can utilize >>>> DHCPv6-PD (e.g. most of wireline services). >>>=20 >>> Don't understand why the IANA's EUI-64 ID wouldn't be appropriate = for this case too. >>> Could you explain? >>>=20 >>> This model works by statelessly mapping the IPv4 addresses of CLAT = clients into IPv6 addresses of the given prefix. So it obviously doesn't = use a fixed interface ID. >>=20 >> This isn't an answer to my question: "why using the IANA's EUI + = NAT44 model wouldn't work also if DHCPv6 is operational"? >>=20 >> RD >>=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 > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =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 >=20 From Fred.L.Templin@boeing.com Fri May 18 08:03:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E67521F8658 for ; Fri, 18 May 2012 08:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9mi5WQBeB1Y for ; Fri, 18 May 2012 08:03:44 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0911D21F861B for ; Fri, 18 May 2012 08:03:43 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IF3hp9023164 for ; Fri, 18 May 2012 08:03:43 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IF3g6K023150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 08:03:42 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IF3gGc007148; Fri, 18 May 2012 08:03:42 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IF3fnP007127 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 08:03:42 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 18 May 2012 08:03:41 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , "v6ops@ietf.org" Date: Fri, 18 May 2012 08:03:40 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00nzmbcivsKf3UQo6lcfaZt4VYvQAZ9w2A Message-ID: References: <20120517162526.GA4385@srv03.cluenet.de> <20120518002637.B26BB20B53D3@drugs.dv.isc.org> 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] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 15:03:44 -0000 > Path MTU discovery needs to work.=A0But path MTU discovery > is slow - 1 RTT for every new host you connect to. s/1/1 or more/ RFC4821 *fixes* the RTT issue; RFC4821 TCPs will always make progress w/o incurring a RTT even if there is a restricting link in the path. Fred fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Fri May 18 08:09:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA4721F85A4 for ; Fri, 18 May 2012 08:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD-g5H3764fx for ; Fri, 18 May 2012 08:09:30 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6221F85A3 for ; Fri, 18 May 2012 08:09:29 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IF9TYs000630 for ; Fri, 18 May 2012 08:09:29 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IF9Spn000624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 08:09:28 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IF9SYJ025773; Fri, 18 May 2012 08:09:28 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IF9RbM025751 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 08:09:28 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 18 May 2012 08:09:28 -0700 From: "Templin, Fred L" To: Brian E Carpenter , Gert Doering Date: Fri, 18 May 2012 08:09:26 -0700 Thread-Topic: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] Thread-Index: Ac00yU/Udsm/KmczT/SGHV7mULagMAAPiHBA Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5FC8B.8040806@gmail.com> In-Reply-To: <4FB5FC8B.8040806@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 15:09:32 -0000 Hi Brian, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Friday, May 18, 2012 12:39 AM > To: Gert Doering > Cc: IPv6 Operations > Subject: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] >=20 > On 2012-05-17 20:51, Gert Doering wrote: >=20 >=20 > > IPv6 PMTU works - and where it breaks, it needs to be fixed. >=20 > Yes, it works except where it doesn't. As I said before, if IPv6 PMTUD is broken then we're sunk; set every link to 1280 and call it a day. But, we know that that is an unacceptable outcome. =20 > Now is surely the time to develop a BCP on what everybody must do to make > it work. There has been some progress related to this. Please see: http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes which saw some momentum in the 'grow' wg back in the November 2011 timeframe but now appears to be stalled. Maybe interested parties should try to breathe some new life into it. Fred > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Fri May 18 08:29:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D92721F863B for ; Fri, 18 May 2012 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_62=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 0ZMGF4DAix2i for ; Fri, 18 May 2012 08:29:30 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6166A21F8634 for ; Fri, 18 May 2012 08:29:30 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IFTNSj026019 for ; Fri, 18 May 2012 08:29:24 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IFTM4P026015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 08:29:23 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IFTSfL003141; Fri, 18 May 2012 10:29:28 -0500 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IFTRUA003103 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 10:29:28 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 18 May 2012 08:29:27 -0700 From: "Templin, Fred L" To: Shishio Tsuchiya , "gert@space.net" Date: Fri, 18 May 2012 08:29:27 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00k6pdPzTAy6Q/RaORCewtJwj0RAAdtQcg Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> In-Reply-To: <4FB5A28B.8000701@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-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 15:29:31 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Shishio Tsuchiya > Sent: Thursday, May 17, 2012 6:15 PM > To: gert@space.net > Cc: v6ops@ietf.org > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > (2012/05/18 4:51), Gert Doering wrote: > > Hi, > > > > On Thu, May 17, 2012 at 10:00:27PM +1000, Hesham Soliman wrote: > >> =3D> Yes of course, so what's the comment? MSS editing has nothing to= do > >> with any other MTU on the Internet either. > > > > I'm not advocating MSS editing for IPv6. > > > > IPv6 PMTU works - and where it breaks, it needs to be fixed. >=20 > I hope so ,but there is problem analysis of IPv6 PMTD. >=20 > Path MTU Discovery=1B$B!>=1B(B failure cases =1B$B!>=1B(B > http://www.attn.jp/maz/p/t/tmp/pmtud-failure-cases-maz.pdf > RIPE60 Measurements of IPv6 Path MTU Discovery Behaviour > http://ripe60.ripe.net/presentations/Stasiewicz- > Measurements_of_IPv6_Path_MTU_Discovery_Behaviour.pdf >=20 > World IPv6 day report,5%(11/241) websites may have IPv6 Path MTU Discover= y > problem. > http://hide.dnsalias.net/aaaa/worldipv6day.cgi I was only able to read the second of these due to firewall blockage. Can you send them to me in e-mail? > I think the data should not ignore,so CPE requirement document should > mention MSS editing as *optional*. That should not be necessary if the 6rd tunnel can do 1500 or better. Thanks - Fred fred.l.templin@boeing.com > Regard, > -Shishio > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Fri May 18 08:48:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1034E21F869D for ; Fri, 18 May 2012 08:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cd9GYjmXuJ7 for ; Fri, 18 May 2012 08:48:07 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFF621F868A for ; Fri, 18 May 2012 08:48:05 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q4IFlIJW098310 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 May 2012 16:47:18 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FB66F2C.5040304@inex.ie> Date: Fri, 18 May 2012 16:47:56 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5FC8B.8040806@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 15:48:08 -0000 On 18/05/2012 16:09, Templin, Fred L wrote: > There has been some progress related to this. Please see: > > http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes > > which saw some momentum in the 'grow' wg back in the > November 2011 timeframe but now appears to be stalled. > Maybe interested parties should try to breathe some > new life into it. In fact, Martin has been pushing this at various conferences outside the IETF arena. People seem to generally be positive about the draft. However, speaking as an IXP operator who's attempted to get people interested in jumbo frames, the problem with it is that the IXP participants are very interested until the point where they have to sit down in front of their routers and do something about it. Then they stop being interested. Been there, got overwhelmed by the apathy. Besides, the problem we're talking about here relates more to the MTU at the edge rather than jumbo frames in the core. Nick From Fred.L.Templin@boeing.com Fri May 18 08:53:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F93821F8634 for ; Fri, 18 May 2012 08:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtKVnpPYstgw for ; Fri, 18 May 2012 08:53:15 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id DA46821F85FC for ; Fri, 18 May 2012 08:53:13 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IFrTHa029229 for ; Fri, 18 May 2012 08:53:29 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IFrSU9028834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 08:53:29 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IFrCAo032620; Fri, 18 May 2012 08:53:12 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IFrCLp032615 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 08:53:12 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Fri, 18 May 2012 08:53:12 -0700 From: "Templin, Fred L" To: Nick Hilliard Date: Fri, 18 May 2012 08:53:10 -0700 Thread-Topic: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] Thread-Index: Ac01DapKd83I3FpvQH+M+CbIVO/B8gAAB8rQ Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5FC8B.8040806@gmail.com> <4FB66F2C.5040304@inex.ie> In-Reply-To: <4FB66F2C.5040304@inex.ie> 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: IPv6 Operations Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 15:53:17 -0000 Hi Nick, > -----Original Message----- > From: Nick Hilliard [mailto:nick@inex.ie] > Sent: Friday, May 18, 2012 8:48 AM > To: Templin, Fred L > Cc: Brian E Carpenter; Gert Doering; IPv6 Operations > Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for > rfc6204bis] >=20 > On 18/05/2012 16:09, Templin, Fred L wrote: > > There has been some progress related to this. Please see: > > > > http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes > > > > which saw some momentum in the 'grow' wg back in the > > November 2011 timeframe but now appears to be stalled. > > Maybe interested parties should try to breathe some > > new life into it. >=20 > In fact, Martin has been pushing this at various conferences outside the > IETF arena. People seem to generally be positive about the draft. >=20 > However, speaking as an IXP operator who's attempted to get people > interested in jumbo frames, the problem with it is that the IXP > participants are very interested until the point where they have to sit > down in front of their routers and do something about it. Then they stop > being interested. Been there, got overwhelmed by the apathy. That's sad. Would it cut through the apathy if the document were to say: "here's the *minimum* you must do in order to avoid operational issues"? > Besides, the problem we're talking about here relates more to the MTU at > the edge rather than jumbo frames in the core. I can easily imagine expanding the scope of the document to cover the edge situations too. Thanks - Fred =20 > Nick From nick@inex.ie Fri May 18 09:04:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03621F872D for ; Fri, 18 May 2012 09:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khh491JOxx1F for ; Fri, 18 May 2012 09:04:36 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6264521F8723 for ; Fri, 18 May 2012 09:04:35 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q4IG3oGU098505 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 May 2012 17:03:50 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FB6730C.5040505@inex.ie> Date: Fri, 18 May 2012 17:04:28 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5FC8B.8040806@gmail.com> <4FB66F2C.5040304@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 16:04:37 -0000 On 18/05/2012 16:53, Templin, Fred L wrote: > That's sad. Would it cut through the apathy if the document > were to say: "here's the *minimum* you must do in order to > avoid operational issues"? the minimum includes a lot of monitoring of all point-to-point paths over the network. This is operationally difficult to do when you have hash-based load balancing over multiple links, and you have no real way of predetermining what path a particular packet will take. Of course, when you have an MTU failure, it often causes silent blackholing, and this tends only to be noticed by a small number of people doing slightly fringe things, and the problem can only be debugged/fixed by escalation to layer 3 engineering. Why yes! As you ask, I have been affected by this exact problem as a L3 transit customer in the last couple of months. And it involved IPv6. Nick From Fred.L.Templin@boeing.com Fri May 18 09:20:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D5121F8675 for ; Fri, 18 May 2012 09:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MetqW2PONu-q for ; Fri, 18 May 2012 09:20:23 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 40FDC21F865A for ; Fri, 18 May 2012 09:20:23 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IGKM1f022122 for ; Fri, 18 May 2012 09:20:22 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IGKLVP022106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 09:20:22 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IGKLa0026127; Fri, 18 May 2012 09:20:21 -0700 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IGKKnT026094 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 09:20:21 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 18 May 2012 09:20:20 -0700 From: "Templin, Fred L" To: Nick Hilliard Date: Fri, 18 May 2012 09:20:19 -0700 Thread-Topic: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] Thread-Index: Ac01D/U0FMcNN7gITZyvzLmgmyc48AAAe2nw Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5FC8B.8040806@gmail.com> <4FB66F2C.5040304@inex.ie> <4FB6730C.5040505@inex.ie> In-Reply-To: <4FB6730C.5040505@inex.ie> 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: IPv6 Operations Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 16:20:24 -0000 > -----Original Message----- > From: Nick Hilliard [mailto:nick@inex.ie] > Sent: Friday, May 18, 2012 9:04 AM > To: Templin, Fred L > Cc: Brian E Carpenter; Gert Doering; IPv6 Operations > Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for > rfc6204bis] >=20 > On 18/05/2012 16:53, Templin, Fred L wrote: > > That's sad. Would it cut through the apathy if the document > > were to say: "here's the *minimum* you must do in order to > > avoid operational issues"? >=20 > the minimum includes a lot of monitoring of all point-to-point paths over > the network. This is operationally difficult to do when you have > hash-based load balancing over multiple links, and you have no real way o= f > predetermining what path a particular packet will take. >=20 > Of course, when you have an MTU failure, it often causes silent > blackholing, and this tends only to be noticed by a small number of peopl= e > doing slightly fringe things, and the problem can only be debugged/fixed > by > escalation to layer 3 engineering. >=20 > Why yes! As you ask, I have been affected by this exact problem as a L3 > transit customer in the last couple of months. And it involved IPv6. So, we either fix IPv6 PMTUD or we set all links to 1280; is that what you're saying? Fred fred.l.templin@boeing.com > Nick From phdgang@gmail.com Fri May 18 09:29:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2068521F869F for ; Fri, 18 May 2012 09:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9vKMnUCUmnw for ; Fri, 18 May 2012 09:29:01 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2165221F869D for ; Fri, 18 May 2012 09:29:00 -0700 (PDT) Received: by werb13 with SMTP id b13so732385wer.31 for ; Fri, 18 May 2012 09:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XI4RaULnaLHQeayDhTjo+q++yh5YcICIkl6ib4TR1y0=; b=hRDt6f7gdjvU0r+ltv6JufSpZUDKm7EYnNqQ0KTRxUFEx0Dy+6FNn29L7KlPoO8gj8 pffv0JDEPo2kYIFqoYcVASqn2Td7r7sZssdW0SOktXp3C4QwMXfrKCzNEULy3/V8C4xv ikq4han0N2h8vsB3b3hQo5VLMkusaRUl5M6VMIp4MDBfy6LCzltpCZo/yrhNvhTWA3qD MTvt0sR/KnZ9ArnaZw7T519L6eLew8wZtaXfiJs+m4EUIXiWRXXtcnG3Vjqq5CTx9L8f GV5hgbl7QS+SdVr6FVWyhz6oxz6fikyVa01H3hpOvh6GURgeWqtGxmjMNnDKaFri2XvN H55Q== MIME-Version: 1.0 Received: by 10.216.199.75 with SMTP id w53mr2820683wen.14.1337358540156; Fri, 18 May 2012 09:29:00 -0700 (PDT) Received: by 10.180.106.38 with HTTP; Fri, 18 May 2012 09:28:59 -0700 (PDT) In-Reply-To: <20120518183342kawashimam@mail.jp.nec.com> References: <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> <20120518183342kawashimam@mail.jp.nec.com> Date: Sat, 19 May 2012 00:28:59 +0800 Message-ID: From: GangChen To: Masanobu Kawashima , Admin Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 16:29:02 -0000 2012/5/18, Masanobu Kawashima : > > Hi Remi, > > Thank you for your comment. > >>This isn't an answer to my question: "why using the IANA's EUI + >> NAT44 model wouldn't work also if DHCPv6 is operational"? > > I think that it would work even if DHCPv6-PD is operational. > However, using the IANA's EUI + NAT44 model does not comply > the following part of RFC6145. > > Quote of section 4.1. in RFC6145. > > "Translating IPv4 Headers into IPv6 Headers" > > (snip) > > Source Address: The IPv4-converted address derived from the IPv4 > source address per [RFC6052], Section 2.3. > > If the translator gets an illegal source address (e.g., 0.0.0.0, > 127.0.0.1, etc.), the translator SHOULD silently drop the packet > (as discussed in Section 5.3.7 of [RFC1812]). When IANA IID was adopted in the non-DHCP-PD case, two benefits here. 1) Avoiding proxy CLAT address 2) 464xlat traffic identifiable When the network supports DHCP-PD, it may still remain second benefit. Whereas it may not fully comply with RFC6145. I saw the benefits, however it should document such process for illegal source address. Does the clarification help? Gang > Addition to this, some operators or implementors will choose > dedicated IPv6 prefix model in order to avoid operational difficulty > and implementation complexity. > > Therefore, we need two models. > > I prefer simple combination with RFC6145 and RFC6146. > That is our essential motivation. > > Regards, > Masanobu > > >> >>Le 18 mai 2012 08:45:29, Lorenzo Colitti a =D8=B8rit : >> >>> On Fri, May 18, 2012 at 3:42 PM, Admin wrote= : >>> > and "dedicated IPv6 prefix model >>> > without NAT44" is appropriate for the service that can utilize >>> > DHCPv6-PD (e.g. most of wireline services). >>> >>> Don't understand why the IANA's EUI-64 ID wouldn't be appropriate for >>> this case too. >>> Could you explain? >>> >>> This model works by statelessly mapping the IPv4 addresses of CLAT >>> clients into IPv6 addresses of the given prefix. So it obviously doesn'= t >>> use a fixed interface ID. >> >>This isn't an answer to my question: "why using the IANA's EUI + NAT44 >> model wouldn't work also if DHCPv6 is operational"? >> >>RD >> >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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. > Product Development Department > Masanobu Kawashima > 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=3D=3D=3D=3D > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Fred.L.Templin@boeing.com Fri May 18 09:31:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D203A21F86D1 for ; Fri, 18 May 2012 09:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ItGxa-Er7wn for ; Fri, 18 May 2012 09:31:01 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 493C321F86A1 for ; Fri, 18 May 2012 09:31:01 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IGV0Ij023899 for ; Fri, 18 May 2012 11:31:00 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IGUx3a023875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 11:30:59 -0500 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IGUw1K001762; Fri, 18 May 2012 09:30:58 -0700 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IGUwiN001757 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 09:30:58 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 18 May 2012 09:30:58 -0700 From: "Templin, Fred L" To: Shishio Tsuchiya , "gert@space.net" Date: Fri, 18 May 2012 09:30:57 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00k6pdPzTAy6Q/RaORCewtJwj0RAAdtQcgAAEhq9A= Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 16:31:01 -0000 > That should not be necessary if the 6rd tunnel can > do 1500 or better. So, here's an idea (i.e., just an idea): 1. set the MTU of all 6rd interfaces in the site to 1500 2. for IPv6 packets exiting the 6rd CPE, the host accepts ICMPv6 PTB messages and reduces MSS if a PTB is received 3. for IPv6 packets entering the 6rd BR from the Internet and destined to a host within a 6rd site, the BR does the following: a) drop the packet and send an ICMPv6 PTB if it is 1501 or more b) encapsulate the packet in an IPv4 header and send it to the 6rd CPE if it is 1480 or less c) if the packet is between 1481 - 1500: - break it into 2 equal-sized pieces and insert a fragment header on both pieces - choose a random 32-bit value and write the value in the Identification field in both pieces - encapsulate both pieces in an IPv4 header and send them to the 6rd CPE 4. the IPv6 host within the 6rd site gets to accept packets unfragmented packets in one piece and gets to reassemble fragmented packets that are no more than 1500 Fred From Fred.L.Templin@boeing.com Fri May 18 09:45:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA13021F8550 for ; Fri, 18 May 2012 09:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFernKw5Z4LX for ; Fri, 18 May 2012 09:45:24 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 3C17A21F8720 for ; Fri, 18 May 2012 09:45:24 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IGjdKO017018 for ; Fri, 18 May 2012 09:45:40 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IGjcA6017015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 09:45:39 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IGjMUa017414; Fri, 18 May 2012 11:45:22 -0500 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IGjLAK017383 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 11:45:22 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 18 May 2012 09:45:21 -0700 From: "Templin, Fred L" To: Shishio Tsuchiya , "gert@space.net" Date: Fri, 18 May 2012 09:45:20 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00k6pdPzTAy6Q/RaORCewtJwj0RAAdtQcgAAEhq9AAAX184A== Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 16:45:25 -0000 Let me make it simpler: 1. set the MTU of all 6rd interfaces in the site to 1500 2. for IPv6 packets to be admitted into the 6rd tunnel, do the following: a) drop the packet and send an ICMPv6 PTB if it is 1501 or more b) encapsulate the packet in an IPv4 header and send it to the tunnel far end if it is 1480 or less c) if the packet is between 1481 - 1500: - break it into 2 equal-sized pieces and insert a fragment header on both pieces - choose a random 32-bit value and write the value in the Identification field in both pieces - encapsulate both pieces in an IPv4 header and send them to the tunnel far end d) the IPv6 destination host gets to reassemble if necessary Fred > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Friday, May 18, 2012 9:31 AM > To: Shishio Tsuchiya; gert@space.net > Cc: v6ops@ietf.org > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > > That should not be necessary if the 6rd tunnel can > > do 1500 or better. >=20 > So, here's an idea (i.e., just an idea): >=20 > 1. set the MTU of all 6rd interfaces in the site to 1500 > 2. for IPv6 packets exiting the 6rd CPE, the host accepts > ICMPv6 PTB messages and reduces MSS if a PTB is received > 3. for IPv6 packets entering the 6rd BR from the Internet > and destined to a host within a 6rd site, the BR does > the following: >=20 > a) drop the packet and send an ICMPv6 PTB if it is > 1501 or more > b) encapsulate the packet in an IPv4 header and send > it to the 6rd CPE if it is 1480 or less > c) if the packet is between 1481 - 1500: > - break it into 2 equal-sized pieces and insert a > fragment header on both pieces > - choose a random 32-bit value and write the value > in the Identification field in both pieces > - encapsulate both pieces in an IPv4 header and > send them to the 6rd CPE >=20 > 4. the IPv6 host within the 6rd site gets to accept packets > unfragmented packets in one piece and gets to reassemble > fragmented packets that are no more than 1500 >=20 > Fred > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Fri May 18 09:52:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE0621F8633 for ; Fri, 18 May 2012 09:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp2IoMmc4P0g for ; Fri, 18 May 2012 09:52:21 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 61B7F21F8630 for ; Fri, 18 May 2012 09:52:21 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IGqERk020784 for ; Fri, 18 May 2012 09:52:15 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IGqEce020772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 09:52:14 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IGqJFg024091; Fri, 18 May 2012 09:52:19 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IGqIeo024059 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 09:52:19 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 18 May 2012 09:52:18 -0700 From: "Templin, Fred L" To: Shishio Tsuchiya , "gert@space.net" Date: Fri, 18 May 2012 09:52:18 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00k6pdPzTAy6Q/RaORCewtJwj0RAAdtQcgAAEhq9AAAX184AAAVMkQ Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 16:52:22 -0000 Sorry; one more iteration: 1. set the MTU of all 6rd interfaces in the site to 1500 2. for IPv6 packets to be admitted into the 6rd tunnel, do the following: a) drop the packet and send an ICMPv6 PTB if it is 1501 or more b) encapsulate the packet in an IPv4 header and send it to the tunnel far end if it is 1280 or less c) if the packet is between 1281 - 1500: - break it into 2 equal-sized pieces and insert a fragment header on both pieces - choose a random 32-bit value and write the value in the Identification field in both pieces - encapsulate both pieces in an IPv4 header and send them to the tunnel far end d) the IPv6 destination host gets to reassemble if necessary =20 Fred > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Friday, May 18, 2012 9:45 AM > To: Shishio Tsuchiya; gert@space.net > Cc: v6ops@ietf.org > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > Let me make it simpler: >=20 > 1. set the MTU of all 6rd interfaces in the site to 1500 > 2. for IPv6 packets to be admitted into the 6rd tunnel, > do the following: >=20 > a) drop the packet and send an ICMPv6 PTB if it is > 1501 or more > b) encapsulate the packet in an IPv4 header and send > it to the tunnel far end if it is 1480 or less > c) if the packet is between 1481 - 1500: > - break it into 2 equal-sized pieces and insert a > fragment header on both pieces > - choose a random 32-bit value and write the value > in the Identification field in both pieces > - encapsulate both pieces in an IPv4 header and > send them to the tunnel far end > d) the IPv6 destination host gets to reassemble if > necessary >=20 > Fred >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > > Templin, Fred L > > Sent: Friday, May 18, 2012 9:31 AM > > To: Shishio Tsuchiya; gert@space.net > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis > > > > > That should not be necessary if the 6rd tunnel can > > > do 1500 or better. > > > > So, here's an idea (i.e., just an idea): > > > > 1. set the MTU of all 6rd interfaces in the site to 1500 > > 2. for IPv6 packets exiting the 6rd CPE, the host accepts > > ICMPv6 PTB messages and reduces MSS if a PTB is received > > 3. for IPv6 packets entering the 6rd BR from the Internet > > and destined to a host within a 6rd site, the BR does > > the following: > > > > a) drop the packet and send an ICMPv6 PTB if it is > > 1501 or more > > b) encapsulate the packet in an IPv4 header and send > > it to the 6rd CPE if it is 1480 or less > > c) if the packet is between 1481 - 1500: > > - break it into 2 equal-sized pieces and insert a > > fragment header on both pieces > > - choose a random 32-bit value and write the value > > in the Identification field in both pieces > > - encapsulate both pieces in an IPv4 header and > > send them to the 6rd CPE > > > > 4. the IPv6 host within the 6rd site gets to accept packets > > unfragmented packets in one piece and gets to reassemble > > fragmented packets that are no more than 1500 > > > > Fred > > _______________________________________________ > > 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 nick@inex.ie Fri May 18 10:01:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605F621F8686 for ; Fri, 18 May 2012 10:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG8gLnaXUhJI for ; Fri, 18 May 2012 10:01:37 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A4DFC21F8683 for ; Fri, 18 May 2012 10:01:36 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q4IH0oF7099029 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 May 2012 18:00:51 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FB68069.6040606@inex.ie> Date: Fri, 18 May 2012 18:01:29 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5FC8B.8040806@gmail.com> <4FB66F2C.5040304@inex.ie> <4FB6730C.5040505@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 17:01:37 -0000 On 18/05/2012 17:20, Templin, Fred L wrote: > So, we either fix IPv6 PMTUD or we set all links to 1280; > is that what you're saying? basically yeah. Nick From Fred.L.Templin@boeing.com Fri May 18 10:41:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E6521F84A0 for ; Fri, 18 May 2012 10:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmIPvE2WfVk8 for ; Fri, 18 May 2012 10:41:27 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id CEEBA21F8496 for ; Fri, 18 May 2012 10:40:23 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IHcgxj005859 for ; Fri, 18 May 2012 12:38:42 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IHcfrd005851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 12:38:41 -0500 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IHcfR4013593; Fri, 18 May 2012 12:38:41 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IHcecr013553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 12:38:41 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 18 May 2012 10:38:40 -0700 From: "Templin, Fred L" To: Shishio Tsuchiya , "gert@space.net" Date: Fri, 18 May 2012 10:38:39 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00k6pdPzTAy6Q/RaORCewtJwj0RAAdtQcgAAEhq9AAAX184AAAVMkQAAGngxA= Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 17:41:28 -0000 > 1. set the MTU of all 6rd interfaces in the site to 1500 Also, no need to set all 6rd interfaces at the same time. This is incrementally deployable. Fred From Fred.L.Templin@boeing.com Fri May 18 11:38:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2013F21F883E for ; Fri, 18 May 2012 11:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp7vJwzi2vFx for ; Fri, 18 May 2012 11:38:31 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 987EC21F8838 for ; Fri, 18 May 2012 11:38:31 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IIcMjN017274 for ; Fri, 18 May 2012 13:38:23 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IIcMD1017270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 13:38:22 -0500 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IIcTSH022213; Fri, 18 May 2012 13:38:29 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IIcT3d022194 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 13:38:29 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 18 May 2012 11:38:28 -0700 From: "Templin, Fred L" To: Shishio Tsuchiya , "gert@space.net" Date: Fri, 18 May 2012 11:38:27 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00k6pdPzTAy6Q/RaORCewtJwj0RAAdtQcgAAEhq9AAAX184AAAVMkQAAGngxAAAhjVEA== Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 18:38:32 -0000 ...and, here's the draft: http://www.ietf.org/internet-drafts/draft-foo-v6ops-6rdmtu-00.txt Fred From Fred.L.Templin@boeing.com Fri May 18 12:59:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF91821F8665 for ; Fri, 18 May 2012 12:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEw275AeZvcr for ; Fri, 18 May 2012 12:59:40 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB9C21F865C for ; Fri, 18 May 2012 12:59:40 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IJxVcH025552 for ; Fri, 18 May 2012 14:59:32 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IJxU1R025541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 14:59:30 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IJxbiW021292; Fri, 18 May 2012 12:59:37 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IJxa3q021230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 12:59:37 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 18 May 2012 12:59:37 -0700 From: "Templin, Fred L" To: Shishio Tsuchiya , "gert@space.net" Date: Fri, 18 May 2012 12:59:35 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac00k6pdPzTAy6Q/RaORCewtJwj0RAAdtQcgAAEhq9AAAX184AAAVMkQAAGngxAAAhjVEAAC1x1g Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 19:59:41 -0000 ...and another: http://www.ietf.org/internet-drafts/draft-bar-v6ops-ismtu-00.txt Fred=20 From gert@space.net Fri May 18 13:29:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17F521F85E5 for ; Fri, 18 May 2012 13:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2WGj6AqqVwP for ; Fri, 18 May 2012 13:29:26 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3807721F85A3 for ; Fri, 18 May 2012 13:29:25 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 78E1EF8B6B for ; Fri, 18 May 2012 22:29:23 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 479E7F8B78 for ; Fri, 18 May 2012 22:29:23 +0200 (CEST) Received: (qmail 66459 invoked by uid 1007); 18 May 2012 22:29:23 +0200 Date: Fri, 18 May 2012 22:29:23 +0200 From: Gert Doering To: "Templin, Fred L" Message-ID: <20120518202923.GW84425@Space.Net> References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B7KcDGkYuB2XNLdF" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 20:29:27 -0000 --B7KcDGkYuB2XNLdF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, May 18, 2012 at 11:38:27AM -0700, Templin, Fred L wrote: > ...and, here's the draft: >=20 > http://www.ietf.org/internet-drafts/draft-foo-v6ops-6rdmtu-00.txt Am I understanding this right that you're proposing to re-introduce router fragmentation to IPv6? I wasn't there when this was declared an absolute no-go some hundred years ago, so I'm just staring in blank amazement... Gert Doering -- Operator --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --B7KcDGkYuB2XNLdF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT7axI6kuBuNlUUl1AQIX2QQApQrSHSyMt+0w6i36o0uM1F9E1pQT2ktg YHW/xnmkvBtgLWu5mNuF2IvkwcOlMkOBU0VmqIDvBJd0LLMI6JfBry5MOc54eYje QvVd5qhVoO7964TOFk5AfBxk/wJl3SGk96GNx8xTmM4EBQPKzpSa9AwIB/yDEygh SQeT74mbrYM= =KljQ -----END PGP SIGNATURE----- --B7KcDGkYuB2XNLdF-- From Fred.L.Templin@boeing.com Fri May 18 13:32:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829F821F8547 for ; Fri, 18 May 2012 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbVBjU1BjIZt for ; Fri, 18 May 2012 13:32:44 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0B96121F8528 for ; Fri, 18 May 2012 13:32:43 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4IKWZjH013816 for ; Fri, 18 May 2012 15:32:35 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4IKWYjU013808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2012 15:32:35 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4IKWgGc027372; Fri, 18 May 2012 13:32:42 -0700 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4IKWfIc027343 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 May 2012 13:32:41 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Fri, 18 May 2012 13:32:41 -0700 From: "Templin, Fred L" To: Gert Doering Date: Fri, 18 May 2012 13:32:40 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac01NOztcheNiRmsTf+q+X8SlZFLAwAABBWA Message-ID: References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> <20120518202923.GW84425@Space.Net> In-Reply-To: <20120518202923.GW84425@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 20:32:44 -0000 > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Friday, May 18, 2012 1:29 PM > To: Templin, Fred L > Cc: Shishio Tsuchiya; gert@space.net; v6ops@ietf.org > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > Hi, >=20 > On Fri, May 18, 2012 at 11:38:27AM -0700, Templin, Fred L wrote: > > ...and, here's the draft: > > > > http://www.ietf.org/internet-drafts/draft-foo-v6ops-6rdmtu-00.txt >=20 > Am I understanding this right that you're proposing to re-introduce > router fragmentation to IPv6? Well, for some special cases of router, yes. =20 > I wasn't there when this was declared an absolute no-go some hundred > years ago, so I'm just staring in blank amazement... It's heresy, I know. But, do you see anything wrong with it? Thanks - Fred fred.l.templin@boeing.com =20 > Gert Doering > -- Operator > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From C.Donley@CableLabs.com Fri May 18 16:14:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEC921F85ED for ; Fri, 18 May 2012 16:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSovhgNEF0kP for ; Fri, 18 May 2012 16:14:43 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4C21F85E7 for ; Fri, 18 May 2012 16:14:42 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q4INEZ2q002596; Fri, 18 May 2012 17:14:38 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 18 May 2012 17:14:35 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 18 May 2012 17:13:29 -0600 From: Chris Donley To: Fred Baker , "v6ops@ietf.org" Date: Fri, 18 May 2012 17:13:27 -0600 Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC Thread-Index: Ac01S9Werv1I1i4CRxGpGurNzEA2BQ== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBDC31945325Fcdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 23:14:43 -0000 --_000_CBDC31945325Fcdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I reviewed the document, and think it does a good job outlining the transit= ion path(s). I think it'll be ready to advance once comments are addressed. One comment wrt Section 3.5. The document says, "To minimize risk, an oper= ator should use transition technologies for the less dominant address famil= y if possible." I don't think the driver is address family dominance, but a= vailability. If operators can get native v6 to the edge, they should do i= t, even if v6 is not dominant (otherwise we could be stuck in 6RD mode for = a while, even when native v6 is available). On the v4 side, operators won'= t deploy a transition technology until they run out of addresses. Then the = choice is btw NAT444 and DS-Lite (or if we're really lucky, NAT64). Perhaps= this is what you mean by dominant? You won=92t use any as long as you can = get addresses, but once you run out, you might make the choice of base A-F = based on dominance/maturity/stability? I'll send copy-edits to the authors in a separate email. Chris From: Fred Baker > Date: Sun, 13 May 2012 12:01:41 -0600 To: "v6ops@ietf.org" > Cc: "v6ops-chairs@tools.ietf.org" >, Ronald Bonica= > Subject: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC The working group last call for this draft announced last week continues fo= r another week. Please feel free to comment on it. --_000_CBDC31945325Fcdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I reviewed= the document, and think it does a good job outlining the transition path(s= ). I think it'll be ready to advance once comments are addressed.

One comment wrt Section 3.5= .  The document says, "To minimize risk, an operator sho= uld use transition technologies for the less dominant addre= ss family if possible." I don't think the driver is address fa= mily dominance, but availability.  If operators can get  native v6 to the edge, they should do it, even if v6 is not dom= inant (otherwise we could be stuck in 6RD mode for a while, even when nativ= e v6 is available).=   On the v4 side, operators won't deploy = a transition technology until they run out of addresses. Then the choice is= btw NAT444 and DS-Lite (or if we're really lucky, NAT64). Perhaps this is = what you mean by dominant? You won=92t use any as long as you can get addre= sses, but once you run out, you might make the choice of base A-F based on = dominance/maturity/stability?

<= /font>
I'll send copy-edits to the authors= in a separate email.

Chris

From: Fred Baker &l= t;fred@cisco.com>
Date: Sun, 13 May 2012 12:01:41 -0600
To: "v6ops@ietf.org" <v6ops@= ietf.org>
Cc: "v6ops-chairs@tools.ietf.org&= quot; <v6ops-chairs@tools= .ietf.org>, Ronald Bonica <ron@= bonica.org>
Subject: [v6= ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC

The working gro= up last call for this draft announced last week continues for another week.= Please feel free to comment on it.

--_000_CBDC31945325Fcdonleycablelabscom_-- From randy@psg.com Fri May 18 16:52:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02D621F84A7 for ; Fri, 18 May 2012 16:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHwBYwB0Sv6R for ; Fri, 18 May 2012 16:52:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A271221F8602 for ; Fri, 18 May 2012 16:52:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SVWyY-0004wu-M2; Fri, 18 May 2012 23:52:51 +0000 Date: Sat, 19 May 2012 08:52:49 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <4FB66F2C.5040304@inex.ie> References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5FC8B.8040806@gmail.com> <4FB66F2C.5040304@inex.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 May 2012 23:52:54 -0000 >> http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes > In fact, Martin has been pushing this at various conferences outside > the IETF arena. [ not judging this rightly or wrongly ] it is an ieee standard, and that is the only place where it can be meaningfully pushed. and they have pretty firmly said "hell no" for over a decade. so configure it with a friend in the privacy of your own link or within your own datacenter. randy From mawatari@jpix.ad.jp Fri May 18 19:28:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6494021F8661 for ; Fri, 18 May 2012 19:28:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyibnb1ybca3 for ; Fri, 18 May 2012 19:28:29 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id C641C21F865C for ; Fri, 18 May 2012 19:28:28 -0700 (PDT) Received: from [192.168.1.5] (i114-185-194-56.s42.a013.ap.plala.or.jp [114.185.194.56]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 41463FC021; Sat, 19 May 2012 11:28:27 +0900 (JST) Date: Sat, 19 May 2012 11:28:26 +0900 From: MAWATARI Masataka To: despres.remi@laposte.net In-Reply-To: <8F5B353B-D92E-44F8-8211-300C463EB4C3@laposte.net> References: <20120518183342kawashimam@mail.jp.nec.com> <8F5B353B-D92E-44F8-8211-300C463EB4C3@laposte.net> Message-Id: <20120519112826.C685.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 02:28:29 -0000 Dear Remi-san and all, Thank you for your comments. We, 464XLAT co-authors, do not reject the benefit of using NAT44 with IANA's EUI-64 ID. Please correct this misinterpretation. But, we do not understand that you stick with describing only one model (no dedicated IPv6 prefix model by using NAT44 with IANA's EUI-64 ID) on 464XLAT document. Sorry, if I'm wrong about this point. Excuse me for writing again, 464XLAT co-authors' belief about describing 2 models on 464XLAT document is as below. http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html Of course, we understood BIH even now. Kind Regards, Masataka MAWATARI * On Fri, 18 May 2012 16:03:08 +0200 * Admin wrote: > 18 mai 2012 b11:33, Masanobu Kawashima : > > > > > Hi Remi, > > > > Thank you for your comment. > > > >> This isn't an answer to my question: "why using the IANA's EUI + > >> NAT44 model wouldn't work also if DHCPv6 is operational"? > > > > I think that it would work even if DHCPv6-PD is operational. > > However, using the IANA's EUI + NAT44 model does not comply > > the following part of RFC6145. > > > > Quote of section 4.1. in RFC6145. > > > > "Translating IPv4 Headers into IPv6 Headers" > > > > (snip) > > > > Source Address: The IPv4-converted address derived from the IPv4 > > source address per [RFC6052], Section 2.3. > > > > If the translator gets an illegal source address (e.g., 0.0.0.0, > > 127.0.0.1, etc.), the translator SHOULD silently drop the packet > > (as discussed in Section 5.3.7 of [RFC1812]). > > > > Addition to this, some operators or implementors will choose > > dedicated IPv6 prefix model in order to avoid operational difficulty > > and implementation complexity. > > Not understood where IANA's CLAT IID would introduce "operational difficulty > and implementation complexity" (in my understanding, negligible implementation > difference, and simpler operation with the IANA CLAT IID). > > Documenting at least one configuration where you this to apply would be clarifying. > > RD > > > > Therefore, we need two models. > > > > I prefer simple combination with RFC6145 and RFC6146. > > That is our essential motivation. > > > > Regards, > > Masanobu From hesham@elevatemobile.com Fri May 18 19:39:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8AB21F8675 for ; Fri, 18 May 2012 19:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu3XUMVAwjeT for ; Fri, 18 May 2012 19:39:09 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAF621F8673 for ; Fri, 18 May 2012 19:39:08 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SVZZM-0001J6-Cy; Sat, 19 May 2012 12:39:00 +1000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 19 May 2012 12:38:38 +1000 From: Hesham Soliman To: "Templin, Fred L" , Gert Doering Message-ID: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 02:39:09 -0000 Fred, Just for the record, you're not introducing router fragmentation. The router here is the originator of the new packet, so you're not breaking anything in IPv6 in your idea, which I don't have an opinion on btw. Hesham -----Original Message----- From: "Templin, Fred L" Date: Fri, 18 May 2012 13:32:40 -0700 To: Gert Doering Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis > > >> -----Original Message----- >> From: Gert Doering [mailto:gert@space.net] >> Sent: Friday, May 18, 2012 1:29 PM >> To: Templin, Fred L >> Cc: Shishio Tsuchiya; gert@space.net; v6ops@ietf.org >> Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >> >> Hi, >> >> On Fri, May 18, 2012 at 11:38:27AM -0700, Templin, Fred L wrote: >> > ...and, here's the draft: >> > >> > http://www.ietf.org/internet-drafts/draft-foo-v6ops-6rdmtu-00.txt >> >> Am I understanding this right that you're proposing to re-introduce >> router fragmentation to IPv6? > >Well, for some special cases of router, yes. > >> I wasn't there when this was declared an absolute no-go some hundred >> years ago, so I'm just staring in blank amazement... > >It's heresy, I know. But, do you see anything wrong >with it? > >Thanks - Fred >fred.l.templin@boeing.com > >> Gert Doering >> -- Operator >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- >> Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Fri May 18 23:53:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3604321F8692 for ; Fri, 18 May 2012 23:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFCnQ++YH3G0 for ; Fri, 18 May 2012 23:53:03 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 374A621F8693 for ; Fri, 18 May 2012 23:53:02 -0700 (PDT) Received: from [192.168.1.28] ([89.170.204.45]) by mwinf8507-out with ME id Bisw1j0050zHM1D03iswMk; Sat, 19 May 2012 08:53:00 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Admin In-Reply-To: <20120519112826.C685.8FE1F57E@jpix.ad.jp> Date: Sat, 19 May 2012 08:52:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120518183342kawashimam@mail.jp.nec.com> <8F5B353B-D92E-44F8-8211-300C463EB4C3@laposte.net> <20120519112826.C685.8FE1F57E@jpix.ad.jp> To: MAWATARI Masataka , Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 06:53:04 -0000 Mawartari-san, Masanobu-san, 2012-05-19 04:28:26, MAWATARI Masataka: > Dear Remi-san and all, >=20 >=20 > Thank you for your comments. >=20 > We, 464XLAT co-authors, do not reject the benefit of using NAT44 > with IANA's EUI-64 ID. =20 Well understood. Thanks. > Please correct this misinterpretation. No need, see above. > But, we do not understand that you stick with describing only one > model (no dedicated IPv6 prefix model by using NAT44 with IANA's > EUI-64 ID) on 464XLAT document. 1. I have, as I said, no objection to a publication with the two models if = status is Informational. 2. Reasons why, at least as long as CLAT nodes are CPEs, the CLAT single = address model is IMHO sufficient in a BCP are: - Doubt that vendors would market new CPEs unable to support NAT44.=20 - With that, CLATs can work with ordinary NAT64s without needing more = than their ordinary IPv6 prefixes, which is simpler. =3D> If BCP is the desired status, more explanation would be needed = AFAIAC.=20 Regards, RD > Sorry, if I'm wrong about this point. >=20 > Excuse me for writing again, 464XLAT co-authors' belief about > describing 2 models on 464XLAT document is as below. > http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html >=20 > Of course, we understood BIH even now. >=20 >=20 > Kind Regards, > Masataka MAWATARI >=20 >=20 >=20 > * On Fri, 18 May 2012 16:03:08 +0200 > * Admin wrote: >=20 >> 18 mai 2012 b11:33, Masanobu Kawashima : >>=20 >>>=20 >>> Hi Remi, >>>=20 >>> Thank you for your comment. >>>=20 >>>> This isn't an answer to my question: "why using the IANA's EUI + >>>> NAT44 model wouldn't work also if DHCPv6 is operational"? >>>=20 >>> I think that it would work even if DHCPv6-PD is operational. >>> However, using the IANA's EUI + NAT44 model does not comply >>> the following part of RFC6145. >>>=20 >>> Quote of section 4.1. in RFC6145. >>>=20 >>> "Translating IPv4 Headers into IPv6 Headers" >>>=20 >>> (snip) >>>=20 >>> Source Address: The IPv4-converted address derived from the IPv4 >>> source address per [RFC6052], Section 2.3. >>>=20 >>> If the translator gets an illegal source address (e.g., 0.0.0.0, >>> 127.0.0.1, etc.), the translator SHOULD silently drop the packet >>> (as discussed in Section 5.3.7 of [RFC1812]). >>>=20 >>> Addition to this, some operators or implementors will choose >>> dedicated IPv6 prefix model in order to avoid operational difficulty >>> and implementation complexity. >>=20 >> Not understood where IANA's CLAT IID would introduce "operational = difficulty >> and implementation complexity" (in my understanding, negligible = implementation >> difference, and simpler operation with the IANA CLAT IID). >>=20 >> Documenting at least one configuration where you this to apply would = be clarifying. >>=20 >> RD >>=20 >>=20 >>> Therefore, we need two models. >>>=20 >>> I prefer simple combination with RFC6145 and RFC6146. >>> That is our essential motivation. >>>=20 >>> Regards, >>> Masanobu >=20 From brian.e.carpenter@gmail.com Fri May 18 23:57:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6A21F8692 for ; Fri, 18 May 2012 23:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0VCbL25YCn6 for ; Fri, 18 May 2012 23:57:32 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92B6921F8679 for ; Fri, 18 May 2012 23:57:32 -0700 (PDT) Received: by werb13 with SMTP id b13so1093034wer.31 for ; Fri, 18 May 2012 23:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0RSGWtmZzzNrufmhJWYJjuLxKJCOZxUm9BORkKWUuoI=; b=Jdzi7SRe2yaIoMze78I9nrRGOzQkLYQFy5l9E5ZfnlLGvpDgBqZDRw4asqdHViRPLF oIv/b1AHcqSzhQToU42Y/pCl9MM/MmHKadhu7M+jlcgO10JoFfytHZ6v4u9c3LmZP+j9 XMr5ey7AoR125Gaed9jEM4PnYACtPEeV844JXwclRZqadNfl/fqcZRjJR5ktyFZdudKt p+flNwTxyEWYlsJnqxh9mDVgTjpU82LdNUFbhCgtvRqDtwjhUQsmIpw4YcB5U7aI51MY JNb303iNZgLOLQtE/GZu6i/GRkA9ipQyq2fn94NQQNxnjv5dBMK2uu1yB4qlSaKj/7BK Cj9Q== Received: by 10.216.54.206 with SMTP id i56mr9240128wec.28.1337410651736; Fri, 18 May 2012 23:57:31 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-67.as13285.net. [2.102.216.67]) by mx.google.com with ESMTPS id gb9sm6805257wib.8.2012.05.18.23.57.30 (version=SSLv3 cipher=OTHER); Fri, 18 May 2012 23:57:30 -0700 (PDT) Message-ID: <4FB74456.2090009@gmail.com> Date: Sat, 19 May 2012 07:57:26 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5A28B.8000701@cisco.com> <20120518202923.GW84425@Space.Net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 06:57:33 -0000 On 2012-05-18 21:32, Templin, Fred L wrote: > >> -----Original Message----- >> From: Gert Doering [mailto:gert@space.net] >> Sent: Friday, May 18, 2012 1:29 PM >> To: Templin, Fred L >> Cc: Shishio Tsuchiya; gert@space.net; v6ops@ietf.org >> Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >> >> Hi, >> >> On Fri, May 18, 2012 at 11:38:27AM -0700, Templin, Fred L wrote: >>> ...and, here's the draft: >>> >>> http://www.ietf.org/internet-drafts/draft-foo-v6ops-6rdmtu-00.txt >> Am I understanding this right that you're proposing to re-introduce >> router fragmentation to IPv6? > > Well, for some special cases of router, yes. > >> I wasn't there when this was declared an absolute no-go some hundred >> years ago, so I'm just staring in blank amazement... > > It's heresy, I know. But, do you see anything wrong > with it? A more interesting heresy would be to remove fragmentation from IPv6 entirely. There's already a rule that any layer 2 used for IPv6 must carry a payload of at least 1280 bytes: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. [RFC2460 section 5] That is necessary and sufficient to make the Internet work. Can somebody remember why we added the complication of fragmentation? Brian From despres.remi@laposte.net Sat May 19 00:32:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3330421F86A5 for ; Sat, 19 May 2012 00:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvBffkhNuiml for ; Sat, 19 May 2012 00:32:38 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 6752621F869A for ; Sat, 19 May 2012 00:32:37 -0700 (PDT) Received: from [192.168.1.28] ([89.170.204.45]) by mwinf8507-out with ME id BjYa1j0080zHM1D03jYaFQ; Sat, 19 May 2012 09:32:35 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-2022-jp From: Admin In-Reply-To: <20120518183342kawashimam@mail.jp.nec.com> Date: Sat, 19 May 2012 09:32:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <813FF89D-FBAF-4634-BF35-E6021D1777E0@laposte.net> References: <4FA00849-4076-4033-B78A-21F6D26633CB@laposte.net> <20120518183342kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 07:32:39 -0000 Masanobu-san, Thank you for the explanation below. Formally, you are right: RFC6145 doesn't cover the case where there is = only one IPv4 address on the IPv4 side, and where therefore a fixed IPv6 = address, non IPv4 translated, can be used. OTOH, RFC 6052 says, about Stateless translation "Both IPv4-translatable = IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same = prefix". Using different IPv6 prefixes for customer-side and = Internbet-side IPv4 addresses would introduce an exception to this rule, = with the need to explain. The IANA EUI-64 interface ID remains IMHO worth using, at least when = CLAT nodes contain NAT44s. Regards, RD 2012-05-18 11:33:41, Masanobu Kawashima: >=20 > Hi Remi, >=20 > Thank you for your comment. >=20 >> This isn't an answer to my question: "why using the IANA's EUI + >> NAT44 model wouldn't work also if DHCPv6 is operational"? >=20 > I think that it would work even if DHCPv6-PD is operational. > However, using the IANA's EUI + NAT44 model does not comply > the following part of RFC6145. >=20 > Quote of section 4.1. in RFC6145. >=20 > "Translating IPv4 Headers into IPv6 Headers" >=20 > (snip) >=20 > Source Address: The IPv4-converted address derived from the IPv4 > source address per [RFC6052], Section 2.3. This case is however useful since it permits the CLAT model to apply = with nothing more than=20 =20 >=20 > If the translator gets an illegal source address (e.g., 0.0.0.0, > 127.0.0.1, etc.), the translator SHOULD silently drop the packet > (as discussed in Section 5.3.7 of [RFC1812]). >=20 > Addition to this, some operators or implementors will choose > dedicated IPv6 prefix model in order to avoid operational difficulty > and implementation complexity. >=20 > Therefore, we need two models. >=20 > I prefer simple combination with RFC6145 and RFC6146. > That is our essential motivation. >=20 > Regards, > Masanobu >=20 >=20 >>=20 >> Le 18 mai 2012 08:45:29, Lorenzo Colitti a =1B$BqD=1B(Brit : >>=20 >>> On Fri, May 18, 2012 at 3:42 PM, Admin = wrote: >>>> and "dedicated IPv6 prefix model >>>> without NAT44" is appropriate for the service that can utilize >>>> DHCPv6-PD (e.g. most of wireline services). >>>=20 >>> Don't understand why the IANA's EUI-64 ID wouldn't be appropriate = for this case too. >>> Could you explain? >>>=20 >>> This model works by statelessly mapping the IPv4 addresses of CLAT = clients into IPv6 addresses of the given prefix. So it obviously doesn't = use a fixed interface ID. >>=20 >> This isn't an answer to my question: "why using the IANA's EUI + = NAT44 model wouldn't work also if DHCPv6 is operational"? >>=20 >> RD >>=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 > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =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 >=20 From gert@space.net Sat May 19 00:58:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F3C21F86D1 for ; Sat, 19 May 2012 00:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yK28OOxXKZn for ; Sat, 19 May 2012 00:58:52 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id E5CA821F86B0 for ; Sat, 19 May 2012 00:58:50 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B3CA4F8B02 for ; Sat, 19 May 2012 09:58:49 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 857EBF8B10 for ; Sat, 19 May 2012 09:58:49 +0200 (CEST) Received: (qmail 45926 invoked by uid 1007); 19 May 2012 09:58:49 +0200 Date: Sat, 19 May 2012 09:58:49 +0200 From: Gert Doering To: Hesham Soliman Message-ID: <20120519075849.GY84425@Space.Net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YWN6XEovrqUgNPhM" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 07:58:52 -0000 --YWN6XEovrqUgNPhM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, May 19, 2012 at 12:38:38PM +1000, Hesham Soliman wrote: > Just for the record, you're not introducing router fragmentation. The > router here is the originator of the new packet, so you're not breaking > anything in IPv6 in your idea, which I don't have an opinion on btw. The router is creating a new *IPv4* packet, and packing the existing=20 IPv6 packet into it. It's not creating a new IPv6 packet. If the 6rd router were to be fragmenting the external *IPv4* packet, there would not be anything spectacular about this proposal. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --YWN6XEovrqUgNPhM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT7dSuakuBuNlUUl1AQLongQAmrS0DVkvLOCqXFZn0FHUPNFTpZ2ar4Ye aNpxcR7oHO0qcMIRCVDyVixWci5MjjnnKwqjZOIM3xRTeRxinkLkB2UofzkA3CeB gI9I+lz5nJJWgE4lSStd5tNALgRDgTgat9rzTYKlMfDO6C2Ndm6cgpXlLLurGNBn 7QQ4BF5bb4U= =biCs -----END PGP SIGNATURE----- --YWN6XEovrqUgNPhM-- From gert@space.net Sat May 19 01:00:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA07521F84FF for ; Sat, 19 May 2012 01:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RugUPSzG7sdH for ; Sat, 19 May 2012 01:00:07 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 03B2821F84FE for ; Sat, 19 May 2012 01:00:07 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 5FD39F8B17 for ; Sat, 19 May 2012 10:00:06 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4CF43F8B0E for ; Sat, 19 May 2012 10:00:06 +0200 (CEST) Received: (qmail 47136 invoked by uid 1007); 19 May 2012 10:00:06 +0200 Date: Sat, 19 May 2012 10:00:06 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20120519080006.GZ84425@Space.Net> References: <4FB5A28B.8000701@cisco.com> <20120518202923.GW84425@Space.Net> <4FB74456.2090009@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dfcVzwpUDf6GsZpj" Content-Disposition: inline In-Reply-To: <4FB74456.2090009@gmail.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 08:00:07 -0000 --dfcVzwpUDf6GsZpj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, May 19, 2012 at 07:57:26AM +0100, Brian E Carpenter wrote: > That is necessary and sufficient to make the Internet work. Can somebody > remember why we added the complication of fragmentation? UDP packets larger than 1280 bytes, and link-layers that are a) limited in packet size, and b) have no reasonable way to do on-link fragmentation and reassembly, like "Ethernet". Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --dfcVzwpUDf6GsZpj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT7dTBqkuBuNlUUl1AQLJ6gP/SdanCj42hmiX40HtdpsE/MP3sbv8/Rdt mcjaIAnqr3hPuLgEpGWrZBugOjCwoSsSit7/xXMc1OLOMz32YleO546KNP9tR5Vb vDYmZrADUC7niSCl+hyryWAP0cv2uxB+vicPo0nxWG7Vc7wZyOP9aGp4l7CfoZpV rxPovuTBzf8= =VFmT -----END PGP SIGNATURE----- --dfcVzwpUDf6GsZpj-- From brian.e.carpenter@gmail.com Sat May 19 03:27:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9E21F85C7 for ; Sat, 19 May 2012 03:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0FJewOZonqZ for ; Sat, 19 May 2012 03:27:52 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A379521F85C2 for ; Sat, 19 May 2012 03:27:52 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so746947wib.13 for ; Sat, 19 May 2012 03:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bL6ZtMxk7ybL2eBgh32pOBWrdb1vXLQHnXaL4XV4vjg=; b=PHK0xxIs9kfuyiofx/F9FN7fpjHZmNfRJopo90i5DW6WbCialiyCK8QXKs3cHaVwR1 2Tcpzodbd0lmGezDYXc+eOTyA2ZbX6zh9Uza4tomkeTKR9lvdRCeXsBB0gQNxyIvKk8Y fTIo7WXuI1HccvpF6hYSYKm2JqjNP7kNSPgsLFSQDSkAO2K1+hITBnDh1r3cTrEYk/0f eoDHHV9MnmgsNszNYaO4nUNdT4UEmWblj/nkU8LXSxyX7TN3Mw08q/cLBJGgNIYJYMj3 cVpeMhWkIF8NoH3/nCiBKe6SP75hKnI4Q81Pm9FzaywuS12gW2gf5O278p6OXJy8yK9P C2Rw== Received: by 10.180.82.5 with SMTP id e5mr9400367wiy.0.1337423271835; Sat, 19 May 2012 03:27:51 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-67.as13285.net. [2.102.216.67]) by mx.google.com with ESMTPS id m1sm8199526wic.6.2012.05.19.03.27.49 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 03:27:50 -0700 (PDT) Message-ID: <4FB775A3.1030900@gmail.com> Date: Sat, 19 May 2012 11:27:47 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <4FB5A28B.8000701@cisco.com> <20120518202923.GW84425@Space.Net> <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> In-Reply-To: <20120519080006.GZ84425@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 10:27:53 -0000 On 2012-05-19 09:00, Gert Doering wrote: > Hi, > > On Sat, May 19, 2012 at 07:57:26AM +0100, Brian E Carpenter wrote: >> That is necessary and sufficient to make the Internet work. Can somebody >> remember why we added the complication of fragmentation? > > UDP packets larger than 1280 bytes Don't do that! > and link-layers that are a) limited in > packet size, and b) have no reasonable way to do on-link fragmentation and > reassembly, like "Ethernet". That is *specifically* excluded by the text in 2460: if you have such a link, you must insert an adaptation layer - it is not covered by layer 3. Brian From nick@inex.ie Sat May 19 03:41:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B785D21F846E for ; Sat, 19 May 2012 03:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVlnvpdvRu+r for ; Sat, 19 May 2012 03:41:24 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1614921F846F for ; Sat, 19 May 2012 03:41:23 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org ([IPv6:2001:4d68:2002:100:5d90:947b:bd6:3840]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q4JAeUEP006763 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 19 May 2012 11:40:35 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FB778C5.6030009@inex.ie> Date: Sat, 19 May 2012 11:41:09 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Randy Bush References: <20120517114252.GI84425@Space.Net> <20120517195110.GJ84425@Space.Net> <4FB5FC8B.8040806@gmail.com> <4FB66F2C.5040304@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 PMTU works?? [proposed TCP MSS text for rfc6204bis] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 10:41:24 -0000 On 19/05/2012 00:52, Randy Bush wrote: > it is an ieee standard, and that is the only place where it can be > meaningfully pushed. and they have pretty firmly said "hell no" for > over a decade. they may have said no, however that hasn't stopped pretty much every nic manufacturer in the world supporting 9k mtu on their devices, even on trashy low-end kit. > so configure it with a friend in the privacy of your own link or within > your own datacenter. I think you're right here. There are some technologies which don't tend to work well on interconnection links due to different expectations on each side. This is one of them. fwiw, inex still has a 9k mtu vlan (full of tumbleweed) but we're very clear that our primary peering vlans are 1500 only. We may try to resuscitate the 9k mtu vlan at some stage in the future. anyway, this is well off topic. Nick From sthaug@nethelp.no Sat May 19 05:19:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FD621F85F8 for ; Sat, 19 May 2012 05:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRr08CYUcYVO for ; Sat, 19 May 2012 05:19:09 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 8E32321F85DF for ; Sat, 19 May 2012 05:19:08 -0700 (PDT) Received: (qmail 2656 invoked from network); 19 May 2012 12:19:06 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 19 May 2012 12:19:06 -0000 Date: Sat, 19 May 2012 14:19:06 +0200 (CEST) Message-Id: <20120519.141906.74656347.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com From: sthaug@nethelp.no In-Reply-To: <4FB775A3.1030900@gmail.com> References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 12:19:09 -0000 > >> That is necessary and sufficient to make the Internet work. Can somebody > >> remember why we added the complication of fragmentation? > > > > UDP packets larger than 1280 bytes > > Don't do that! It sounds like you're saying that we should expect IPv6 to work less well than IPv4. Surely I'm misunderstanding? > > and link-layers that are a) limited in > > packet size, and b) have no reasonable way to do on-link fragmentation and > > reassembly, like "Ethernet". > > That is *specifically* excluded by the text in 2460: if you have such a > link, you must insert an adaptation layer - it is not covered by layer 3. So we shouldn't be able to send large IPv6 datagrams on Ethernet. Or? I think these points are probably down in the noise when it comes to actually getting IPv6 deployed. Nevertheless, they are important to some people. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From fred@cisco.com Sat May 19 05:46:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39E021F8513 for ; Sat, 19 May 2012 05:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjdj5cpuOdMv for ; Sat, 19 May 2012 05:46:46 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7697A21F8504 for ; Sat, 19 May 2012 05:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=124; q=dns/txt; s=iport; t=1337431606; x=1338641206; h=date:from:message-id:to:subject:cc; bh=/50QhkWk4dHNtb+HsZ7CFVaf9aMJEyEI7N0kuwFsx9c=; b=eDYe1TXQCBThqe5yKyktCtUAArH+DbRCSdwocah/r8k6SilNgL4sL1Xc r+p3IuM26eeHJ8WlQu+rw2uUfDR8/YZK0+610FTBDLVBcCQMIqxmg3AcC ABJe1qa81QWV6p4Zp4ggnXXSVo9NAihDepe1QQTJcB6DomxpDEX0eUoY3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4IAPuVt0+rRDoG/2dsb2JhbABFohIBkXiBB4IuAWY8LYEKh2sMnF+fYI00gjxiA4hCjWiMfYFkgwk X-IronPort-AV: E=Sophos;i="4.75,621,1330905600"; d="scan'208";a="42396390" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 19 May 2012 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4JCj1Zr027188; Sat, 19 May 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q4JCj1B08991; Sat, 19 May 2012 05:45:01 -0700 (PDT) Date: Sat, 19 May 2012 05:45:01 -0700 (PDT) From: Message-Id: <201205191245.q4JCj1B08991@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-foo-v6ops-6rdmtu@tools.ietf.org Subject: [v6ops] new draft: draft-foo-v6ops-6rdmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 12:46:47 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-foo-v6ops-6rdmtu. Please take a look at it and comment. From fred@cisco.com Sat May 19 05:48:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9F621F856C for ; Sat, 19 May 2012 05:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvNykHEbuF8x for ; Sat, 19 May 2012 05:48:41 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4458021F8552 for ; Sat, 19 May 2012 05:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=123; q=dns/txt; s=iport; t=1337431721; x=1338641321; h=date:from:message-id:to:subject:cc; bh=ArxGBQjkGOqHlAkL27pZc9W+QeggZL6auKoPbOWr7FY=; b=ltKvPnK4X18eteD43ozpWvQl8IvNNG+waRMOOURdMQ6rFfOKe/TwmBdp ZMkqKAQ824KWIaQ+wv/aHPGiVXCGKxi+YFu0lSDoPtIHqtRzG41MG5RhE B51hnwulu3hg+YYwyWh2ieHriHBq87cOnqJleIV3+I4i6n4FlOb7qFInf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEALqVt0+rRDoJ/2dsb2JhbABFtAuBB4IuAWY8LYEKh2sMnF6fYI00gx4DiEKNaIx9gWSDCQ X-IronPort-AV: E=Sophos;i="4.75,621,1330905600"; d="scan'208";a="42936006" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 19 May 2012 12: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.3/8.14.3) with ESMTP id q4JCj1Cp009305; Sat, 19 May 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q4JCj0q08985; Sat, 19 May 2012 05:45:00 -0700 (PDT) Date: Sat, 19 May 2012 05:45:00 -0700 (PDT) From: Message-Id: <201205191245.q4JCj0q08985@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-bar-v6ops-ismtu@tools.ietf.org Subject: [v6ops] new draft: draft-bar-v6ops-ismtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 12:48:41 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-bar-v6ops-ismtu. Please take a look at it and comment. From brian.e.carpenter@gmail.com Sat May 19 07:01:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679DB21F860E for ; Sat, 19 May 2012 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnNrvE6nG9oQ for ; Sat, 19 May 2012 07:01:54 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4D0721F85FC for ; Sat, 19 May 2012 07:01:53 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2512241wgb.13 for ; Sat, 19 May 2012 07:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RN/WI5l31MMFQvMmM51AuAwtE7fRvONXlLYiCk+CL1E=; b=ZTu5iwE9nrUdL5CdOrrU2tE4zIAdAuv0yUOuUrspIfTdqoGEzNg48Vgm8Dp3Zndp1o MuGwqW6vx6L7GXPNvq9H4DhtprZCIrnthg0eevp2KYN79QLn1NSWAJfO69TGhXat7fWr I6aW0pUh+4CNNMzS/UCmrpXLtcrWdo4+KsfFWgl0qWPm77556dtswyaRXVcyzvkURf9m Dft/JyQYYY35bob8ju4ulPl1iWd5EaSsqlzG2YUB7TkVvYfD1PacHkkP5JSDhjZm/Tgk heqXBtmyGYz6v8HFmq+sL1ODuaaZY5aBJiy96X97IUqH6BBwqAXbZntnLfY+O38OAju9 Sgag== Received: by 10.180.82.195 with SMTP id k3mr10358875wiy.9.1337436112933; Sat, 19 May 2012 07:01:52 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-67.as13285.net. [2.102.216.67]) by mx.google.com with ESMTPS id dg2sm14935874wib.4.2012.05.19.07.01.51 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 07:01:51 -0700 (PDT) Message-ID: <4FB7A7CC.6060503@gmail.com> Date: Sat, 19 May 2012 15:01:48 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sthaug@nethelp.no References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> In-Reply-To: <20120519.141906.74656347.sthaug@nethelp.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 14:01:54 -0000 On 2012-05-19 13:19, sthaug@nethelp.no wrote: >>>> That is necessary and sufficient to make the Internet work. Can somebody >>>> remember why we added the complication of fragmentation? >>> UDP packets larger than 1280 bytes >> Don't do that! > > It sounds like you're saying that we should expect IPv6 to work less > well than IPv4. Surely I'm misunderstanding? What I am saying (and remember this is heresy) is that apps that assume that large UDP packets will arrive, without any kind of trial-and-error approach, are badly designed. There's always going to be a finite PMTU. > >>> and link-layers that are a) limited in >>> packet size, and b) have no reasonable way to do on-link fragmentation and >>> reassembly, like "Ethernet". >> That is *specifically* excluded by the text in 2460: if you have such a >> link, you must insert an adaptation layer - it is not covered by layer 3. > > So we shouldn't be able to send large IPv6 datagrams on Ethernet. Or? If you want to send packets of arbitrary size, in any environment where PMTUD is impossible or fails, won't you need to always include a fragmentation header in every packet greater than 1280? > I think these points are probably down in the noise when it comes to > actually getting IPv6 deployed. Nevertheless, they are important to > some people. Well, I was an advocate for RFC 2675 since it seemed important where I worked at that time: "The Jumbo Payload option is relevant only for IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets (that is, 65,535 + 40, where 40 octets is the size of the IPv6 header)... The Jumbo Payload option must not be used in a packet that carries a Fragment header." In other words people who need really big packets know that they must avoid fragmentation. Getting back to the topic at hand, I've reached the conclusion (by a sort of reductio ad absurdum) that expecting an off-the-shelf CPE to fix this problem is unreasonable. Brian From victor.kuarsingh@gmail.com Sat May 19 07:31:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DDC21F8518 for ; Sat, 19 May 2012 07:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfmPCsCBPv83 for ; Sat, 19 May 2012 07:31:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 443BD21F8501 for ; Sat, 19 May 2012 07:31:36 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so6686873obb.31 for ; Sat, 19 May 2012 07:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=L+EVUS/lLbBCwX0iXd6MjLMDVgEUhkLQXBAHgPjoHhA=; b=kPHbY9ltlWDMiHTvVTOaSZpMc+/tb2k6FGA5fCLzbz21iT97di4EPVqGB580CcT3jq w0zRLJDcILtp1xDGiy12kj5IKsxoz47wIOIn6nBH9LcKbh8EtobmF4EYLe5sUCtKzZJZ YPCKO5KY1OaxvkmWAQPTUIVv5nI9kgcj0zdS+gIR5WKrsA8yxdaLOv0uPL93qKSICCbo aLu/YVc7NUUZwfsDRbMPJVuBlAQ5oJhg33c4Yl7hPejaOHS2aDefjQFyJiQCWLuWxMws Yjon72h3rUOP25n5knRNJ7FjX8jBY3r3+652K2uZp+WY1X7wIppnb/KIwD1gvSl9abou 82TA== Received: by 10.50.159.134 with SMTP id xc6mr3179540igb.41.1337437895812; Sat, 19 May 2012 07:31:35 -0700 (PDT) Received: from [192.168.1.2] ([74.198.164.15]) by mx.google.com with ESMTPS id k6sm4939973igw.14.2012.05.19.07.31.30 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 07:31:33 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sat, 19 May 2012 10:31:29 -0400 From: Victor Kuarsingh To: Chris Donley , Fred Baker , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3420268296_1789749" Cc: "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 14:31:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3420268296_1789749 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Fred, I will add the updates from this review to the others noted throughout the WGLC for next update. Regards, Victor K From: Chris Donley Date: Fri, 18 May 2012 17:13:27 -0600 To: Fred Baker , "v6ops@ietf.org" Cc: "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC I reviewed the document, and think it does a good job outlining the transition path(s). I think it'll be ready to advance once comments are addressed. One comment wrt Section 3.5. The document says, "To minimize risk, an operator should use transition technologies for the less dominant address family if possible." I don't think the driver is address family dominance, but availability. If operators can get native v6 to the edge, they should do it, even if v6 is not dominant (otherwise we could be stuck in 6RD mode for a while, even when native v6 is available). On the v4 side, operators won't deploy a transition technology until they run out of addresses. Then the choice is btw NAT444 and DS-Lite (or if we're really lucky, NAT64). Perhaps this is what you mean by dominant? You won=B9t use any as long as you can get addresses, but once you run out, you might make the choice of base A-F based on dominance/maturity/stability? I'll send copy-edits to the authors in a separate email. Chris From: Fred Baker Date: Sun, 13 May 2012 12:01:41 -0600 To: "v6ops@ietf.org" Cc: "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-wireline-incremental-ipv6 WGLC The working group last call for this draft announced last week continues fo= r another week. Please feel free to comment on it. =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3420268296_1789749 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Fred,

I will add the updates from this review to the others noted throughout th= e WGLC for next update.

Regards,

Victor K

From: Chris Donley <C.Donley@CableLab= s.com>
Date: Fri, 18 May 20= 12 17:13:27 -0600
To: Fred Baker &= lt;fred@cisco.com>, "v6ops@ietf.org" <v6op= s@ietf.org>
Cc: "v6ops-chairs@tools.ietf.org" <v6ops-chairs@tools.ietf.org>= , Ronald Bonica <ron@bonica.org>Subject: Re: [v6ops] Reminder: draf= t-ietf-v6ops-wireline-incremental-ipv6 WGLC

I reviewed the document, and think = it does a good job outlining the transition path(s). I think it'll be ready = to advance once comments are addressed.

One comment wrt Section 3.5.  The document says, "To min= imize risk, an operator should use transition technologies for th= e less dominant address family if possible." I don't think the driver is address family dom= inance, but availability.&n= bsp; If operators can get  native v6 to the edge, = they should do it, even if v6 is not dominant (otherwise we could be stuck i= n 6RD mode for a while, even when native v6 is available).  On the v4 side= , operators won't deploy a transition technology until they run out of addre= sses. Then the choice is btw NAT444 and DS-Lite (or if we're really lucky, N= AT64). Perhaps this is what you mean by dominant? You won’t use any as= long as you can get addresses, but once you run out, you might make the cho= ice of base A-F based on dominance/maturity/stability?

I'll send copy-edits to the authors in= a separate email.

Chris

F= rom: Fred Baker <fred@cisco.com>
Date: Sun, 13 May 2012 12:0= 1:41 -0600
To: "v6ops@ietf.org" <v6ops@= ietf.org>
Cc: "v6ops-chairs@tools.ietf.org" <v6ops-chairs@tools.ietf.org>, = Ronald Bonica <ron@bonica.org>
= Subject: [v6ops] Reminder: draft-ietf= -v6ops-wireline-incremental-ipv6 WGLC

The working group last call for this draft announced la= st week continues for another week. Please feel free to comment on it.

_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3420268296_1789749-- From fgont@si6networks.com Sat May 19 07:36:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0304421F8629 for ; Sat, 19 May 2012 07:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBgwGpz04u-W for ; Sat, 19 May 2012 07:36:55 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 57D0D21F8623 for ; Sat, 19 May 2012 07:36:55 -0700 (PDT) Received: from [186.134.9.156] (helo=[192.168.123.103]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SVkm5-00034M-Cz; Sat, 19 May 2012 16:36:54 +0200 Message-ID: <4FB79A70.9070904@si6networks.com> Date: Sat, 19 May 2012 10:04:48 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPv6 Operations References: <20120518052610.7838.76832.idtracker@ietfa.amsl.com> In-Reply-To: <20120518052610.7838.76832.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] New IETF I-D: draft-gont-opsec-dhcpv6-shield-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, 19 May 2012 14:36:56 -0000 Folks, We have published a new IETF I-D entitled: "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers". It is analogous to the RA-Guard (RFC 6105) mechanism currently employed for mitigating RA-based attacks. The I-D is available at: I'm not sure in which wg I'd be pursuing this effort (v6ops, opsec, or dhcwg). If there's interest in this wg, it could be done here (the obvious argument for pursuing this in v6ops is that this is heavily based on draft-ietf-v6ops-ra-guard-implementation, and hence the wg is already familiar with the idea). In any case, discussion of this document within v6ops would be welcome. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-opsec-dhcpv6-shield-00.txt Date: Thu, 17 May 2012 22:26:10 -0700 From: internet-drafts@ietf.org To: fgont@si6networks.com A new version of I-D, draft-gont-opsec-dhcpv6-shield-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-opsec-dhcpv6-shield Revision: 00 Title: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers Creation date: 2012-05-18 WG ID: Individual Submission Number of pages: 12 Abstract: This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ("DHCP snooping"), and hence it is desirable that similar functionality be provided for IPv6 networks. The IETF Secretariat -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gert@space.net Sat May 19 13:16:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E83C21F8547 for ; Sat, 19 May 2012 13:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48ixUBB+fo7p for ; Sat, 19 May 2012 13:16:15 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22021F8546 for ; Sat, 19 May 2012 13:16:14 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 063DDF8B15 for ; Sat, 19 May 2012 22:16:13 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id DD436F8B17 for ; Sat, 19 May 2012 22:16:12 +0200 (CEST) Received: (qmail 55825 invoked by uid 1007); 19 May 2012 22:16:12 +0200 Date: Sat, 19 May 2012 22:16:12 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20120519201612.GA84425@Space.Net> References: <20120518202923.GW84425@Space.Net> <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d24Pk/ipVQdCTZvo" Content-Disposition: inline In-Reply-To: <4FB775A3.1030900@gmail.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 20:16:16 -0000 --d24Pk/ipVQdCTZvo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, May 19, 2012 at 11:27:47AM +0100, Brian E Carpenter wrote: > On 2012-05-19 09:00, Gert Doering wrote: > > On Sat, May 19, 2012 at 07:57:26AM +0100, Brian E Carpenter wrote: > >> That is necessary and sufficient to make the Internet work. Can somebo= dy > >> remember why we added the complication of fragmentation? > >=20 > > UDP packets larger than 1280 bytes > Don't do that! Tell that to the DNS people. They seem to really like not-using-TCP. > > and link-layers that are a) limited in > > packet size, and b) have no reasonable way to do on-link fragmentation = and > > reassembly, like "Ethernet". >=20 > That is *specifically* excluded by the text in 2460: if you have such a > link, you must insert an adaptation layer - it is not covered by layer 3. Usually "Ethernet" is not considered a medium that needs an adaption layer... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --d24Pk/ipVQdCTZvo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT7f/jKkuBuNlUUl1AQL9dAQAgnxVNwZiim+UCYQIi5LOr75nxH9KVfm4 /Eob/XlXOT/aVJqvS4Xfq1Kg8xTskGaD1k2WbCtEHFRbucqQ2Zc/P2YE1RGUfhKj cTCjl+vxGkEAyU/sHL98IU4GVNDvXvk1Q+Kx/MYZHidHu7Sudk8HhFAOoOra0Ug7 lD51td8Bq4I= =OIng -----END PGP SIGNATURE----- --d24Pk/ipVQdCTZvo-- From randy@psg.com Sat May 19 14:26:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D82D21F8471 for ; Sat, 19 May 2012 14:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7PYsqlfbjBU for ; Sat, 19 May 2012 14:26:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C6DFB21F8469 for ; Sat, 19 May 2012 14:26:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SVrAi-0008v1-Tx; Sat, 19 May 2012 21:26:45 +0000 Date: Sun, 20 May 2012 06:26:43 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4FB7A7CC.6060503@gmail.com> References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 May 2012 21:26:48 -0000 > If you want to send packets of arbitrary size, in any environment > where PMTUD is impossible or fails, won't you need to always include > a fragmentation header in every packet greater than 1280? see discussion of jumbo frames, commonly 4k or 9k, between consenting adults on known links randy From joelja@bogus.com Sat May 19 21:11:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD46C11E8079 for ; Sat, 19 May 2012 21:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjhDJFwvxBsx for ; Sat, 19 May 2012 21:11:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A72521F8464 for ; Sat, 19 May 2012 21:11:43 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-76-115-174-157.hsd1.wa.comcast.net [76.115.174.157]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q4K4BgBg053085 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 20 May 2012 04:11:42 GMT (envelope-from joelja@bogus.com) Message-ID: <4FB86EF8.9030101@bogus.com> Date: Sat, 19 May 2012 21:11:36 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 20 May 2012 04:11:42 +0000 (UTC) Subject: [v6ops] 6204bis draft 09 - http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-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: Sun, 20 May 2012 04:11:45 -0000 In response to comments recieved during the 6204bis draft wglc and subsequent discsussion among the authors, draft 09 was produced. http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 diffs between the two are here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6204bis-09.txt please review by tue 5/22, this is the version that I plan on generating the document shepherds review from. It strikes me as unlikley that the current discussion on mtu/mss adjustment is going to produce a sustainable consensus and we should therefore consider where or whether or where to expose that problem in a document. Minor niggles can be corrected in auth-48, larger problems should not. thanks joel From brian.e.carpenter@gmail.com Sun May 20 00:03:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E6621F861B for ; Sun, 20 May 2012 00:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4fm9uMLU0Sk for ; Sun, 20 May 2012 00:03:23 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2F3721F861A for ; Sun, 20 May 2012 00:03:22 -0700 (PDT) Received: by werb13 with SMTP id b13so1553220wer.31 for ; Sun, 20 May 2012 00:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ulTXowYoQakihXybXvKU6m00oCipCcG+OVfF719Pcro=; b=O1y63NSV8oOI0z0gCIG6meFzmzG3phaKMvSqJOevdMabKSKddleDBN4ouD2kp5iZKn I6NX9kurCsbgY5BhTKqeMRONdP313ecv83gy70Uw50vXqs5sUP12KtaKDm7KfNyE9fvr 2bFpSMq98tzJ4743NfiXIJf0xLLtTd9zUZbIC3JbJcn0+pp36CwXdeuAwLuCsIZpXHd1 KmVl7liE7hJWzM+s/ngOxob4zJ1+YkmJKX1w8t8RkQmm727/EKunt0UkVDKeryAvEoZ7 D1ie+e4OCwSEhWEkumuvsPhuVVxTxF72CoMSCX2tddWdChRXmb6xCbGIinrM++zm3rmZ 33Jw== Received: by 10.180.102.36 with SMTP id fl4mr7518986wib.2.1337497402030; Sun, 20 May 2012 00:03:22 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-62.as13285.net. [2.102.217.62]) by mx.google.com with ESMTPS id fm1sm15466378wib.10.2012.05.20.00.03.20 (version=SSLv3 cipher=OTHER); Sun, 20 May 2012 00:03:21 -0700 (PDT) Message-ID: <4FB89733.2080106@gmail.com> Date: Sun, 20 May 2012 08:03:15 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 May 2012 07:03:23 -0000 On 2012-05-19 22:26, Randy Bush wrote: >> If you want to send packets of arbitrary size, in any environment >> where PMTUD is impossible or fails, won't you need to always include >> a fragmentation header in every packet greater than 1280? > > see discussion of jumbo frames, commonly 4k or 9k, between consenting > adults on known links Yes indeed, but that isn't the general case. Across the open Internet, I think we have the situation I described. On 2012-05-19 21:16, Gert Doering wrote: >>> UDP packets larger than 1280 bytes >> > Don't do that! > > Tell that to the DNS people. They seem to really like not-using-TCP. Yes, but I understand that DNSSEC more or less dooms that plan anyway. However, I thinks it's true that the only fail-safe solution is to include a frag header if you need to send UDP >1280. Brian Brian From jinmei@isc.org Sun May 20 00:53:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF8C21F857A for ; Sun, 20 May 2012 00:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.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 bbBhXn0yhnGs for ; Sun, 20 May 2012 00:53:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 355DD21F8554 for ; Sun, 20 May 2012 00:53:25 -0700 (PDT) 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 id 5409BC980F; Sun, 20 May 2012 07:53:14 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (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 EAACB216C33; Sun, 20 May 2012 07:53:13 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Sun, 20 May 2012 00:53:12 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian E Carpenter In-Reply-To: <4FB89733.2080106@gmail.com> References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 May 2012 07:53:25 -0000 At Sun, 20 May 2012 08:03:15 +0100, Brian E Carpenter wrote: > >>> UDP packets larger than 1280 bytes > >> > Don't do that! > > > > Tell that to the DNS people. They seem to really like not-using-TCP. > > Yes, but I understand that DNSSEC more or less dooms that plan anyway. I may misunderstand the context, but modern and sensible DNS server implementations generally enable the IPV6_USE_MIN_MTU socket option. > However, I thinks it's true that the only fail-safe solution is to > include a frag header if you need to send UDP >1280. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From brian.e.carpenter@gmail.com Sun May 20 01:37:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F56A21F848A for ; Sun, 20 May 2012 01:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.541 X-Spam-Level: X-Spam-Status: No, score=-101.541 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX9mh2jcVK18 for ; Sun, 20 May 2012 01:37:03 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED1B21F856C for ; Sun, 20 May 2012 01:37:03 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so1143891wib.13 for ; Sun, 20 May 2012 01:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RvtkYC90aHC5FOJImcMM7Sj7GcW0Dwhs93ZAVTjGaco=; b=KEM6uXR5mJrgnlmgeznQoZzqH12Tx2r+fU2XPSJ//5VlkNNbohikVqzm1O5evvG6fj LOpzV3/7fdXHRC/pt22D/7A3dwBIH3+Tz31zuraiGwcC3WIEftnD9rdOxnjQjEJNvGKq dK+kP7pmu//4BLXDOdzfiNfmd5Itcx1bWy1/L/zK6cIVDbJ75oo9ggMrDahCTVqzJo0N xBI6c4eSuQktfZTK2VPDDv4I6D8NWb20nRMsjaDUimhTmKkTLL6WFsRPOrwkn0wYf+IA 9z8JUO+It2Iw7nVflVf6ZKne4YCHAqVhnMHEd9De2SqvjQPlkaIWdrg+zge8FRsU/ueN kYRg== Received: by 10.216.143.148 with SMTP id l20mr11178115wej.115.1337503022616; Sun, 20 May 2012 01:37:02 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-62.as13285.net. [2.102.217.62]) by mx.google.com with ESMTPS id o9sm25004108wia.3.2012.05.20.01.37.00 (version=SSLv3 cipher=OTHER); Sun, 20 May 2012 01:37:01 -0700 (PDT) Message-ID: <4FB8AD29.9030706@gmail.com> Date: Sun, 20 May 2012 09:36:57 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 May 2012 08:37:04 -0000 On 2012-05-20 08:53, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= wrote: > At Sun, 20 May 2012 08:03:15 +0100, > Brian E Carpenter wrote: >=20 >>>>> UDP packets larger than 1280 bytes >>>>> Don't do that! >>> Tell that to the DNS people. They seem to really like not-using-TCP.= >> Yes, but I understand that DNSSEC more or less dooms that plan anyway.= >=20 > I may misunderstand the context, but modern and sensible DNS server > implementations generally enable the IPV6_USE_MIN_MTU socket option. OK... >> However, I thinks it's true that the only fail-safe solution is to >> include a frag header if you need to send UDP >1280. As I understand it, that is triggered automatically by IPV6_USE_MIN_MTU. So any UDP application that *doesn't* set IPV6_USE_MIN_MTU =3D 1 is at risk of failure to some destinations, unless it performs its own transport-layer PMTUD somehow. However, we are well off the MSS topic so I will shut up now. Brian From cb.list6@gmail.com Sun May 20 05:50:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49E321F84B2 for ; Sun, 20 May 2012 05:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO11r7a-rNwN for ; Sun, 20 May 2012 05:50:05 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D936F21F8473 for ; Sun, 20 May 2012 05:50:04 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5891945pbc.31 for ; Sun, 20 May 2012 05:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cKQY6tU24I76yedLfhz7kLpKVo8mjAgQyWiudjtyeOg=; b=qNZzryaus2W4uAKunCTH5dGNnVb76BfzeEVKDQdoP2/L6oMgdqFUVSgjVfZp/3+Lwa axZkV3hzJUPrwjRDnVCwgPbFCJQFn/q0wJ/k23kUABbFD1CnmatEVPziYIq62wAN619I fARHUl5JRjgrW7WhGa9QBOTGOhCnL2jVQXrRljulinsoOccMy1443pJvqqo5wguKZp1E en5vSyywYgFqtz4roUPM6XJ0aIp5bx4/V8qr0qdHlZtCldRjeJc1xrgPsRkgcskwOIQF w5dStysM8XJSmdzBrTVE5WvpyG9f+Z4SXIO+0PMx4mxDTVDU25B6axWZtMHUiI5TToM/ ZDPg== MIME-Version: 1.0 Received: by 10.68.223.167 with SMTP id qv7mr57585492pbc.127.1337518204446; Sun, 20 May 2012 05:50:04 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Sun, 20 May 2012 05:50:04 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Sun, 20 May 2012 05:50:04 -0700 (PDT) In-Reply-To: <4FB86EF8.9030101@bogus.com> References: <4FB86EF8.9030101@bogus.com> Date: Sun, 20 May 2012 05:50:04 -0700 Message-ID: From: Cameron Byrne To: Joel jaeggli Content-Type: multipart/alternative; boundary=047d7b162db774e5e604c0773943 Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 - http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-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: Sun, 20 May 2012 12:50:05 -0000 --047d7b162db774e5e604c0773943 Content-Type: text/plain; charset=ISO-8859-1 On May 19, 2012 9:11 PM, "Joel jaeggli" wrote: > > In response to comments recieved during the 6204bis draft wglc and > subsequent discsussion among the authors, draft 09 was produced. > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 > > diffs between the two are here: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6204bis-09.txt > > please review by tue 5/22, this is the version that I plan on generating > the document shepherds review from. It strikes me as unlikley that the > current discussion on mtu/mss adjustment is going to produce a > sustainable consensus and we should therefore consider where or whether > or where to expose that problem in a document. > I still strongly believe the mtu issue needs to be acknowledged here. It does not need to be solved here. CB > Minor niggles can be corrected in auth-48, larger problems should not. > > thanks > joel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7b162db774e5e604c0773943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 19, 2012 9:11 PM, "Joel jaeggli" <joelja@bogus.com> wrote:
>
> In response to comments recieved during the 6204bis =A0draft wglc and<= br> > subsequent discsussion among the authors, draft 09 was produced.
>
> htt= p://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09
>
> diffs between the two are here:
>
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6204bis-09= .txt
>
> please review by tue 5/22, this is the version that I plan on generati= ng
> the document shepherds review from. It strikes me as unlikley that the=
> current discussion on mtu/mss adjustment is going to produce a
> sustainable consensus and we should therefore consider where or whethe= r
> or where to expose that problem in a document.
>

I still strongly believe the mtu issue needs to be acknowledged here. It= does not need to be solved here.

CB

> Minor niggles can be corrected in auth-48, larger problems should n= ot.
>
> thanks
> joel
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--047d7b162db774e5e604c0773943-- From randy@psg.com Sun May 20 06:05:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E1E21F8493 for ; Sun, 20 May 2012 06:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lGQzyOCXzcX for ; Sun, 20 May 2012 06:05:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1997821F846A for ; Sun, 20 May 2012 06:05:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SW5or-0002Xs-TD; Sun, 20 May 2012 13:05:10 +0000 Date: Sun, 20 May 2012 22:05:08 +0900 Message-ID: From: Randy Bush To: Cameron Byrne In-Reply-To: References: <4FB86EF8.9030101@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 - http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-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: Sun, 20 May 2012 13:05:12 -0000 > I still strongly believe the mtu issue needs to be acknowledged > here. It does not need to be solved here. this draft sans at least a warning would be grievously bad engineering. randy From marka@isc.org Sun May 20 07:04:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0963E21F84CD for ; Sun, 20 May 2012 07:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxBB1Fne1gAO for ; Sun, 20 May 2012 07:04:58 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 30A5221F8496 for ; Sun, 20 May 2012 07:04:58 -0700 (PDT) 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 AAE505F9899; Sun, 20 May 2012 14:04:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:79e9:7881:f98f:57e7]) (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 ADD99216C33; Sun, 20 May 2012 14:04:38 +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 9E5A520C611B; Mon, 21 May 2012 00:04:21 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> In-reply-to: Your message of "Sun, 20 May 2012 08:03:15 +0100." <4FB89733.2080106@gmail.com> Date: Mon, 21 May 2012 00:04:20 +1000 Message-Id: <20120520140421.9E5A520C611B@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 May 2012 14:04:59 -0000 In message <4FB89733.2080106@gmail.com>, Brian E Carpenter writes: > On 2012-05-19 22:26, Randy Bush wrote: > >> If you want to send packets of arbitrary size, in any environment > >> where PMTUD is impossible or fails, won't you need to always include > >> a fragmentation header in every packet greater than 1280? > > > > see discussion of jumbo frames, commonly 4k or 9k, between consenting > > adults on known links > > Yes indeed, but that isn't the general case. Across the open Internet, > I think we have the situation I described. > > On 2012-05-19 21:16, Gert Doering wrote: > > >>> UDP packets larger than 1280 bytes > >> > Don't do that! > > > > Tell that to the DNS people. They seem to really like not-using-TCP. > > Yes, but I understand that DNSSEC more or less dooms that plan anyway. > > However, I thinks it's true that the only fail-safe solution is to > include a frag header if you need to send UDP >1280. > > Brian For DNS we just fragment at 1280 using IPV6_USE_MIN_MTU. We were thinking about this back in 1998 (draft-ietf-ipngwg-bsd-frag-00.txt) which was rolled into the advanced socket api. It took a few more years than I would have liked to become RFC and for implementations to be available. EDNS was already being developed back then and it was obvious that PMTUD wouldn't work for large nameservers even if they got the ICMPv6 PTBs. For DNS there is little to be gained by trying to send any bigger packets. YMMV for other UDP based protocols. Mark > Brian > _______________________________________________ > 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 ichiroumakino@gmail.com Mon May 21 00:50:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D89721F8546 for ; Mon, 21 May 2012 00:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGucD+b-NvFE for ; Mon, 21 May 2012 00:50:11 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18FE421F854A for ; Mon, 21 May 2012 00:50:08 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1323603eaa.31 for ; Mon, 21 May 2012 00:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=lDyXJeoqDzMSM770n79RtZV5VgcQZm/aOrdbxImkn+E=; b=dvdZbFAjtyQ0fTu4jAoM7smZ4CwxZxa0sDrNY3Lk23J5UjDIYn+Xsmgl+ti0t0v2L9 VvjzvkgMB/udRD09SZxIZbQVfMag6Ku1ds68La5KNETjXsTsj9hZMYTn/GJdjQvbg0UC +DIbbY2wkmi8m9E/YohPc+o+GCfYNbjMPjP8VK/5HF89caUS2662dLApbgCD6zQ30nmT rj8QrLhsWJ13aAsBZgQOjCZaWCqzlkvqaVz9ouAcZbcunEhNnGs7OA2QyYaYdaxMmXVC jorj0H51EmXqCk6jkpRQYtJKGhxK67jsr2xv2SwydTZO6evuFeJpG2Bp0nq5vTO5KRYb 4j2A== Received: by 10.14.96.72 with SMTP id q48mr3515232eef.122.1337586608187; Mon, 21 May 2012 00:50:08 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id s47sm64787346eef.4.2012.05.21.00.49.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 00:50:07 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4FB86EF8.9030101@bogus.com> Date: Mon, 21 May 2012 09:49:54 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4FB86EF8.9030101@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1278) Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 - http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-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: Mon, 21 May 2012 07:50:11 -0000 Joel, > In response to comments recieved during the 6204bis draft wglc and > subsequent discsussion among the authors, draft 09 was produced. > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 > > diffs between the two are here: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6204bis-09.txt > > please review by tue 5/22, this is the version that I plan on generating > the document shepherds review from. It strikes me as unlikley that the > current discussion on mtu/mss adjustment is going to produce a > sustainable consensus and we should therefore consider where or whether > or where to expose that problem in a document. I-D.ietf-dhc-dhcpv6-stateful-issues should be a normative reference. cheers, Ole From despres.remi@laposte.net Mon May 21 02:05:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD20E21F85A8 for ; Mon, 21 May 2012 02:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c87SRUTKL-7z for ; Mon, 21 May 2012 02:05:39 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0F54A21F8599 for ; Mon, 21 May 2012 02:05:38 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id E42E870000E2; Mon, 21 May 2012 11:05:33 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 78FD87000065; Mon, 21 May 2012 11:05:33 +0200 (CEST) X-SFR-UUID: 20120521090533495.78FD87000065@msfrf2301.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FB86EF8.9030101@bogus.com> Date: Mon, 21 May 2012 11:05:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5875BB9A-F46D-45FA-97E3-08610C83952B@laposte.net> References: <4FB86EF8.9030101@bogus.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] 6204bis draft 09 - Work item on fragmentation issues? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 May 2012 09:05:40 -0000 Hi Joel, 2012-05-20 06:11, Joel Jaeggli : ... > It strikes me as unlikley that the > current discussion on mtu/mss adjustment is going to produce a > sustainable consensus and we should therefore consider where or = whether > or where to expose that problem in a document. The fact that there is no consensus on how to deal with an identified = operational problem justifies IETF to tackle the subject. Suggestion: v6ops asks for a work item to be created on fragmentation = issues, e.g. in Intarea. Subject could include considerations on: - IPv6 AND IPv4 - ICMP PTB and firewalls - RA advertised MTUs - Transmit MTUs and DF settings in hosts . in TCP AND UDP=20 . for on-link AND off-link destinations - MSS rewrites Any alternative way to make progress would be welcome, provided = documenting an IETF view on these issues isn't further deferred. Regards, RD From shemant@cisco.com Mon May 21 07:05:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300F421F859B; Mon, 21 May 2012 07:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ISYJGPtCTTH; Mon, 21 May 2012 07:05:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7393A21F8597; Mon, 21 May 2012 07:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=624; q=dns/txt; s=iport; t=1337609123; x=1338818723; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=o6t5/gpuvixE6wcXZ/qPIZ2hDn44gjJ8N38as7dfpdY=; b=K2qFbhF3+PQVqRyAU3oYmud8CJck25m/E8qW8rHBTWGIDMlhxwfPvzT+ ENmLUDdIKTAuosB5mKsnT7m39Zn7mFC6yrF2khdb1mnFFBFW4YIeYQwu8 YYTycbGXIyAwdy5MnJsOT+VmMToZOusGTQY9YPTlI38jUuD/gVD4+eu3y 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD5Luk+tJXG//2dsb2JhbABEtAKBB4IVAQEBBBIBHUkMBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2wLny+faYsFhGtiA4gPM41ojH2BZIMH X-IronPort-AV: E=Sophos;i="4.75,631,1330905600"; d="scan'208";a="85156200" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 21 May 2012 14:05:23 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4LE5MDm028940; Mon, 21 May 2012 14:05:22 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 09:05:22 -0500 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-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 May 2012 09:05:21 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304B6379D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis draft 09 -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Thread-Index: Ac03JnQC/fsm1WOcQp+rHjo1zoByRwANAgmA References: <4FB86EF8.9030101@bogus.com> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Joel jaeggli" X-OriginalArrivalTime: 21 May 2012 14:05:22.0930 (UTC) FILETIME=[C3732520:01CD375A] Cc: dhcwg , IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-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: Mon, 21 May 2012 14:05:24 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Monday, May 21, 2012 3:50 AM To: Joel jaeggli Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 = -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 >I-D.ietf-dhc-dhcpv6-stateful-issues should be a normative reference. When do we think the above document can be sent to the IESG by the DHC = WG? Rfc6204bis is sensitive to any delays for publication if a = normative reference does not become an RFC around the time of = publication for rfc6204bis. Thanks, Hemant From volz@cisco.com Mon May 21 07:45:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE3921F84DF; Mon, 21 May 2012 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3PonQG4KDKC; Mon, 21 May 2012 07:45:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D569421F84D8; Mon, 21 May 2012 07:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1348; q=dns/txt; s=iport; t=1337611513; x=1338821113; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=a/SxUCNSqox7GiUvQaLlMc9qVWpwEMjyDwoXhWv+50s=; b=Q+hzcXDqr/CYLv4RS43l73qYr4xLtEIYPap+/x0BVE4Rw+5rCStf2x64 L/7hcEaEceaWOguNLhlDBL18uVaot3EEby5H5r88uODc8jaCNKEC3xfPx Y74K+t6KFnqm4TWiVOEWoeLUASSzSlpNiqiVNAaWsiFoWJQbc6zmBQbaS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKBTuk+tJXG+/2dsb2JhbABEtAKBB4IVAQEBBAEBAQ8BHT4LDAQCAQgRBAEBCwYXAQYBJh8JCAEBBBMIGodsC58hn2eLBYIvgjxiA4gPM41ojH2BZIMH X-IronPort-AV: E=Sophos;i="4.75,631,1330905600"; d="scan'208";a="85108428" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 21 May 2012 14:45:11 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4LEjBRv017819; Mon, 21 May 2012 14:45:11 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 09:45:10 -0500 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-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 May 2012 09:44:59 -0500 Message-ID: In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304B6379D@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis draft 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Thread-Index: Ac03JnQC/fsm1WOcQp+rHjo1zoByRwANAgmAAAFlqqA= References: <4FB86EF8.9030101@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304B6379D@XMB-RCD-109.cisco.com> From: "Bernie Volz (volz)" To: X-OriginalArrivalTime: 21 May 2012 14:45:10.0746 (UTC) FILETIME=[52B2F3A0:01CD3760] Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-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: Mon, 21 May 2012 14:45:13 -0000 Can we request that the DHC WG chairs to start a DHC WG last-call on the = document? There has been no real discussion of it so far on the mailing = list; perhaps this is one way to trigger that discussion? It would be = nice to move this document along!! - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Monday, May 21, 2012 10:05 AM To: Ole Tr=F8an; Joel jaeggli Cc: dhcwg; IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft = 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Monday, May 21, 2012 3:50 AM To: Joel jaeggli Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 = -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 >I-D.ietf-dhc-dhcpv6-stateful-issues should be a normative reference. When do we think the above document can be sent to the IESG by the DHC = WG? Rfc6204bis is sensitive to any delays for publication if a = normative reference does not become an RFC around the time of = publication for rfc6204bis. Thanks, Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From warren@kumari.net Mon May 21 07:49:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2C921F84FA for ; Mon, 21 May 2012 07:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ1hvnTNKIr4 for ; Mon, 21 May 2012 07:49:05 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 197ED21F84D8 for ; Mon, 21 May 2012 07:49:05 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 625D11B402F8; Mon, 21 May 2012 10:49:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <20120520140421.9E5A520C611B@drugs.dv.isc.org> Date: Mon, 21 May 2012 10:49:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96B542C8-F19D-470D-B648-154946D791A6@kumari.net> References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> <20120520140421.9E5A520C611B@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1278) Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 May 2012 14:49:05 -0000 [ Top posting / meta questions ] So, both my memory and my google-foo are failing me=85 Can anyone remember *why* the v6 in MTU is 1280 (and please don't say = "Because the RFC says so!"=85) I have some niggling voice in the back of my head making 3GPP noises, = but=85 W On May 20, 2012, at 10:04 AM, Mark Andrews wrote: >=20 > In message <4FB89733.2080106@gmail.com>, Brian E Carpenter writes: >> On 2012-05-19 22:26, Randy Bush wrote: >>>> If you want to send packets of arbitrary size, in any environment >>>> where PMTUD is impossible or fails, won't you need to always = include >>>> a fragmentation header in every packet greater than 1280? >>>=20 >>> see discussion of jumbo frames, commonly 4k or 9k, between = consenting >>> adults on known links >>=20 >> Yes indeed, but that isn't the general case. Across the open = Internet, >> I think we have the situation I described. >>=20 >> On 2012-05-19 21:16, Gert Doering wrote: >>=20 >>>>> UDP packets larger than 1280 bytes >>>>> Don't do that! >>>=20 >>> Tell that to the DNS people. They seem to really like = not-using-TCP. >>=20 >> Yes, but I understand that DNSSEC more or less dooms that plan = anyway. >>=20 >> However, I thinks it's true that the only fail-safe solution is to >> include a frag header if you need to send UDP >1280. >>=20 >> Brian >=20 > For DNS we just fragment at 1280 using IPV6_USE_MIN_MTU. We were > thinking about this back in 1998 (draft-ietf-ipngwg-bsd-frag-00.txt) > which was rolled into the advanced socket api. It took a few more > years than I would have liked to become RFC and for implementations > to be available. EDNS was already being developed back then and > it was obvious that PMTUD wouldn't work for large nameservers even > if they got the ICMPv6 PTBs. >=20 > For DNS there is little to be gained by trying to send any bigger > packets. >=20 > YMMV for other UDP based protocols. >=20 > Mark >=20 >> Brian >> _______________________________________________ >> 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 >=20 --=20 With Feudalism, it's your Count that votes. From jason.weil@twcable.com Mon May 21 08:56:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A8C21F859A for ; Mon, 21 May 2012 08:56:22 -0700 (PDT) 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, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHRc6r+ERBkR for ; Mon, 21 May 2012 08:56:22 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id E705321F8593 for ; Mon, 21 May 2012 08:56:21 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,631,1330923600"; d="scan'208";a="367131484" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 May 2012 11:55:49 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 21 May 2012 11:56:21 -0400 From: "Weil, Jason" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Timothy Winters Date: Mon, 21 May 2012 11:54:34 -0400 Thread-Topic: [v6ops] Route Information Option Lifetime Thread-Index: Ac03akOwbmYCOmD8THmT+Q+d25o5Ew== 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.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Route Information Option Lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 May 2012 15:56:22 -0000 Ole/Tim, I'd like to second the recommendation for invalidated vs deprecated in requirement L-14 for the generation of an ICMP error messages. I believe the original request for this requirement came from an application developer. The fact that nobody seems to be arguing for the former wording seems to imply that the new recommended wording is justified. Thanks, Jason On 5/18/12 3:40 AM, "Ole Tr=F8an" wrote: >Tim, > >> Thanks for taking the time, so If I'm understanding you correctly a= CE >>Router is expected to generate a ICMPv6 Unreachable message for all >>invalidated or unknown prefixes on the LAN interface? This makes sense >>to me, I'm just making sure we don't expect a CE Router to know the >>difference between recently invalidated and unknown. > >yes, agree we should make no such expectation. > >cheers, >Ole >_______________________________________________ >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 shemant@cisco.com Mon May 21 12:53:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C921F859F; Mon, 21 May 2012 12:53:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTn--Evnb-dy; Mon, 21 May 2012 12:53:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7B19621F848E; Mon, 21 May 2012 12:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1658; q=dns/txt; s=iport; t=1337630005; x=1338839605; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=er4TO0/8UxKOaGInDQk1UvEGPenA/2J2Bo5KYqcPrFs=; b=fFXg3H2jAyxEy9tX2Rtniu529OUV6uoiiCwTU6yIuc17lMIJYJ4UNrXH owPGIf5HPgE1NyGNSE2TdT36jFGdBF88rKDBU8dyrZKjlFqC9hbDmmK+V f3O7CJdbCnpUIEAX5p6AB4a+ejczOqADYZRff2kf0I7h6Gav3Sf0fe/ne U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIicuk+tJV2a/2dsb2JhbABEtBqBB4IVAQEBBAEBAQ8BHT4LDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHbAufEp9+iwWEWmIDiA8zjWiMfYFkgwc X-IronPort-AV: E=Sophos;i="4.75,632,1330905600"; d="scan'208";a="85201277" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 21 May 2012 19:53:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4LJrPQ5031580; Mon, 21 May 2012 19:53:25 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 14:53:24 -0500 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-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 May 2012 14:53:23 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304B6392D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis draft 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Thread-Index: Ac03JnQC/fsm1WOcQp+rHjo1zoByRwANAgmAAAFlqqAACtJPMA== References: <4FB86EF8.9030101@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304B6379D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Bernie Volz (volz)" , X-OriginalArrivalTime: 21 May 2012 19:53:24.0969 (UTC) FILETIME=[621D6D90:01CD378B] Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-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: Mon, 21 May 2012 19:53:26 -0000 Thanks, Bernie! Hemant -----Original Message----- From: Bernie Volz (volz)=20 Sent: Monday, May 21, 2012 10:45 AM To: dhcwg@ietf.org Cc: IPv6 Ops WG; Hemant Singh (shemant); Ole Tr=F8an; Joel jaeggli Subject: RE: [v6ops] 6204bis draft = 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Can we request that the DHC WG chairs to start a DHC WG last-call on the = document? There has been no real discussion of it so far on the mailing = list; perhaps this is one way to trigger that discussion? It would be = nice to move this document along!! - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Monday, May 21, 2012 10:05 AM To: Ole Tr=F8an; Joel jaeggli Cc: dhcwg; IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft = 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Monday, May 21, 2012 3:50 AM To: Joel jaeggli Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 = -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 >I-D.ietf-dhc-dhcpv6-stateful-issues should be a normative reference. When do we think the above document can be sent to the IESG by the DHC = WG? Rfc6204bis is sensitive to any delays for publication if a = normative reference does not become an RFC around the time of = publication for rfc6204bis. Thanks, Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Mon May 21 13:31:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5FC21F859E for ; Mon, 21 May 2012 13:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSwZW5ogP+L4 for ; Mon, 21 May 2012 13:31:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 24D5C21F859A for ; Mon, 21 May 2012 13:31:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWZGH-00069f-7U; Mon, 21 May 2012 20:31:25 +0000 Date: Tue, 22 May 2012 05:31:24 +0900 Message-ID: From: Randy Bush To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5875BB9A-F46D-45FA-97E3-08610C83952B@laposte.net> References: <4FB86EF8.9030101@bogus.com> <5875BB9A-F46D-45FA-97E3-08610C83952B@laposte.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 - Work item on fragmentation issues? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 May 2012 20:31:27 -0000 >> It strikes me as unlikley that the current discussion on mtu/mss >> adjustment is going to produce a sustainable consensus and we should >> therefore consider where or whether or where to expose that problem >> in a document. > The fact that there is no consensus on how to deal with an identified > operational problem justifies IETF to tackle the subject. if there is no consensus on how to deal with it does not mean that we should not warn that there is a very large operational speed bump. it would be irresponsible not to do so. randy From mark@townsley.net Mon May 21 14:19:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6617721F858F for ; Mon, 21 May 2012 14:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYxIewC++c4z for ; Mon, 21 May 2012 14:19:31 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADCAE21F8569 for ; Mon, 21 May 2012 14:19:30 -0700 (PDT) Received: by eekd4 with SMTP id d4so1612258eek.31 for ; Mon, 21 May 2012 14:19:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LghE3g6x5dRoieHojt4FzRSSVYKzHmtmk7NkgRWSmMw=; b=JeVKLOPEwLdDsSL61YxbHUcgLQ6uKCz+vgE/J4CveDpnKSZAXFE/KlRfIqatxIOB04 DwtZiztsdsLg8JyDU37NsU6aNShjAMlENmbb2AcVmI1CmWimg4srcFN1j+ksDCROZIoK 6BclO3crbOKOar23D2VWiyw3HYgeEluQ+fFSAnnEU0+MD5UYuWbpx9tZllMS6J/V2UI7 8rGxGRCTha+ep7N1hHEMs5QmwNLQVZ6Wudlg+a95TjpuncGP5YrZ+/KEvC1Pi3aRErv/ RIaFx8HNXTJYOOH3JO2dyX666Ym9zTCKXP88/j9R/Hz2jXxPYyttdD7aQdJPGf1wBazw jtlw== Received: by 10.14.100.144 with SMTP id z16mr1609538eef.50.1337635169761; Mon, 21 May 2012 14:19:29 -0700 (PDT) Received: from ams-townsley-8916.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id u7sm88332485eeb.7.2012.05.21.14.19.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 14:19:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <201205191245.q4JCj1B08991@ftpeng-update.cisco.com> Date: Mon, 21 May 2012 23:19:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205191245.q4JCj1B08991@ftpeng-update.cisco.com> To: X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnFPsZXlejAP0lo8istYbQTrmYT/VZJ0yDhLALZ7YGw3v0jKGDcGitEvHsAVYZsiP/bjFkF Cc: v6ops@ietf.org, draft-foo-v6ops-6rdmtu@tools.ietf.org Subject: Re: [v6ops] new draft: draft-foo-v6ops-6rdmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 May 2012 21:19:31 -0000 Dr. Foo, ;-)=20 Encapsulation in 6rd comes from RFC 4213, including the basis for = recommendations on MTU handling (Section 3.2 of RFC 4213 addresses this = specifically, with pseudocode that would need to be rationalized with = yours proposed in this draft if it were accepted). If there is a problem = to be solved, let's solve in generically.=20 Thanks, - Mark On May 19, 2012, at 2:45 PM, wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/html/draft-foo-v6ops-6rdmtu. Please take a look at = it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Mon May 21 16:00:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517F721F84AF for ; Mon, 21 May 2012 16:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o86w37CGdpGS for ; Mon, 21 May 2012 16:00:02 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id D9F5721F84A7 for ; Mon, 21 May 2012 16:00:02 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4LN02L5031785 for ; Mon, 21 May 2012 16:00:02 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4LN0050031683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 May 2012 16:00:00 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4LN00hc016077; Mon, 21 May 2012 16:00:00 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4LMxvUu016031 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 21 May 2012 15:59:58 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 21 May 2012 15:59:27 -0700 From: "Templin, Fred L" To: Mark Townsley , "" Date: Mon, 21 May 2012 15:59:25 -0700 Thread-Topic: [v6ops] new draft: draft-foo-v6ops-6rdmtu Thread-Index: Ac03l2/MfJHPiHz1RyWdvSxexQ2CMAADc8Bg Message-ID: References: <201205191245.q4JCj1B08991@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-foo-v6ops-6rdmtu@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-foo-v6ops-6rdmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 May 2012 23:00:03 -0000 Good point, Mark - I have a new "generic" draft ready to go and will be posting it this evening. Thanks - Fred > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Mark Townsley > Sent: Monday, May 21, 2012 2:19 PM > To: > Cc: v6ops@ietf.org; draft-foo-v6ops-6rdmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-foo-v6ops-6rdmtu >=20 >=20 > Dr. Foo, ;-) >=20 > Encapsulation in 6rd comes from RFC 4213, including the basis for > recommendations on MTU handling (Section 3.2 of RFC 4213 addresses this > specifically, with pseudocode that would need to be rationalized with > yours proposed in this draft if it were accepted). If there is a problem > to be solved, let's solve in generically. >=20 > Thanks, >=20 > - Mark >=20 > On May 19, 2012, at 2:45 PM, wrote: >=20 > > > > A new draft has been posted, at http://tools.ietf.org/html/draft-foo- > v6ops-6rdmtu. Please take a look at it and comment. > > _______________________________________________ > > 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 internet-drafts@ietf.org Tue May 22 03:25:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0221F84B6; Tue, 22 May 2012 03:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYTEBd5YFD5I; Tue, 22 May 2012 03:25:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2A121F8452; Tue, 22 May 2012 03:25:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120522102505.14922.99336.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 03:25:05 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-discard-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: Tue, 22 May 2012 10:25:06 -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 : A Discard Prefix for IPv6 Author(s) : Nick Hilliard David Freedman Filename : draft-ietf-v6ops-ipv6-discard-prefix-04.txt Pages : 6 Date : 2012-05-22 Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates RFC5156 by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-04= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-04.= txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-discard-prefix/ From internet-drafts@ietf.org Tue May 22 05:45:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910B521F85D4; Tue, 22 May 2012 05:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.602 X-Spam-Level: X-Spam-Status: No, score=-101.602 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTOmOl6F6U0k; Tue, 22 May 2012 05:45:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D48821F85A5; Tue, 22 May 2012 05:45:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120522124516.26184.50429.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 05:45:16 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 12:45: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 : Implementation Advice for IPv6 Router Advertisement Guar= d (RA-Guard) Author(s) : Fernando Gont Filename : draft-ietf-v6ops-ra-guard-implementation-04.txt Pages : 19 Date : 2012-05-22 The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementatio= n-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation= -04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ From simon.perreault@viagenie.ca Tue May 22 07:26:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5725121F8594 for ; Tue, 22 May 2012 07:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2J-rg96galJ for ; Tue, 22 May 2012 07:26:23 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C037421F85FD for ; Tue, 22 May 2012 07:26:23 -0700 (PDT) Received: from [192.168.0.100] (modemcable010.192-131-66.mc.videotron.ca [66.131.192.10]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0DFF0400BD for ; Tue, 22 May 2012 10:26:23 -0400 (EDT) Message-ID: <4FBBA20E.8030905@viagenie.ca> Date: Tue, 22 May 2012 10:26:22 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> <20120520140421.9E5A520C611B@drugs.dv.isc.org> <96B542C8-F19D-470D-B648-154946D791A6@kumari.net> In-Reply-To: <96B542C8-F19D-470D-B648-154946D791A6@kumari.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 May 2012 14:26:24 -0000 On 2012-05-21 10:49, Warren Kumari wrote: > Can anyone remember *why* the v6 in MTU is 1280 (and please don't say "Because the RFC says so!"…) See this thread: http://www.ietf.org/mail-archive/web/v6ops/current/msg11892.html Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From despres.remi@laposte.net Tue May 22 08:43:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05FC21F85F6 for ; Tue, 22 May 2012 08:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnP9laBcdYiA for ; Tue, 22 May 2012 08:43:06 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3E86321F85EF for ; Tue, 22 May 2012 08:42:58 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id 188017000181; Tue, 22 May 2012 17:42:57 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id 2B0507000110; Tue, 22 May 2012 17:42:56 +0200 (CEST) X-SFR-UUID: 20120522154256176.2B0507000110@msfrf2302.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <96B542C8-F19D-470D-B648-154946D791A6@kumari.net> Date: Tue, 22 May 2012 17:42:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F4D41D8-78ED-4EBB-883C-9B4462EBE14A@laposte.net> References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> <20120520140421.9E5A520C611B@drugs.dv.isc.org> <96B542C8-F19D-470D-B648-154946D791A6@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 May 2012 15:43:08 -0000 Hi Warren, Le 2012-05-21 =E0 16:49, Warren Kumari a =E9crit : > [ Top posting / meta questions ] >=20 > So, both my memory and my google-foo are failing me=85 >=20 > Can anyone remember *why* the v6 in MTU is 1280 (and please don't say = "Because the RFC says so!"=85) In the excellent French book in which I learned IPv6 in 2003 = (livre.g6.asso.fr/index.php/Format_du_paquet_IPv6), here is what I = learned: "Choice of 1280 as minimum MTU is to permit IPv6 tunneling. 1500 octets = is the generally admitted link MTU, that imposed by Ethernet."=20 As this permits multiple tunneling layers without fragmentation on the = most typical links, and limits to a moderate ratio waste of bandwidth on = 1500-octet remote links, this is IMHO a valuable choice. RD > I have some niggling voice in the back of my head making 3GPP noises, = but=85 >=20 > W >=20 > On May 20, 2012, at 10:04 AM, Mark Andrews wrote: >=20 >>=20 >> In message <4FB89733.2080106@gmail.com>, Brian E Carpenter writes: >>> On 2012-05-19 22:26, Randy Bush wrote: >>>>> If you want to send packets of arbitrary size, in any environment >>>>> where PMTUD is impossible or fails, won't you need to always = include >>>>> a fragmentation header in every packet greater than 1280? >>>>=20 >>>> see discussion of jumbo frames, commonly 4k or 9k, between = consenting >>>> adults on known links >>>=20 >>> Yes indeed, but that isn't the general case. Across the open = Internet, >>> I think we have the situation I described. >>>=20 >>> On 2012-05-19 21:16, Gert Doering wrote: >>>=20 >>>>>> UDP packets larger than 1280 bytes >>>>>> Don't do that! >>>>=20 >>>> Tell that to the DNS people. They seem to really like = not-using-TCP. >>>=20 >>> Yes, but I understand that DNSSEC more or less dooms that plan = anyway. >>>=20 >>> However, I thinks it's true that the only fail-safe solution is to >>> include a frag header if you need to send UDP >1280. >>>=20 >>> Brian >>=20 >> For DNS we just fragment at 1280 using IPV6_USE_MIN_MTU. We were >> thinking about this back in 1998 (draft-ietf-ipngwg-bsd-frag-00.txt) >> which was rolled into the advanced socket api. It took a few more >> years than I would have liked to become RFC and for implementations >> to be available. EDNS was already being developed back then and >> it was obvious that PMTUD wouldn't work for large nameservers even >> if they got the ICMPv6 PTBs. >>=20 >> For DNS there is little to be gained by trying to send any bigger >> packets. >>=20 >> YMMV for other UDP based protocols. >>=20 >> Mark >>=20 >>> Brian >>> _______________________________________________ >>> 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 >>=20 >=20 > --=20 > With Feudalism, it's your Count that votes. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From warren@kumari.net Tue May 22 10:16:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC7D21F85E6 for ; Tue, 22 May 2012 10:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.049 X-Spam-Level: X-Spam-Status: No, score=-106.049 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxZJXBd1Mrak for ; Tue, 22 May 2012 10:16:27 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D8E9721F85D1 for ; Tue, 22 May 2012 10:16:26 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E4E5F1B402F0; Tue, 22 May 2012 13:16:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <1F4D41D8-78ED-4EBB-883C-9B4462EBE14A@laposte.net> Date: Tue, 22 May 2012 13:16:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <74608BC7-11FE-428B-B16B-76AFFD26F632@kumari.net> References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> <20120520140421.9E5A520C611B@drugs.dv.isc.org> <96B542C8-F19D-470D-B648-154946D791A6@kumari.net> <1F4D41D8-78ED-4EBB-883C-9B4462EBE14A@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1278) Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 May 2012 17:16:27 -0000 On May 22, 2012, at 11:42 AM, R=E9mi Despr=E9s wrote: > Hi Warren, >=20 > Le 2012-05-21 =E0 16:49, Warren Kumari a =E9crit : >=20 >> [ Top posting / meta questions ] >>=20 >> So, both my memory and my google-foo are failing me=85 >>=20 >> Can anyone remember *why* the v6 in MTU is 1280 (and please don't say = "Because the RFC says so!"=85) >=20 > In the excellent French book in which I learned IPv6 in 2003 = (livre.g6.asso.fr/index.php/Format_du_paquet_IPv6), here is what I = learned: > "Choice of 1280 as minimum MTU is to permit IPv6 tunneling. 1500 = octets is the generally admitted link MTU, that imposed by Ethernet."=20 >=20 > As this permits multiple tunneling layers without fragmentation on the = most typical links, and limits to a moderate ratio waste of bandwidth on = 1500-octet remote links, this is IMHO a valuable choice. Yes, I get that it is to accommodate tunnel overhead (and still fit in = an Ethernet frame), I was more wondering why the overhead was chosen as = 220 bytes and not 216 or 247 or 196.324. I received this off-list (including with permissions): "Hi Warren, Off-list since I cannot find a definitive reference at this point. = The 1280 number was codified in RFC 2460 based on a back of the envelope = calculation by Steve Deering either before or during the Fall 1997 IETF = meeting. Starting with the Ethernet MTU of 1500, he subtracted the size = of : ethernet header, IPv6 header, IPv4 header (tunneling), and several = possible extension headers. That put the number at 1280 (with some = rounding to a 64-bit boundary)." W >=20 > RD >=20 >=20 >=20 >> I have some niggling voice in the back of my head making 3GPP noises, = but=85 >>=20 >> W >>=20 >> On May 20, 2012, at 10:04 AM, Mark Andrews wrote: >>=20 >>>=20 >>> In message <4FB89733.2080106@gmail.com>, Brian E Carpenter writes: >>>> On 2012-05-19 22:26, Randy Bush wrote: >>>>>> If you want to send packets of arbitrary size, in any environment >>>>>> where PMTUD is impossible or fails, won't you need to always = include >>>>>> a fragmentation header in every packet greater than 1280? >>>>>=20 >>>>> see discussion of jumbo frames, commonly 4k or 9k, between = consenting >>>>> adults on known links >>>>=20 >>>> Yes indeed, but that isn't the general case. Across the open = Internet, >>>> I think we have the situation I described. >>>>=20 >>>> On 2012-05-19 21:16, Gert Doering wrote: >>>>=20 >>>>>>> UDP packets larger than 1280 bytes >>>>>>> Don't do that! >>>>>=20 >>>>> Tell that to the DNS people. They seem to really like = not-using-TCP. >>>>=20 >>>> Yes, but I understand that DNSSEC more or less dooms that plan = anyway. >>>>=20 >>>> However, I thinks it's true that the only fail-safe solution is to >>>> include a frag header if you need to send UDP >1280. >>>>=20 >>>> Brian >>>=20 >>> For DNS we just fragment at 1280 using IPV6_USE_MIN_MTU. We were >>> thinking about this back in 1998 (draft-ietf-ipngwg-bsd-frag-00.txt) >>> which was rolled into the advanced socket api. It took a few more >>> years than I would have liked to become RFC and for implementations >>> to be available. EDNS was already being developed back then and >>> it was obvious that PMTUD wouldn't work for large nameservers even >>> if they got the ICMPv6 PTBs. >>>=20 >>> For DNS there is little to be gained by trying to send any bigger >>> packets. >>>=20 >>> YMMV for other UDP based protocols. >>>=20 >>> Mark >>>=20 >>>> Brian >>>> _______________________________________________ >>>> 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 >>>=20 >>=20 >> --=20 >> With Feudalism, it's your Count that votes. >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --=20 With Feudalism, it's your Count that votes. From fred@cisco.com Tue May 22 12:34:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3290921F851B for ; Tue, 22 May 2012 12:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUDjJAErqj+w for ; Tue, 22 May 2012 12:34:10 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 756A021F85AC for ; Tue, 22 May 2012 12:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=452; q=dns/txt; s=iport; t=1337715250; x=1338924850; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TWzvvkXR1Mn0YTQ/Bj794lRr1pgjbKFBc4/Xnn8q8JA=; b=SqxFrC1nuvlenHR3sLyupz4jylj65zzI1UzOMVxPfjmH78ppOaOXd5Dy Ksh1IdPR3wjTsYvb+vEd4sLqeyiqz7GKbAH+b/GBLT0Gd3h/ot4AmkeJW a5yGbLD30rI8NmPSuQ/mpDJ7jTyqPKGRauBcquzM1MY5GxCouypGDB8lZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGzpu0+rRDoG/2dsb2JhbABEtBeBB4IVAQEBAwESASc/BQsLRlcGLgeHZwSaY59siwiEW2IDiEOMWY4MgWSDCg X-IronPort-AV: E=Sophos;i="4.75,639,1330905600"; d="scan'208";a="43349243" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 22 May 2012 19:34:10 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4MJY9tU000527; Tue, 22 May 2012 19:34:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Tue, 22 May 2012 12:34:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <580B622E-1132-409D-A065-17C6FB5B3BF3@cisco.com> References: <201205191245.q4JCj1B08991@ftpeng-update.cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, draft-foo-v6ops-6rdmtu@tools.ietf.org Subject: Re: [v6ops] new draft: draft-foo-v6ops-6rdmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 May 2012 19:34:11 -0000 On May 21, 2012, at 2:19 PM, Mark Townsley wrote: > Encapsulation in 6rd comes from RFC 4213, including the basis for = recommendations on MTU handling (Section 3.2 of RFC 4213 addresses this = specifically, with pseudocode that would need to be rationalized with = yours proposed in this draft if it were accepted). If there is a problem = to be solved, let's solve in generically.=20 Agree. I'm very much in favor of generic solutions.= From rajiva@cisco.com Tue May 22 20:47:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4DF21F8606 for ; Tue, 22 May 2012 20:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-L6myYOyL5r for ; Tue, 22 May 2012 20:47:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDF821F8617 for ; Tue, 22 May 2012 20:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5335; q=dns/txt; s=iport; t=1337744834; x=1338954434; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=z9As34D6L1BfSf4iQ85mi603tQBoQ36S08yVHhbTRVI=; b=ErRDpo0Kks9EA8TechJSy+aZa8ZcvTaIclwyJ2jsSbFtHFo/ogUyzIVa IE95RhNE7zHqCiVpC5iXV3aU8xRNtrlsev8bRC8oOfzlSpexXfGDMjLbh lr9FQpSVXJ/Q2UseDzyqFhDXJOzzUqe1n+Lj+QKDtBXq6yMC+WDE6xS9k E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACBdvE+tJXHB/2dsb2JhbABDtC6BB4IVAQEBBAEBAQ8BHTwCCwwCAgIBCBEEAQEBCgYXAQYBGgYGHwkIAQEEARIIEweHXgMLC5sqlhwNiVIEihxuhF5iA4gQM41oiWiDFYFkgwg X-IronPort-AV: E=Sophos;i="4.75,641,1330905600"; d="scan'208";a="85717181" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 23 May 2012 03:47:14 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q4N3lEtA007620; Wed, 23 May 2012 03:47:14 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 22:47:14 -0500 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-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 May 2012 22:47:09 -0500 Message-ID: In-Reply-To: <74608BC7-11FE-428B-B16B-76AFFD26F632@kumari.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac04Pqdfes21gnxCSGyehTNdl4gY1AAVuInA References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net><4FB775A3.1030900@gmail.com><20120519.141906.74656347.sthaug@nethelp.no><4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com><20120520140421.9E5A520C611B@drugs.dv.isc.org><96B542C8-F19D-470D-B648-154946D791A6@kumari.net><1F4D41D8-78ED-4EBB-883C-9B4462EBE14A@laposte.net> <74608BC7-11FE-428B-B16B-76AFFD26F632@kumari.net> From: "Rajiv Asati (rajiva)" To: "Warren Kumari" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 23 May 2012 03:47:14.0417 (UTC) FILETIME=[BDCCAE10:01CD3896] Cc: v6ops@ietf.org Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 03:47:16 -0000 Why would Ethernet header size be subtracted in that equation, since = RFC894 (in 1984) had already specified 1500B size IP packet over = ethernet? I am puzzled. http://tools.ietf.org/html/rfc894 .. The minimum length of the data field of a packet sent over an Ethernet is 1500 octets, thus the maximum length of an IP datagram sent over an Ethernet is 1500 octets. Implementations are encouraged .. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Warren Kumari > Sent: Tuesday, May 22, 2012 1:16 PM > To: R=E9mi Despr=E9s > Cc: v6ops@ietf.org > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 >=20 > On May 22, 2012, at 11:42 AM, R=E9mi Despr=E9s wrote: >=20 > > Hi Warren, > > > > Le 2012-05-21 =E0 16:49, Warren Kumari a =E9crit : > > > >> [ Top posting / meta questions ] > >> > >> So, both my memory and my google-foo are failing me... > >> > >> Can anyone remember *why* the v6 in MTU is 1280 (and please don't = say > >> "Because the RFC says so!"...) > > > > In the excellent French book in which I learned IPv6 in 2003 > (livre.g6.asso.fr/index.php/Format_du_paquet_IPv6), here is what I > learned: > > "Choice of 1280 as minimum MTU is to permit IPv6 tunneling. 1500 = octets is > the generally admitted link MTU, that imposed by Ethernet." > > > > As this permits multiple tunneling layers without fragmentation on = the > most typical links, and limits to a moderate ratio waste of bandwidth = on > 1500-octet remote links, this is IMHO a valuable choice. >=20 > Yes, I get that it is to accommodate tunnel overhead (and still fit = in an > Ethernet frame), I was more wondering why the overhead was chosen as > 220 bytes and not 216 or 247 or 196.324. >=20 > I received this off-list (including with permissions): >=20 > "Hi Warren, > Off-list since I cannot find a definitive reference at this point. = The 1280 > number was codified in RFC 2460 based on a back of the envelope > calculation by Steve Deering either before or during the Fall 1997 = IETF > meeting. Starting with the Ethernet MTU of 1500, he subtracted the = size of : > ethernet header, IPv6 header, IPv4 header (tunneling), and several = possible > extension headers. That put the number at 1280 (with some rounding to = a > 64-bit boundary)." >=20 >=20 > W >=20 >=20 > > > > RD > > > > > > > >> I have some niggling voice in the back of my head making 3GPP = noises, > >> but... > >> > >> W > >> > >> On May 20, 2012, at 10:04 AM, Mark Andrews wrote: > >> > >>> > >>> In message <4FB89733.2080106@gmail.com>, Brian E Carpenter writes: > >>>> On 2012-05-19 22:26, Randy Bush wrote: > >>>>>> If you want to send packets of arbitrary size, in any = environment > >>>>>> where PMTUD is impossible or fails, won't you need to always > >>>>>> include a fragmentation header in every packet greater than = 1280? > >>>>> > >>>>> see discussion of jumbo frames, commonly 4k or 9k, between > >>>>> consenting adults on known links > >>>> > >>>> Yes indeed, but that isn't the general case. Across the open > >>>> Internet, I think we have the situation I described. > >>>> > >>>> On 2012-05-19 21:16, Gert Doering wrote: > >>>> > >>>>>>> UDP packets larger than 1280 bytes Don't do that! > >>>>> > >>>>> Tell that to the DNS people. They seem to really like = not-using-TCP. > >>>> > >>>> Yes, but I understand that DNSSEC more or less dooms that plan > anyway. > >>>> > >>>> However, I thinks it's true that the only fail-safe solution is = to > >>>> include a frag header if you need to send UDP >1280. > >>>> > >>>> Brian > >>> > >>> For DNS we just fragment at 1280 using IPV6_USE_MIN_MTU. We were > >>> thinking about this back in 1998 = (draft-ietf-ipngwg-bsd-frag-00.txt) > >>> which was rolled into the advanced socket api. It took a few more > >>> years than I would have liked to become RFC and for = implementations > >>> to be available. EDNS was already being developed back then and = it > >>> was obvious that PMTUD wouldn't work for large nameservers even if > >>> they got the ICMPv6 PTBs. > >>> > >>> For DNS there is little to be gained by trying to send any bigger > >>> packets. > >>> > >>> YMMV for other UDP based protocols. > >>> > >>> Mark > >>> > >>>> Brian > >>>> _______________________________________________ > >>>> 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 > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >>> > >> > >> -- > >> With Feudalism, it's your Count that votes. > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > -- > With Feudalism, it's your Count that votes. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Tue May 22 22:53:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3F521F85D3; Tue, 22 May 2012 22:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo7P-A+nSC2Q; Tue, 22 May 2012 22:53:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE82F21F8597; Tue, 22 May 2012 22:53:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120523055326.27310.39196.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 22:53:26 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-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, 23 May 2012 05:53:27 -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 : Wireline Incremental IPv6 Author(s) : Victor Kuarsingh Lee Howard Filename : draft-ietf-v6ops-wireline-incremental-ipv6-03.txt Pages : 28 Date : 2012-05-22 Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-i= pv6-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-ip= v6-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ From ales.vizdal@t-mobile.cz Wed May 23 02:49:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4930621F859B for ; Wed, 23 May 2012 02:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LufQ1rkg3bsy for ; Wed, 23 May 2012 02:49:56 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5C21F8596 for ; Wed, 23 May 2012 02:49:56 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 7A014285801; Wed, 23 May 2012 11:49:52 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Wed, 23 May 2012 11:49:52 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Joel jaeggli , IPv6 Ops WG Date: Wed, 23 May 2012 11:49:14 +0200 Thread-Topic: [v6ops] 6204bis draft 09 - http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Thread-Index: Ac02Pr1DOZn6Q0X3TGSnKoINA7bqMQCij1jg Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6806E9F41@SRVHKE02.rdm.cz> References: <4FB86EF8.9030101@bogus.com> In-Reply-To: <4FB86EF8.9030101@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 Subject: Re: [v6ops] 6204bis draft 09 - http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-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, 23 May 2012 09:49:57 -0000 Hello, I would like to propose a small wording change to increase the clarity of L= -2 in order to make sure that in case of multiple prefixes delegated to a CER a /64 from each of its delegated prefixes is assigned to each of its LAN in= terfaces. L-2: The IPv6 CE router MUST assign a separate /64 from *each of* its delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) for each of its LAN interfaces. WPD-8: the I-D.ietf-dhc-pd-exclude has recently been issued as an RFC6603 Cheers, Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Joel > jaeggli > Sent: Sunday, May 20, 2012 6:12 AM > To: IPv6 Ops WG > Subject: [v6ops] 6204bis draft 09 - http://tools.ietf.org/html/draft-ietf= -v6ops- > 6204bis-09 >=20 > In response to comments recieved during the 6204bis draft wglc and > subsequent discsussion among the authors, draft 09 was produced. >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 >=20 > diffs between the two are here: >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6204bis-09.txt >=20 > please review by tue 5/22, this is the version that I plan on generating > the document shepherds review from. It strikes me as unlikley that the > current discussion on mtu/mss adjustment is going to produce a > sustainable consensus and we should therefore consider where or whether > or where to expose that problem in a document. >=20 > Minor niggles can be corrected in auth-48, larger problems should not. >=20 > thanks > joel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed May 23 05:45:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2795221F86B1 for ; Wed, 23 May 2012 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq1ZY6i5s7AA for ; Wed, 23 May 2012 05:45:01 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A067521F85FB for ; Wed, 23 May 2012 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=128; q=dns/txt; s=iport; t=1337777101; x=1338986701; h=date:from:message-id:to:subject:cc; bh=9jGqEAwLQm6pXkngWif7+FZ15HjqGiY0554jdvxYlsA=; b=UvCBQRNhKWadUv1btQ1KKttqrz/ZkWavp7IS1YTwR36/Bns7J9lEndxG l0nxjcgMM1QL3r7ZW/6K8xd0FtjOq02m0C7POu6UZ1LdrCiOSbWsWcAHX yMnz/RPjJ7Ocj1zFnOJzMxux9P2/qHnZvMVVZRnlSvhOSruz09Ih5v+/D k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUGADnbvE+rRDoJ/2dsb2JhbABDok0BkWWBB4IuAWY8LYEKh2sMmkugBo0xgx4DiEONaIx9gWSDCg X-IronPort-AV: E=Sophos;i="4.75,645,1330905600"; d="scan'208";a="46065981" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 May 2012 12: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.3/8.14.3) with ESMTP id q4NCj19Q022281; Wed, 23 May 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q4NCj1X27445; Wed, 23 May 2012 05:45:01 -0700 (PDT) Date: Wed, 23 May 2012 05:45:01 -0700 (PDT) From: Message-Id: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-generic-v6ops-tunmtu@tools.ietf.org Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 12:45:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-generic-v6ops-tunmtu. Please take a look at it and comment. From Fred.L.Templin@boeing.com Wed May 23 07:17:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18621F8711 for ; Wed, 23 May 2012 07:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7Q8tipjG3Yg for ; Wed, 23 May 2012 07:17:28 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id CC89F21F86E4 for ; Wed, 23 May 2012 07:17:28 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4NEHi0R020861 for ; Wed, 23 May 2012 07:17:44 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4NEHfNt020841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 May 2012 07:17:41 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4NEHOwU009940; Wed, 23 May 2012 07:17:25 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4NEHOPl009928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 May 2012 07:17:24 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Wed, 23 May 2012 07:17:25 -0700 From: "Templin, Fred L" To: "fred@cisco.com" , "v6ops@ietf.org" Date: Wed, 23 May 2012 07:17:23 -0700 Thread-Topic: [v6ops] new draft: draft-foo-v6ops-6rdmtu Thread-Index: Ac01vXnnhKNa7irVRymTzkwpPijclQDMPuog Message-ID: References: <201205191245.q4JCj1B08991@ftpeng-update.cisco.com> In-Reply-To: <201205191245.q4JCj1B08991@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-foo-v6ops-6rdmtu@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-foo-v6ops-6rdmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 14:17:29 -0000 This draft is now deprecated by 'draft-generic-v6ops-tunmtu': https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ Please refer to this new document when commenting. Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > fred@cisco.com > Sent: Saturday, May 19, 2012 5:45 AM > To: v6ops@ietf.org > Cc: draft-foo-v6ops-6rdmtu@tools.ietf.org > Subject: [v6ops] new draft: draft-foo-v6ops-6rdmtu >=20 >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-foo- > v6ops-6rdmtu. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Wed May 23 07:17:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB0221F86E5 for ; Wed, 23 May 2012 07:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ7rkQ9IdzlS for ; Wed, 23 May 2012 07:17:42 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id A2EDE21F86E4 for ; Wed, 23 May 2012 07:17:42 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4NEHgYg001311 for ; Wed, 23 May 2012 07:17:42 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4NEHfO9001302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 May 2012 07:17:41 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4NEHfu4002128; Wed, 23 May 2012 09:17:41 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4NEHbla001990 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 May 2012 09:17:41 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 23 May 2012 07:17:38 -0700 From: "Templin, Fred L" To: "fred@cisco.com" , "v6ops@ietf.org" Date: Wed, 23 May 2012 07:17:37 -0700 Thread-Topic: [v6ops] new draft: draft-bar-v6ops-ismtu Thread-Index: Ac01vbuC9GnPpVoqTzug/PukcutNGQDMQ2TA Message-ID: References: <201205191245.q4JCj0q08985@ftpeng-update.cisco.com> In-Reply-To: <201205191245.q4JCj0q08985@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-bar-v6ops-ismtu@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-bar-v6ops-ismtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 14:17:43 -0000 This draft is now deprecated by 'draft-generic-v6ops-tunmtu': https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ Please refer to this new document when commenting. Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > fred@cisco.com > Sent: Saturday, May 19, 2012 5:45 AM > To: v6ops@ietf.org > Cc: draft-bar-v6ops-ismtu@tools.ietf.org > Subject: [v6ops] new draft: draft-bar-v6ops-ismtu >=20 >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-bar- > v6ops-ismtu. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Wed May 23 07:22:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7530421F84FA for ; Wed, 23 May 2012 07:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61A0vuth+LG2 for ; Wed, 23 May 2012 07:22:00 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 9435121F84FB for ; Wed, 23 May 2012 07:21:59 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4NEMFQb028337 for ; Wed, 23 May 2012 07:22:16 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4NEMFkc028333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 May 2012 07:22:15 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4NELwqb030596; Wed, 23 May 2012 07:21:58 -0700 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4NELvtP030569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 May 2012 07:21:58 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 23 May 2012 07:21:57 -0700 From: "Templin, Fred L" To: "fred@cisco.com" , "v6ops@ietf.org" Date: Wed, 23 May 2012 07:21:56 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac044fL08M8tz+9SQ1WFD/ergfftmAADOZwQ Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> In-Reply-To: <201205231245.q4NCj1X27445@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 14:22:00 -0000 Please review and comment on 'draft-generic-v6ops-tunmtu': https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ This new document takes the radical approach of proposing IPv6 router fragmentation at the tunnel ingress so that the tunnel MTU can be jacked up to 1500 bytes. The document notes issues that arise when the IPv6 router performs fragmentation - most notably, the selection of the Identification value to place in the (router-inserted) fragmentation header. Please review and comment on this thread. Remember that this approach is proposing something new and different and should be discussed further on the list. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > fred@cisco.com > Sent: Wednesday, May 23, 2012 5:45 AM > To: v6ops@ietf.org > Cc: draft-generic-v6ops-tunmtu@tools.ietf.org > Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-generic- > v6ops-tunmtu. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Wed May 23 07:39:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E61F21F8739 for ; Wed, 23 May 2012 07:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a71gyBUedxL6 for ; Wed, 23 May 2012 07:39:03 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 3C67821F8721 for ; Wed, 23 May 2012 07:39:03 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4NEd2fO012749 for ; Wed, 23 May 2012 07:39:02 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4NEd2jH012737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 May 2012 07:39:02 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4NEd19H023930; Wed, 23 May 2012 07:39:02 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4NEd04Z023883 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 May 2012 07:39:01 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 23 May 2012 07:39:00 -0700 From: "Templin, Fred L" To: Warren Kumari , Mark Andrews Date: Wed, 23 May 2012 07:38:59 -0700 Thread-Topic: [v6ops] proposed TCP MSS text for rfc6204bis Thread-Index: Ac03YOLmgT/473IOSBKU9g9nQkXpzQBkHpvQ Message-ID: References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> <20120520140421.9E5A520C611B@drugs.dv.isc.org> <96B542C8-F19D-470D-B648-154946D791A6@kumari.net> In-Reply-To: <96B542C8-F19D-470D-B648-154946D791A6@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 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 14:39:04 -0000 > Can anyone remember *why* the v6 in MTU is 1280 (and please don't say > "Because the RFC says so!"...) You have to reach way back into history to find the reasoning. The first proposal of moving from 576 to 1280 was from Steve Deering in November 1997. Go to: https://www.sixxs.net/archive/docs/ipng-archives/ipng.199711 and search for: (IPng 4802) increasing the IPv6 minimum MTU Remember that IPv6 is a very old protocol, and the history goes way back. Digging the archives can be very revealing. Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Warren Kumari > Sent: Monday, May 21, 2012 7:49 AM > To: Mark Andrews > Cc: v6ops@ietf.org > Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis >=20 > [ Top posting / meta questions ] >=20 > So, both my memory and my google-foo are failing me... >=20 > Can anyone remember *why* the v6 in MTU is 1280 (and please don't say > "Because the RFC says so!"...) >=20 > I have some niggling voice in the back of my head making 3GPP noises, but= ... >=20 > W >=20 > On May 20, 2012, at 10:04 AM, Mark Andrews wrote: >=20 > > > > In message <4FB89733.2080106@gmail.com>, Brian E Carpenter writes: > >> On 2012-05-19 22:26, Randy Bush wrote: > >>>> If you want to send packets of arbitrary size, in any environment > >>>> where PMTUD is impossible or fails, won't you need to always include > >>>> a fragmentation header in every packet greater than 1280? > >>> > >>> see discussion of jumbo frames, commonly 4k or 9k, between consenting > >>> adults on known links > >> > >> Yes indeed, but that isn't the general case. Across the open Internet, > >> I think we have the situation I described. > >> > >> On 2012-05-19 21:16, Gert Doering wrote: > >> > >>>>> UDP packets larger than 1280 bytes > >>>>> Don't do that! > >>> > >>> Tell that to the DNS people. They seem to really like not-using-TCP. > >> > >> Yes, but I understand that DNSSEC more or less dooms that plan anyway. > >> > >> However, I thinks it's true that the only fail-safe solution is to > >> include a frag header if you need to send UDP >1280. > >> > >> Brian > > > > For DNS we just fragment at 1280 using IPV6_USE_MIN_MTU. We were > > thinking about this back in 1998 (draft-ietf-ipngwg-bsd-frag-00.txt) > > which was rolled into the advanced socket api. It took a few more > > years than I would have liked to become RFC and for implementations > > to be available. EDNS was already being developed back then and > > it was obvious that PMTUD wouldn't work for large nameservers even > > if they got the ICMPv6 PTBs. > > > > For DNS there is little to be gained by trying to send any bigger > > packets. > > > > YMMV for other UDP based protocols. > > > > Mark > > > >> Brian > >> _______________________________________________ > >> 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 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > -- > With Feudalism, it's your Count that votes. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed May 23 07:48:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A026621F8703 for ; Wed, 23 May 2012 07:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yawY9misJoT for ; Wed, 23 May 2012 07:48:10 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 215E921F86D1 for ; Wed, 23 May 2012 07:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=492; q=dns/txt; s=iport; t=1337784490; x=1338994090; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TqKUD3QKkhJuCMukhwRK5mqajE5VYgE3G6TSwZ8vuYE=; b=mydNW/iieyf1JjwMsg9+CMOTxT9PSJe1Li8xMce8WORVLOw4TIwYqRq5 RZxHo3QZSjUpn/xIuic2MXc2QZoeFnIott6iyPJebbgShPGWCMwu/6und FheZBcOQzUvtvXiuZtmgsgCMzriGSanoM8mT+K4x0X8+Nb61RnMwytUi7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACD4vE+rRDoJ/2dsb2JhbABEtDSBB4IVAQEBAwESASc/BQsLRlcGNYdnBJpYoASLD4ReYgOIQ4xZjgyBZIMK X-IronPort-AV: E=Sophos;i="4.75,645,1330905600"; d="scan'208";a="45994346" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 23 May 2012 14:48:09 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4NEm8iL023798; Wed, 23 May 2012 14:48:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Wed, 23 May 2012 07:48:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 14:48:10 -0000 On May 23, 2012, at 7:21 AM, Templin, Fred L wrote: > Please review and comment on this thread. Remember that > this approach is proposing something new and different > and should be discussed further on the list. I will indeed comment in the thread. Generating discussion on the list, = apart from the initial poke you saw this morning, is your = responsibility. As we have been doing for a couple of years now, face = time in Vancouver depends on list activity and interest.= From simon.perreault@viagenie.ca Wed May 23 07:50:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47D321F84E4 for ; Wed, 23 May 2012 07:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4URWxjEXrXI1 for ; Wed, 23 May 2012 07:50:04 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 0D12921F84DE for ; Wed, 23 May 2012 07:50:04 -0700 (PDT) Received: from [IPv6:2607:fa48:94:201:c0ac:7b22:4916:b8c6] (unknown [IPv6:2607:fa48:94:201:c0ac:7b22:4916:b8c6]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4721B400BD for ; Wed, 23 May 2012 10:50:03 -0400 (EDT) Message-ID: <4FBCF91B.5080107@viagenie.ca> Date: Wed, 23 May 2012 10:50:03 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FB74456.2090009@gmail.com> <20120519080006.GZ84425@Space.Net> <4FB775A3.1030900@gmail.com> <20120519.141906.74656347.sthaug@nethelp.no> <4FB7A7CC.6060503@gmail.com> <4FB89733.2080106@gmail.com> <20120520140421.9E5A520C611B@drugs.dv.isc.org> <96B542C8-F19D-470D-B648-154946D791A6@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 14:50:05 -0000 On 2012-05-23 10:38, Templin, Fred L wrote: > Go to: > > https://www.sixxs.net/archive/docs/ipng-archives/ipng.199711 > > and search for: > > (IPng 4802) increasing the IPv6 minimum MTU Direct link for the lazy: http://web.archive.org/web/20001210152900/http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1997-12/0052.html Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fred@cisco.com Wed May 23 09:48:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A80F21F8759 for ; Wed, 23 May 2012 09:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW-Ba5v16R7y for ; Wed, 23 May 2012 09:48:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E116A21F862B for ; Wed, 23 May 2012 09:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=10883; q=dns/txt; s=iport; t=1337791726; x=1339001326; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ThF3S3CLRvUQBFHoV2XvELK4gSiwLrXMVxlZVY2unpk=; b=MW+2lgSqEDax1exsdlNvcaoL2lPWgS7ijjGA2AMEo7PqXfAWgxdkurq6 hp+JRF6WLn3+/umAhhvSY/Hqm4BMENezxJ/bpQDyJCJd0o+ElciABhpqY akJrJXxsVvPHdVECCf81R9uhRKevJgdjnwuE+Qth8bZFqrkH6f3G0FQzB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAUUvU+tJXG8/2dsb2JhbABDtCyBB4IVAQEBBBIBFBM/EAsYLlcGCh0Oh2uaeZ9zin0gB4QZYAOIP4xZjgyBZIMKgTcB X-IronPort-AV: E=Sophos;i="4.75,645,1330905600"; d="scan'208";a="85970391" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 23 May 2012 16:48:45 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4NGmihN010960; Wed, 23 May 2012 16:48:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Wed, 23 May 2012 09:48:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: draft-generic-v6ops-tunmtu@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 16:48:47 -0000 On May 23, 2012, at 7:21 AM, Templin, Fred L wrote: > Please review and comment on this thread. Remember that this approach = is proposing something new and different and should be discussed further = on the list. A nit-pick point: I would prefer that the text didn't focus on "1500 = byte MTUs" as much as simply allowing for larger PMTUs. For example, if = I have an otherwise 9K-clean path but have a tunnel in it, I wouldn't = want the tunnel to jack me up from a 1460 byte PMTU to a 1500 byte PMTU = by sending slightly-too-large packets as packet pairs, one large and one = small; I'd want a 9K-clean path, with small packet trains as long as = they need to be. You'll notice "1460". I'm also not necessarily thinking = about IPv6/IPv4 tunnels; I'm just as happy to think about IPv4/IPv6 = tunnels or IPv6/IPv6 tunnels. I think you can address this comment with = a sentence or two up front making the point clear, and then globally = replacing references to tunnel types with the word "tunnel", and = references to PMTUs having a given value to "PMTU". As I understand it - quick read - you view an IPv6 end-to-end path as = being from the addressed source to the addressed destination, and = fragmentation/reassembly as being a process between the addressed source = and destination. Hence, end to end fragmentation and reassembly as = described in RFC 2460 could go from tunnel endpoint to tunnel endpoint. A quick comment on the ident field issue. If you need a 32 bit number to = take a given value at most once every 60 seconds, one implementation = would be to have a clock that counts every 14 ns and use its value in = the field (eg, 4294967296/60=3D71582788 distinct ident values per = second). At the point where we have links for which even that isn't fast = enough, putting multiple EIDs on the same source interface allows you to = re-use the clock value. I could imagine other uses for the multiple-EID = model; if I have an input-queued switch and as a result am doing the = fragmentation on each of a number of ingress line cards that feed to a = single egress line card, I could associate a different EID with each = ingress card (as a source address) and give each a separate clock. That = way I don't have to coordinate the packet streams.=20 My understanding of the reason that the community has moved away from = fragmentation in the network is the implied unreliability, the = processing load, and the implications for the intermediate node's = internal structure.=20 The reliability issues comes to this. Take a look at ftp://ftpeng.cisco.com/fred/templin/LACNIC_Wednesday.pptx which is a talk I gave at LACNIC a couple of weeks ago. Look = specifically at slide 14. This is a very simple test that I actually did = for a Networkers talk a decade back. The test setup is: +------+ +------+ +------+ +------+ |Peer 1| |Router+------------+Router| |Peer 2| +--+---+ +--+---+ +--+---+ +--+---+ | | | | --+------------+----- --+-------------+----- Peer 1 and 2 are PCs running some variant on unix, and the routers are = 26xx series routers connected back to back at 2 MBPS. One could use any = pair of link speeds one likes as long as one gets a dumbbell topology; = the value of a relatively low link speed is that you don't have to = generate a lot of traffic to get the effect. The effect is the some, = however, regardless of link speed; it's just that numbers scale up and = down accordingly. On Peer 1, I place a file of a large enough size that it's going to take = a while - maybe ten seconds - to move it to Peer 2 across the = intervening link. On Peer 2, I open two windows. In one, I start a ping = -s to Peer 1, and store the output in a file. This will run for the = duration of the test. In the second window, I run a script. The script = will: for N =3D 1..15 open N parallel FTP sessions to GET N instances of the file = from Peer 1 wait until they all complete delete all of the resulting local files sleep for a couple of seconds end Offline, I then do some number crunching on the "ping" durations. In = sets of (IIRC) 11 numbers, I find the least (magenta), the greatest = (yellow), the arithmetic mean (dark blue), and the standard deviation = (light blue), and plot them. So, in the graphic, going left to right, you see bumps of increasing = height and width for one FTP session, two, three, four, ..., and on the = right-most side the bump is for 15 FTPs in parallel. The maximum queue = depth is Cisco's standard 40 buffers. An interesting implication: at the = left side, a loss results in a TCP fast retransmit event, while on the = right side, 40/15 < 3, so we have to assume that every loss (or at least = many of them) results in a timeout/retransmission. With the pings, we = have to assume we are getting a sampled measurement - losses only occur = when there are more than 40 packets in the queue. Hence, I have to = believe that the drop-off rate noticeable on the fourth through eleventh = iterations are from slow start driving until there is a loss, and then = some FTPs moving data a little more quickly than others, so that at the = end of the iteration they don't all finish simultaneously. The key thing I want to point out is this. Especially on the 11..15 = iterations, the queue is at full occupancy most of the time. Hence, the = points at which we see a tail drop are when Peer 1 sends multiple = packets in a burst, and it is more likely to be the last packet in the = burst that is dropped than the first.=20 When we fragment packets in the network, we almost by definition get = such bursts of traffic, meaning that we have an increased probability of = dropping one of the fragments in a fragmented packet burst. That in turn = has an embedded attack and creates an embedded point of vulnerability. = If I am fragmenting packets but transferring them on a multi-path route, = I can't say "oops, missed that fragment, toss all of the fragments I = have assembled so far" as I can with PPP Multilink; I have to let them = time out. So I now have a reassembly failure attack, and if someone = wants to attack the infrastructure, spoofed source addresses allow him = to at least consume buffer if not insert data into reassembled = datagrams. One of the key reasons that people have pushed back hard on = fragmentation in the network is an observed decrease in reliability of = the path. The processing load is dependent on the structure of the implementation. = In any event, doing something is more of a processing load than not = doing it, so by definition fragmentation and reassembly increase = processing load. Now, how does one store packets? One storage structure is to simply have a pool of areas of memory of a = stated size. When the controller starts to store a packet it is = receiving, it has no idea how large the packet will be, so it grabs a = standard buffer and puts a packet into it, whether the packet is large = or small. On an ASR9K, we put 2 Gbytes of buffer on a line card, and = people tend to assume that means that we can store many seconds worth of = traffic. To be honest, I don't know what the buffer structure is on an = ASR9K, but I'll bet it is simple linear buffers. If so, it means we can = store many small packets and don't have to think too hard about fancy = mechanisms for dealing with buffers. When we get larger packets, we're = storing the same amount of data, but more compactly. =46rom a = fragmentation perspective, it has a significant down side; we have to = physically copy data when I fragment packets. That's a big deal. Another storage structure is to have scatter-gather buffers, with data = separate from description. In this case, fragmentation (and reassembly) = consist of creating a small buffer for the indicated header attached to = a second descriptor that points into the buffer being fragmented. I = might therefore receive: +--+ |D1+----+--------------------------------------------+ +--+ | | V start V end +-------------------------------------------------------+ | Data | +-------------------------------------------------------+ and divide it into two messages: V start V end +-------------------------------------------------------+ | Data | +-------------------------------------------------------+ ^ ^^ ^ | || | +---------------++----+----------------------+ | | +--+ +-++ +--+ +-++ |D1+-->|D2| |D3+-->|D4| +-++ +--+ +-++ +--+ | | ++-+ ++-+ | | | | V V V V +----+ +----+ |HDR1| |HDR2| +----+ +----+ Possible? Yes. I have done it in products I built in the 1980's and = 1990's, and it has some similarities to the "particle" data structure = used in some of Cisco's products today. Did you say "Terabit"? Hmm. = Well, it reduces the data copy overheads, but it also means that the = process of chaining two buffers has implications - either I can't simply = feed them into a FIFO without ensuring that the FIFO won't underrun = (which means that the headers have to have a certain minimum size, as is = required by the LANCE), or I have to gather an entire message into some = form of memory system before I can start transmitting it. One way or = another, it has its own processing loads. The widespread use of fragmentation/reassembly *can* also mean that some = product designs have to be forklift-upgraded, if the buffer design is = presumed in hardware and can't be readily changed. Intellectually, I understand where you're coming from and don't see much = of an issue with it. Practically, I think the received wisdom of = preferring a solid PMTU design that limits or eliminates the need for = fragmentation in the network is a good thing. That falls under "In = theory, theory and practice are the same thing". I would *far* rather = see hosts implement RFC 4821 (which yields a PMTU result without = depending on ICMP) than have fragmentation and reassembly in the = network. My two yen. From Fred.L.Templin@boeing.com Wed May 23 10:58:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9929021F8687 for ; Wed, 23 May 2012 10:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id As7dxlvq3epw for ; Wed, 23 May 2012 10:58:02 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1F35721F85D9 for ; Wed, 23 May 2012 10:58:02 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4NHvtVi005558 for ; Wed, 23 May 2012 12:57:55 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4NHvsTO005549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 May 2012 12:57:55 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4NHvs1Q024262; Wed, 23 May 2012 10:57:54 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4NHvrAw024218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 May 2012 10:57:53 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Wed, 23 May 2012 10:57:53 -0700 From: "Templin, Fred L" To: Fred Baker Date: Wed, 23 May 2012 10:57:51 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac05A+z3K0Yxdl2ZS3y3UduXUyT2VQABVu8g Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> In-Reply-To: <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 17:58:03 -0000 Hi Fred, You raise a number of interesting points. Let me see if I can follow up below: > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, May 23, 2012 9:49 AM > To: Templin, Fred L > Cc: v6ops@ietf.org WG; draft-generic-v6ops-tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > On May 23, 2012, at 7:21 AM, Templin, Fred L wrote: > > Please review and comment on this thread. Remember that this approach i= s > proposing something new and different and should be discussed further on > the list. >=20 > A nit-pick point: I would prefer that the text didn't focus on "1500 byte > MTUs" as much as simply allowing for larger PMTUs. For example, if I have > an otherwise 9K-clean path but have a tunnel in it, I wouldn't want the > tunnel to jack me up from a 1460 byte PMTU to a 1500 byte PMTU by sending > slightly-too-large packets as packet pairs, one large and one small; I'd I was actually thinking to have both fragments roughly the same size; or, certainly no more than 1280/ea. Plus, the fragmenter has no way of knowing whether the reassembler can do more than 1500 - so, 1500 is the absolute maximum we can achieve. > want a 9K-clean path, with small packet trains as long as they need to be= . AFAICT, barring congestion the probability of packet delivery decreases exponentially with the number of fragments. So, if the delivery probability of a single packet is P, and there are N fragments, then the delivery probability for the whole packet is P^N. That is why I want to keep N at 2.=20 > You'll notice "1460". I'm also not necessarily thinking about IPv6/IPv4 > tunnels; I'm just as happy to think about IPv4/IPv6 tunnels or IPv6/IPv6 > tunnels. Yes to the IPv6-in-IPv6 (it's in the draft); not sure about the IPv4-in-IPv6. The reason I'm not sure is that IPv4 fragmentation and reassembly is a mess and can't even be used if the IPv4 packet has DF=3D1. So, I think we need some other sort of solution for that. > I think you can address this comment with a sentence or two up > front making the point clear, and then globally replacing references to > tunnel types with the word "tunnel", and references to PMTUs having a > given value to "PMTU". I'll see what I can do about this. > > As I understand it - quick read - you view an IPv6 end-to-end path as > being from the addressed source to the addressed destination, and > fragmentation/reassembly as being a process between the addressed source > and destination. Not quite - I am viewing it as fragmentation at the tunnel ingress and reassembly at the final destination. This is a key and important point - the tunnel egress does not need to do anything at all beyond what it already does. > Hence, end to end fragmentation and reassembly as > described in RFC 2460 could go from tunnel endpoint to tunnel endpoint. As above, it is from tunnel ingress to final destination; not tunnel ingress to tunnel egress. > A quick comment on the ident field issue. If you need a 32 bit number to > take a given value at most once every 60 seconds, one implementation woul= d > be to have a clock that counts every 14 ns and use its value in the field > (eg, 4294967296/60=3D71582788 distinct ident values per second). Thanks for the good suggestion, and I will have to think more about it. Having a special clock seems a bit onerous to me from a layman's perspective however. If you or anyone else have any other ideas on how to portion the Ident values, I'm open to suggestions.=20 > At the > point where we have links for which even that isn't fast enough, putting > multiple EIDs on the same source interface allows you to re-use the clock > value. I could imagine other uses for the multiple-EID model; if I have a= n > input-queued switch and as a result am doing the fragmentation on each of > a number of ingress line cards that feed to a single egress line card, I > could associate a different EID with each ingress card (as a source > address) and give each a separate clock. That way I don't have to > coordinate the packet streams. By EID, do you mean the source/destination? If so, then your point is consistent with Section 4.5 of RFC2460 and is also allowed by the draft. Having multiple ident counters would certainly boost the bandwidth - maybe keep a few ident counters and use some sort of hash function based on source/destination address to select the counter. That should allow the tunnel ingress to avoid rate limiting in may cases. > My understanding of the reason that the community has moved away from > fragmentation in the network is the implied unreliability, the processing > load, and the implications for the intermediate node's internal structure= . I have been assured by at least one equipment manufacturing person that routers can handle fragmentation at line rates. Or, maybe I misunderstood him? =20 > The reliability issues comes to this. Take a look at > ftp://ftpeng.cisco.com/fred/templin/LACNIC_Wednesday.pptx > which is a talk I gave at LACNIC a couple of weeks ago. Look specifically > at slide 14. This is a very simple test that I actually did for a > Networkers talk a decade back. The test setup is: >=20 > +------+ +------+ +------+ +------+ > |Peer 1| |Router+------------+Router| |Peer 2| > +--+---+ +--+---+ +--+---+ +--+---+ > | | | | > --+------------+----- --+-------------+----- >=20 > Peer 1 and 2 are PCs running some variant on unix, and the routers are > 26xx series routers connected back to back at 2 MBPS. One could use any > pair of link speeds one likes as long as one gets a dumbbell topology; th= e > value of a relatively low link speed is that you don't have to generate a > lot of traffic to get the effect. The effect is the some, however, > regardless of link speed; it's just that numbers scale up and down > accordingly. >=20 > On Peer 1, I place a file of a large enough size that it's going to take = a > while - maybe ten seconds - to move it to Peer 2 across the intervening > link. On Peer 2, I open two windows. In one, I start a ping -s to Peer 1, > and store the output in a file. This will run for the duration of the > test. In the second window, I run a script. The script will: >=20 > for N =3D 1..15 > open N parallel FTP sessions to GET N instances of the file from > Peer 1 > wait until they all complete > delete all of the resulting local files > sleep for a couple of seconds > end >=20 > Offline, I then do some number crunching on the "ping" durations. In sets > of (IIRC) 11 numbers, I find the least (magenta), the greatest (yellow), > the arithmetic mean (dark blue), and the standard deviation (light blue), > and plot them. >=20 > So, in the graphic, going left to right, you see bumps of increasing > height and width for one FTP session, two, three, four, ..., and on the > right-most side the bump is for 15 FTPs in parallel. The maximum queue > depth is Cisco's standard 40 buffers. An interesting implication: at the > left side, a loss results in a TCP fast retransmit event, while on the > right side, 40/15 < 3, so we have to assume that every loss (or at least > many of them) results in a timeout/retransmission. With the pings, we hav= e > to assume we are getting a sampled measurement - losses only occur when > there are more than 40 packets in the queue. Hence, I have to believe tha= t > the drop-off rate noticeable on the fourth through eleventh iterations ar= e > from slow start driving until there is a loss, and then some FTPs moving > data a little more quickly than others, so that at the end of the > iteration they don't all finish simultaneously. >=20 > The key thing I want to point out is this. Especially on the 11..15 > iterations, the queue is at full occupancy most of the time. Hence, the > points at which we see a tail drop are when Peer 1 sends multiple packets > in a burst, and it is more likely to be the last packet in the burst that > is dropped than the first. >=20 > When we fragment packets in the network, we almost by definition get such > bursts of traffic, meaning that we have an increased probability of > dropping one of the fragments in a fragmented packet burst. That in turn > has an embedded attack and creates an embedded point of vulnerability. If > I am fragmenting packets but transferring them on a multi-path route, I > can't say "oops, missed that fragment, toss all of the fragments I have > assembled so far" as I can with PPP Multilink; I have to let them time > out. So I now have a reassembly failure attack, and if someone wants to > attack the infrastructure, spoofed source addresses allow him to at least > consume buffer if not insert data into reassembled datagrams. > One of the key reasons that people have pushed back hard on fragmentation > in the network is an observed decrease in reliability of the path. Well, remember I am only talking about fragment pairs; not about fragment multiples. Loss unit less than retransmission unit is certainly a consideration, but how "bad" is "too bad"? > The processing load is dependent on the structure of the implementation. > In any event, doing something is more of a processing load than not doing > it, so by definition fragmentation and reassembly increase processing > load. Now, how does one store packets? >=20 > One storage structure is to simply have a pool of areas of memory of a > stated size. When the controller starts to store a packet it is receiving= , > it has no idea how large the packet will be, so it grabs a standard buffe= r > and puts a packet into it, whether the packet is large or small. On an > ASR9K, we put 2 Gbytes of buffer on a line card, and people tend to assum= e > that means that we can store many seconds worth of traffic. To be honest, > I don't know what the buffer structure is on an ASR9K, but I'll bet it is > simple linear buffers. If so, it means we can store many small packets an= d > don't have to think too hard about fancy mechanisms for dealing with > buffers. When we get larger packets, we're storing the same amount of > data, but more compactly. From a fragmentation perspective, it has a > significant down side; we have to physically copy data when I fragment > packets. That's a big deal. Well, as I said the impression I got was that the routers are much more adept at handling fragmentation now than they were way back when "Fragmentation Considered Harmful" hit the streets. And again, it is the host and not some router that gets to do the reassembly. > Another storage structure is to have scatter-gather buffers, with data > separate from description. In this case, fragmentation (and reassembly) > consist of creating a small buffer for the indicated header attached to a > second descriptor that points into the buffer being fragmented. I might > therefore receive: >=20 > +--+ > |D1+----+--------------------------------------------+ > +--+ | | > V start V end > +-------------------------------------------------------+ > | Data | > +-------------------------------------------------------+ >=20 > and divide it into two messages: >=20 > V start V end > +-------------------------------------------------------+ > | Data | > +-------------------------------------------------------+ > ^ ^^ ^ > | || | > +---------------++----+----------------------+ > | | > +--+ +-++ +--+ +-++ > |D1+-->|D2| |D3+-->|D4| > +-++ +--+ +-++ +--+ > | | > ++-+ ++-+ > | | | | > V V V V > +----+ +----+ > |HDR1| |HDR2| > +----+ +----+ >=20 > Possible? Yes. I have done it in products I built in the 1980's and > 1990's, and it has some similarities to the "particle" data structure use= d > in some of Cisco's products today. Did you say "Terabit"? Hmm. Well, it > reduces the data copy overheads, but it also means that the process of > chaining two buffers has implications - either I can't simply feed them > into a FIFO without ensuring that the FIFO won't underrun (which means > that the headers have to have a certain minimum size, as is required by > the LANCE), or I have to gather an entire message into some form of memor= y There was an Ethernet chipset called "LANCE" back in the 1980's - is that what you're talking about, or something else? > system before I can start transmitting it. One way or another, it has its > own processing loads. >=20 >=20 > The widespread use of fragmentation/reassembly *can* also mean that some > product designs have to be forklift-upgraded, if the buffer design is > presumed in hardware and can't be readily changed. Well, placement of tunnel routers is supposed to be incrementally deployable - and not required at all routers. =20 > Intellectually, I understand where you're coming from and don't see much > of an issue with it. Practically, I think the received wisdom of > preferring a solid PMTU design that limits or eliminates the need for > fragmentation in the network is a good thing. That falls under "In theory= , > theory and practice are the same thing". I would *far* rather see hosts > implement RFC 4821 (which yields a PMTU result without depending on ICMP) > than have fragmentation and reassembly in the network. I'm definitely with you on getting all hosts to do RFC4821. But, it may take a long time between now and then and I'd rather have working tunnels in the nearer term. > My two yen. Worth more than that, IMHO. Fred fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Wed May 23 11:17:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD68C21F8789 for ; Wed, 23 May 2012 11:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvvQRW68blWp for ; Wed, 23 May 2012 11:17:47 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 39B4521F8741 for ; Wed, 23 May 2012 11:17:47 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4NIHkkf002354 for ; Wed, 23 May 2012 11:17:46 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4NIHjTt002342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 May 2012 11:17:45 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4NIHjPt028832; Wed, 23 May 2012 11:17:45 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4NIHj1p028787 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 May 2012 11:17:45 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Wed, 23 May 2012 11:17:45 -0700 From: "Templin, Fred L" To: Fred Baker Date: Wed, 23 May 2012 11:17:43 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac05A+z3K0Yxdl2ZS3y3UduXUyT2VQABVu8gAAGogxA= Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 18:17:47 -0000 > > Hence, end to end fragmentation and reassembly as > > described in RFC 2460 could go from tunnel endpoint to tunnel endpoint. >=20 > As above, it is from tunnel ingress to final destination; > not tunnel ingress to tunnel egress. Correcting myself, you are correct. It could be a nested tunnel-within-a-tunnel, in which case the "final destination" could itself be a router's tunnel endpoint. Thanks - Fred fred.l.templin@boeing.com=20 From Fred.L.Templin@boeing.com Wed May 23 11:24:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A4321F8795 for ; Wed, 23 May 2012 11:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znHu9G6z1XFq for ; Wed, 23 May 2012 11:24:09 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 7A96F21F8793 for ; Wed, 23 May 2012 11:24:09 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4NIO9XQ013595 for ; Wed, 23 May 2012 11:24:09 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4NIO8Se013591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 May 2012 11:24:08 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4NIO8HU025932; Wed, 23 May 2012 11:24:08 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4NIO8pU025904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 May 2012 11:24:08 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Wed, 23 May 2012 11:24:08 -0700 From: "Templin, Fred L" To: Fred Baker Date: Wed, 23 May 2012 11:24:06 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac05A+z3K0Yxdl2ZS3y3UduXUyT2VQABVu8gAAGogxAAACrG4A== Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 May 2012 18:24:10 -0000 Oh, and another idea; I could make it so that the tunnel ingress has three "regions" in its MTU handling: 1) 1280 or smaller are admitted into the tunnel in one piece 2) 1281 - 1500 are fragmented into two pieces before admission into the tunnel 3) 1501 or larger are admitted into the tunnel in one piece Clause 3) is new, and the idea is this. If someone wants to do 1501 or larger they had better be using RFC4821 - then, jumboframes are naturally supported. That ought to help drive RFC4821 deployment! Thanks - Fred fred.l.templin@boeing.com From dr@cluenet.de Thu May 24 00:47:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B645221F85DF for ; Thu, 24 May 2012 00:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mMErvHNarQY for ; Thu, 24 May 2012 00:47:40 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 11A3121F85D5 for ; Thu, 24 May 2012 00:47:39 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id A4A1F1083AB; Thu, 24 May 2012 09:47:37 +0200 (CEST) Date: Thu, 24 May 2012 09:47:37 +0200 From: Daniel Roesen To: v6ops@ietf.org, "draft-generic-v6ops-tunmtu@tools.ietf.org" Message-ID: <20120524074737.GC16448@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "draft-generic-v6ops-tunmtu@tools.ietf.org" References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 May 2012 07:47:40 -0000 On Wed, May 23, 2012 at 10:57:51AM -0700, Templin, Fred L wrote: > Yes to the IPv6-in-IPv6 (it's in the draft); not sure > about the IPv4-in-IPv6. The reason I'm not sure is that > IPv4 fragmentation and reassembly is a mess and can't > even be used if the IPv4 packet has DF=1. So, I think > we need some other sort of solution for that. The whole DSL (PPPoE session on DSL, with L2TP tunnel backhaul and wholesale delivery) works on what factually is a tunnel payload MTU of less than 1500. When used with MSS clamping applied (this is generally the case - I haven't seen different anywhere yet), this works for basically almost everyone. About 22 million DSL subscribers in Germany alone live "happily" with that approach. I don't see why the same approach doesn't work for DS-Lite too, and field testing for many months hasn't brought any indication of the contrary. Can we pretty please fix DS-Lite too while we're at it (fragment the payload, not the tunnel, and apply MSS clamping to avoid unnecessary in-transit fragmentation) in the spec / by updating the spec? Operators are asking vendors for that behaviour anyway to have DS-Lite operationally deployable. Better have it officially specified. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Fred.L.Templin@boeing.com Thu May 24 08:33:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030B621F8606 for ; Thu, 24 May 2012 08:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujFV3P8vm5ha for ; Thu, 24 May 2012 08:33:42 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 84C3F21F85FF for ; Thu, 24 May 2012 08:33:42 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4OFXdom015756 for ; Thu, 24 May 2012 08:33:41 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4OFXbn9015531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 May 2012 08:33:38 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4OFXatF030280; Thu, 24 May 2012 08:33:36 -0700 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4OFXaqZ030277 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 24 May 2012 08:33:36 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Thu, 24 May 2012 08:33:36 -0700 From: "Templin, Fred L" To: Daniel Roesen , "v6ops@ietf.org" , "draft-generic-v6ops-tunmtu@tools.ietf.org" Date: Thu, 24 May 2012 08:33:36 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac05gYWdMn2/RxSQQN+sXlDnnXPjGQAQEVxA Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <20120524074737.GC16448@srv03.cluenet.de> In-Reply-To: <20120524074737.GC16448@srv03.cluenet.de> 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-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 May 2012 15:33:43 -0000 Hi Daniel, Thanks for raising these points, and see below: > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Daniel Roesen > Sent: Thursday, May 24, 2012 12:48 AM > To: v6ops@ietf.org; draft-generic-v6ops-tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > On Wed, May 23, 2012 at 10:57:51AM -0700, Templin, Fred L wrote: > > Yes to the IPv6-in-IPv6 (it's in the draft); not sure > > about the IPv4-in-IPv6. The reason I'm not sure is that > > IPv4 fragmentation and reassembly is a mess and can't > > even be used if the IPv4 packet has DF=3D1. So, I think > > we need some other sort of solution for that. >=20 > The whole DSL (PPPoE session on DSL, with L2TP tunnel backhaul and > wholesale delivery) works on what factually is a tunnel payload MTU of > less than 1500. When used with MSS clamping applied (this is generally > the case - I haven't seen different anywhere yet), this works for > basically almost everyone. About 22 million DSL subscribers in Germany > alone live "happily" with that approach. I don't see why the same > approach doesn't work for DS-Lite too, and field testing for many > months hasn't brought any indication of the contrary. >=20 > Can we pretty please fix DS-Lite too while we're at it (fragment the > payload, not the tunnel, I'd love to be able to fragment the (IPv4) payload, but AFAICT it can't be done with DF=3D1. Are you seeing something I'm not seeing? If not, why not fragment at the tunnel layer - IPv6 fragmentation and reassembly supposedly work. > and apply MSS clamping to avoid unnecessary > in-transit fragmentation) in the spec / by updating the spec? > Operators are asking vendors for that behaviour anyway to have DS-Lite > operationally deployable. Better have it officially specified. AFAICT, MSS clamping is a TCP-only solution. Can we really generalize and say that it will be good enough to standardize for all applications everywhere? Thanks - Fred fred.l.templin@boeing.com > Best regards, > Daniel >=20 > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dr@cluenet.de Thu May 24 09:22:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87E621F85E3 for ; Thu, 24 May 2012 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCcP-8-PiTG6 for ; Thu, 24 May 2012 09:22:08 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB4221F85DF for ; Thu, 24 May 2012 09:22:07 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 0FD3810847E; Thu, 24 May 2012 18:22:06 +0200 (CEST) Date: Thu, 24 May 2012 18:22:06 +0200 From: Daniel Roesen To: v6ops@ietf.org, "draft-generic-v6ops-tunmtu@tools.ietf.org" Message-ID: <20120524162206.GA25325@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "draft-generic-v6ops-tunmtu@tools.ietf.org" References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <20120524074737.GC16448@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 May 2012 16:22:09 -0000 Hi, On Thu, May 24, 2012 at 08:33:36AM -0700, Templin, Fred L wrote: > > Can we pretty please fix DS-Lite too while we're at it (fragment the > > payload, not the tunnel, > > I'd love to be able to fragment the (IPv4) payload, > but AFAICT it can't be done with DF=1. I'm referring only to DF=0. DF=1 needs PMTUD to work, indeed. But that's what all residential DSL deployments I've "seen" do rely on as well. > Are you seeing something I'm not seeing? You mean all the colors that are talking to me? :) > If not, why not fragment at the tunnel layer Performance, security. > AFAICT, MSS clamping is a TCP-only solution. Indeed. > Can we really generalize and say that it will be good > enough to standardize for all applications everywhere? Well, TCP MSS clamping avoids fragmentation/reassembly on DS-Lite AFTR and B4. That avoids the performance impact for DF=0 TCP traffic completely. UDP DF=0 traffic >1460 needs frag/reass still, but that is reasonably seldom that we can probably just live with it (the DSL world does - IPv4 in-transit fragmentation is a basic IPv4 router operation already implemented in CPEs and usually on FPGA/ASIC level on hardware used as large-scale AFTR). PMTUD copes with DF=1 traffic. It's not pretty, but it works "good enough" as proven by a three-digit amount of PPPoE+L2TP residential access lines "out there". We shall not ignore that experience and trying to follow ivory tower approaches that are sexy for purists, but we need to find ways to burry IPv4 with the least cost and risk for all parties involved. Having to do IPv6 reassembly on the AFTR is a significant performance and DoS attack vector. Avoid. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From ietfc@btconnect.com Thu May 24 09:37:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6720C21F8647 for ; Thu, 24 May 2012 09:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1rg0iQ+h-KM for ; Thu, 24 May 2012 09:37:38 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 76C9A21F863E for ; Thu, 24 May 2012 09:37:38 -0700 (PDT) Received: from mail64-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 May 2012 16:37:27 +0000 Received: from mail64-va3 (localhost [127.0.0.1]) by mail64-va3-R.bigfish.com (Postfix) with ESMTP id 99343603FA; Thu, 24 May 2012 16:37:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT008.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: PS-33(zz9371I1be0I542M1432N1418I98dKzz1202hzz8275ch1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3 (MessageSwitch) id 1337877443843844_14940; Thu, 24 May 2012 16:37:23 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.254]) by mail64-va3.bigfish.com (Postfix) with ESMTP id B006F34005C; Thu, 24 May 2012 16:37:23 +0000 (UTC) Received: from DB3PRD0702HT008.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 May 2012 16:37:17 +0000 Received: from CH1PRD0610HT005.namprd06.prod.outlook.com (157.56.244.229) by pod51017.outlook.com (10.3.4.173) with Microsoft SMTP Server (TLS) id 14.15.74.2; Thu, 24 May 2012 16:37:24 +0000 Message-ID: <010a01cd39cb$1adc4540$4001a8c0@gateway.2wire.net> From: t.petch To: MAWATARI Masataka References: <20120518183342kawashimam@mail.jp.nec.com><8F5B353B-D92E-44F8-8211-300C463EB4C3@laposte.net> <20120519112826.C685.8FE1F57E@jpix.ad.jp> Date: Thu, 24 May 2012 17:34:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.244.229] X-OriginatorOrg: btconnect.com Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 May 2012 16:37:39 -0000 I would like to see this published, regardless of status, but to think that it needs more work before it is ready for WGLC. It is just too hard to follow. When I supported its adoption by v6ops, I was expecting that it would be hammered into shape but that has not happened. It contains the detail but lacks the overview - framework, architecture or what, I do not mind, but it is that level of description that it lacks. Rather, the first four sections read like marketing, this is a great idea, you must buy it; err, no, tell me what it is, not the how or why, and I will decide whether or not to buy it. The description only starts at section 5 with a diagram, but this is a diagram that is worth minus one thousand words - if this is 464, then why is the first line a v6 address - that makes it 664! And something you do not explain. The terminology too seems ill-chosen. For example, clauses such as " limited to application that function in a client server model and is not fit for IPv4 peer- to-peer communication or inbound IPv4 connections." does not impart understanding. Of course there is an inbound IPv4 connection, your diagrams all show that. What I reverse-engineer from the I-D, is that the destination IP address used to establish the connection MUST be a global IPv4 address. Which is a much more specific limitation. So let's have an overview in section one and then see if the rest of it still makes sense. Tom Petch ----- Original Message ----- From: "MAWATARI Masataka" To: Cc: Sent: Saturday, May 19, 2012 3:28 AM Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - which status? > Dear Remi-san and all, > > > Thank you for your comments. > > We, 464XLAT co-authors, do not reject the benefit of using NAT44 > with IANA's EUI-64 ID. Please correct this misinterpretation. > > But, we do not understand that you stick with describing only one > model (no dedicated IPv6 prefix model by using NAT44 with IANA's > EUI-64 ID) on 464XLAT document. Sorry, if I'm wrong about this point. > > Excuse me for writing again, 464XLAT co-authors' belief about > describing 2 models on 464XLAT document is as below. > http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html > > Of course, we understood BIH even now. > > > Kind Regards, > Masataka MAWATARI > > > > * On Fri, 18 May 2012 16:03:08 +0200 > * Admin wrote: > > > 18 mai 2012 b11:33, Masanobu Kawashima : > > > > > > > > Hi Remi, > > > > > > Thank you for your comment. > > > > > >> This isn't an answer to my question: "why using the IANA's EUI + > > >> NAT44 model wouldn't work also if DHCPv6 is operational"? > > > > > > I think that it would work even if DHCPv6-PD is operational. > > > However, using the IANA's EUI + NAT44 model does not comply > > > the following part of RFC6145. > > > > > > Quote of section 4.1. in RFC6145. > > > > > > "Translating IPv4 Headers into IPv6 Headers" > > > > > > (snip) > > > > > > Source Address: The IPv4-converted address derived from the IPv4 > > > source address per [RFC6052], Section 2.3. > > > > > > If the translator gets an illegal source address (e.g., 0.0.0.0, > > > 127.0.0.1, etc.), the translator SHOULD silently drop the packet > > > (as discussed in Section 5.3.7 of [RFC1812]). > > > > > > Addition to this, some operators or implementors will choose > > > dedicated IPv6 prefix model in order to avoid operational difficulty > > > and implementation complexity. > > > > Not understood where IANA's CLAT IID would introduce "operational difficulty > > and implementation complexity" (in my understanding, negligible implementation > > difference, and simpler operation with the IANA CLAT IID). > > > > Documenting at least one configuration where you this to apply would be clarifying. > > > > RD > > > > > > > Therefore, we need two models. > > > > > > I prefer simple combination with RFC6145 and RFC6146. > > > That is our essential motivation. > > > > > > Regards, > > > Masanobu > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Fred.L.Templin@boeing.com Thu May 24 10:58:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B189B21F8647 for ; Thu, 24 May 2012 10:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdZPXP0jL-j0 for ; Thu, 24 May 2012 10:58:55 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFBF21F85F7 for ; Thu, 24 May 2012 10:58:55 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4OHwpVP008542 for ; Thu, 24 May 2012 10:58:51 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4OHwoY9008532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 May 2012 10:58:51 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4OHwoxF030862; Thu, 24 May 2012 12:58:50 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4OHwCAQ028354 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 24 May 2012 12:58:50 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Thu, 24 May 2012 10:58:18 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" , "draft-generic-v6ops-tunmtu@tools.ietf.org" Date: Thu, 24 May 2012 10:58:16 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac05gYWdMn2/RxSQQN+sXlDnnXPjGQAQEVxAAAUqt+A= Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <20120524074737.GC16448@srv03.cluenet.de> 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 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 May 2012 17:58:55 -0000 Hi, Since there seemed to be interest in making this even more generic, I took another cut at the document: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ This version now includes considerations for any IP-in-(foo)-in-IP tunnel type (for "foo" as a null or non-null midlayer encapsulation). Any comments? Thanks - Fred fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Thu May 24 11:06:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C8921F85AC for ; Thu, 24 May 2012 11:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWrtxZPYXtCM for ; Thu, 24 May 2012 11:06:20 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 94D5721F84CE for ; Thu, 24 May 2012 11:06:20 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4OI6KpS000358 for ; Thu, 24 May 2012 11:06:20 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4OI6ISP032286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 May 2012 11:06:18 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4OI6HmT026070; Thu, 24 May 2012 13:06:17 -0500 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4OI6HQ6026060 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 24 May 2012 13:06:17 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 24 May 2012 11:06:17 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" , "draft-generic-v6ops-tunmtu@tools.ietf.org" Date: Thu, 24 May 2012 11:06:15 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac05gYWdMn2/RxSQQN+sXlDnnXPjGQAQEVxAAAUqt+AAAEqyMA== Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <20120524074737.GC16448@srv03.cluenet.de> 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 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 May 2012 18:06:21 -0000 Hi, The draft didn't explain this, but bigger-than-1500 packets are caveat emptor. If I as a source send a packet bigger than 1500, then I should be prepared for the possibility that it may be dropped silently. RFC4821 accounts for such cases. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Thursday, May 24, 2012 10:58 AM > To: v6ops@ietf.org; draft-generic-v6ops-tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi, >=20 > Since there seemed to be interest in making this even > more generic, I took another cut at the document: >=20 > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >=20 > This version now includes considerations for any > IP-in-(foo)-in-IP tunnel type (for "foo" as a null > or non-null midlayer encapsulation). Any comments? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marka@isc.org Thu May 24 16:18:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6730111E80B3 for ; Thu, 24 May 2012 16:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiXb6E1B4fZc for ; Thu, 24 May 2012 16:18:14 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCF411E8081 for ; Thu, 24 May 2012 16:18:14 -0700 (PDT) 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 BB7745F9925; Thu, 24 May 2012 23:17:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1557:76a5:95f1:aa90]) (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 F3D70216C3D; Thu, 24 May 2012 23:17: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 E886E20E90A1; Fri, 25 May 2012 09:17:43 +1000 (EST) To: v6ops@ietf.org, "draft-generic-v6ops-tunmtu@tools.ietf.org" From: Mark Andrews References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <20120524074737.GC16448@srv03.cluenet.de> <20120524162206.GA25325@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "draft-generic-v6ops-tunmtu@tools.ietf.org" In-reply-to: Your message of "Thu, 24 May 2012 18:22:06 +0200." <20120524162206.GA25325@srv03.cluenet.de> Date: Fri, 25 May 2012 09:17:43 +1000 Message-Id: <20120524231743.E886E20E90A1@drugs.dv.isc.org> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 May 2012 23:18:15 -0000 In message <20120524162206.GA25325@srv03.cluenet.de>, Daniel Roesen writes: > Hi, > > On Thu, May 24, 2012 at 08:33:36AM -0700, Templin, Fred L wrote: > > > Can we pretty please fix DS-Lite too while we're at it (fragment the > > > payload, not the tunnel, > > > > I'd love to be able to fragment the (IPv4) payload, > > but AFAICT it can't be done with DF=1. > > I'm referring only to DF=0. DF=1 needs PMTUD to work, indeed. But that's > what all residential DSL deployments I've "seen" do rely on as well. IPv4 DF=1 => TCP unless you are broken (Linux/Solaris had/have broken stacks that applied DF=1 to all packets <= interface MTU) or you are doing something special. IPv6 DF=1 for *all* traffic as there is no general router based fragmentation. Unfortunately this really does mean that people running IPv6 networks need to learn and *see* the difference between IPv4 and IPv6 and it doesn't do anyone any long term good hiding that difference. > > Are you seeing something I'm not seeing? > > You mean all the colors that are talking to me? :) > > > If not, why not fragment at the tunnel layer > > Performance, security. > > > AFAICT, MSS clamping is a TCP-only solution. > > Indeed. > > > Can we really generalize and say that it will be good > > enough to standardize for all applications everywhere? > > Well, TCP MSS clamping avoids fragmentation/reassembly on DS-Lite AFTR > and B4. That avoids the performance impact for DF=0 TCP traffic > completely. UDP DF=0 traffic >1460 needs frag/reass still, but that is > reasonably seldom that we can probably just live with it (the DSL world > does - IPv4 in-transit fragmentation is a basic IPv4 router operation > already implemented in CPEs and usually on FPGA/ASIC level on hardware > used as large-scale AFTR). PMTUD copes with DF=1 traffic. > > It's not pretty, but it works "good enough" as proven by a three-digit > amount of PPPoE+L2TP residential access lines "out there". We shall not > ignore that experience and trying to follow ivory tower approaches that > are sexy for purists, but we need to find ways to burry IPv4 with the > least cost and risk for all parties involved. Having to do IPv6 > reassembly on the AFTR is a significant performance and DoS attack > vector. Avoid. > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > 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 washam.fan@gmail.com Thu May 24 19:32:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFFF11E80A3 for ; Thu, 24 May 2012 19:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maefrLtNsfJb for ; Thu, 24 May 2012 19:32:12 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED1F11E8072 for ; Thu, 24 May 2012 19:32:12 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so286014wgb.13 for ; Thu, 24 May 2012 19:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=P5vcDb9iQh3aEnWacwrzH2vhX7IhRhcl7xvTMAv/Aws=; b=WLJ8dWRV3eTduLxvXOGARf0RYVRI35OaFnZZkPq9eVz834UuvDnN7vS9KqRvSrYPKE rkDBcGpr4cP+MLIMVDzUSvC5r63U5bRfk5VMQeE6R6p4fmrdDDV4kGdSsuHJu2Qi7DTI AzodwdqqRDXU1fqzxOAr//V4L+Fw8ws98d/o5ioy3z6C3UwlIU4hygak/6yOGvedCxMZ +jNFQef9AjC38qTCpwRMs6hTRd6TC9o2mHP344NSPNIWRAanaXmIPWTZy2jTZDd2Wqm3 UQRRsFTsjMqfyMBHLaq8NoQPAzJHzd5ruS+S6rTsMCUo6Y9O1mlkgVL5bbGq97GvzqnM R9jw== MIME-Version: 1.0 Received: by 10.180.92.8 with SMTP id ci8mr59337178wib.15.1337913131455; Thu, 24 May 2012 19:32:11 -0700 (PDT) Received: by 10.216.13.193 with HTTP; Thu, 24 May 2012 19:32:11 -0700 (PDT) In-Reply-To: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> Date: Fri, 25 May 2012 10:32:11 +0800 Message-ID: From: Washam Fan To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 May 2012 02:32:13 -0000 Hi Fred, 2012/5/24 Templin, Fred L : > Oh, and another idea; I could make it so that the > tunnel ingress has three "regions" in its MTU > handling: > > =A01) 1280 or smaller are admitted into the tunnel > =A0 =A0 in one piece > =A02) 1281 - 1500 are fragmented into two pieces > =A0 =A0 before admission into the tunnel > =A03) 1501 or larger are admitted into the tunnel > =A0 =A0 in one piece > > Clause 3) is new, and the idea is this. If someone > wants to do 1501 or larger they had better be using > RFC4821 - then, jumboframes are naturally supported. > That ought to help drive RFC4821 deployment! When the tunnel ingress is trying to fragment the larger inner packet, will it also send back ICMP PTB for PMTUD? I don't think it is clarified in the draft. Thanks, washam > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Fri May 25 08:19:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092FD21F8701 for ; Fri, 25 May 2012 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+niWtFVOirw for ; Fri, 25 May 2012 08:19:37 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 85B2721F86FE for ; Fri, 25 May 2012 08:19:37 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4PFJrwA015765 for ; Fri, 25 May 2012 08:19:53 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4PFJq22015757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 May 2012 08:19:53 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4PFJZ83003950; Fri, 25 May 2012 10:19:35 -0500 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4PFJYoM003921 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 25 May 2012 10:19:35 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 25 May 2012 08:19:34 -0700 From: "Templin, Fred L" To: Washam Fan Date: Fri, 25 May 2012 08:19:33 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac06HpqGDdQcCmriReGswY42wO8iFAAalwRg Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 May 2012 15:19:38 -0000 Hi Washam, > When the tunnel ingress is trying to fragment the larger inner packet, > will it also send back ICMP PTB for PMTUD? I don't think it is > clarified in the draft. You're right. I said that in about 50 of my other documents on tunnel PMTUD so forgot to mention it here due to being obvious to me but perhaps not to others. The requirement is, that if the packet is larger than 1500 and is marked "Don't Fragment", the tunnel must drop the packet and send a PTB if it is too big to enter the underlying link in one piece. I'll fix this in the next version. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Washam Fan [mailto:washam.fan@gmail.com] > Sent: Thursday, May 24, 2012 7:32 PM > To: Templin, Fred L > Cc: Fred Baker; draft-generic-v6ops-tunmtu@tools.ietf.org; v6ops@ietf.org > WG > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi Fred, >=20 > 2012/5/24 Templin, Fred L : > > Oh, and another idea; I could make it so that the > > tunnel ingress has three "regions" in its MTU > > handling: > > > > =A01) 1280 or smaller are admitted into the tunnel > > =A0 =A0 in one piece > > =A02) 1281 - 1500 are fragmented into two pieces > > =A0 =A0 before admission into the tunnel > > =A03) 1501 or larger are admitted into the tunnel > > =A0 =A0 in one piece > > > > Clause 3) is new, and the idea is this. If someone > > wants to do 1501 or larger they had better be using > > RFC4821 - then, jumboframes are naturally supported. > > That ought to help drive RFC4821 deployment! >=20 > When the tunnel ingress is trying to fragment the larger inner packet, > will it also send back ICMP PTB for PMTUD? I don't think it is > clarified in the draft. >=20 > Thanks, > washam > > Thanks - Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From mawatari@jpix.ad.jp Mon May 28 21:50:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E5921F86D1 for ; Mon, 28 May 2012 21:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 Kn0lo102zoo5 for ; Mon, 28 May 2012 21:50:09 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 466D921F8691 for ; Mon, 28 May 2012 21:50:05 -0700 (PDT) Received: from [192.168.0.230] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 3E387FC021 for ; Tue, 29 May 2012 13:50:04 +0900 (JST) Date: Tue, 29 May 2012 13:50:03 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: <813FF89D-FBAF-4634-BF35-E6021D1777E0@laposte.net> References: <20120518183342kawashimam@mail.jp.nec.com> <813FF89D-FBAF-4634-BF35-E6021D1777E0@laposte.net> Message-Id: <20120529135003.FB9C.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 May 2012 04:50:10 -0000 Dear Remi-san and all, We appreciate your every comments about 464XLAT. We will add that the CLAT on 464XLAT architecture does not comply with "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix." that is described on Section 3.3. in RFC 6052. And about document's category, we do not care about the document's category as we have told once. The reason that we changed category from Informational to BCP is due to v6ops chairs' suggestion. If v6ops chairs say a request to change from BCP to Informational, we will defer to that. In case of keeping present category, although we don't know whether you are going to like or not, we would like to propose you. What do you think about splitting text of "no dedicated IPv6 prefix model by using NAT44 with IANA's EUI-64 ID" for mobile service (3G, LTE, etc.) that does not utilize DHCPv6-PD yet and "dedicated IPv6 prefix model" for wireline service that utilize DHCPv6-PD as a convenient function. This text is completely splitted by service applicability (moblie and wireline). This is hard to cause some confusions in audiences of 464XLAT document. We really understood your thoughts, we can save operation and deployment cost for IPv4 long-life support by using dedicated IPv6 prefix. This is a antinomy between dedicated IPv6 prefix is required and not required. We understood this. So we are thinking that we would like to describe the 2 models. Kind Regards, Masataka MAWATARI * On Sat, 19 May 2012 09:32:33 +0200 * Admin wrote: > Masanobu-san, > > Thank you for the explanation below. > Formally, you are right: RFC6145 doesn't cover the case where there is only one IPv4 address on the IPv4 side, and where therefore a fixed IPv6 address, non IPv4 translated, can be used. > > OTOH, RFC 6052 says, about Stateless translation "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix". Using different IPv6 prefixes for customer-side and Internbet-side IPv4 addresses would introduce an exception to this rule, with the need to explain. > > The IANA EUI-64 interface ID remains IMHO worth using, at least when CLAT nodes contain NAT44s. > > Regards, > RD From mawatari@jpix.ad.jp Mon May 28 21:55:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1287821F86FC for ; Mon, 28 May 2012 21:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 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, J_CHICKENPOX_15=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 5u7PeSKYeNQq for ; Mon, 28 May 2012 21:54:59 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1212B21F8691 for ; Mon, 28 May 2012 21:54:59 -0700 (PDT) Received: from [192.168.0.230] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 97478FC021; Tue, 29 May 2012 13:54:58 +0900 (JST) Date: Tue, 29 May 2012 13:54:58 +0900 From: MAWATARI Masataka To: ietfc@btconnect.com In-Reply-To: <010a01cd39cb$1adc4540$4001a8c0@gateway.2wire.net> References: <20120519112826.C685.8FE1F57E@jpix.ad.jp> <010a01cd39cb$1adc4540$4001a8c0@gateway.2wire.net> Message-Id: <20120529135457.FBA0.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 May 2012 04:55:00 -0000 Dear Tom-san, Thank you for your comments. I understood your thoughts. I will polish again the diagram on Section 5 and the overview by adding the explanations. The IPv6 host on the diagram on Section 5.1 shows that a IPv6 host can reach the other IPv6 hosts on the Internet via no translation. This means that the CPE can not only have the function of CLAT but also the function of IPv6 native router for IPv6 native traffic. And the 464XLAT architecture provides limited IPv4 service as you understand. This is true due to hub-and-spoke model using stateful translation. Kind Regards, Masataka MAWATARI * On Thu, 24 May 2012 17:34:22 +0100 * t.petch wrote: > I would like to see this published, regardless of status, but to think > that it needs more work before it is ready for WGLC. It is just too > hard to follow. When I supported its adoption by v6ops, I was expecting > that it would be hammered into shape but that has not happened. > > It contains the detail but lacks the overview - framework, architecture > or what, I do not mind, but it is that level of description that it > lacks. Rather, the first four sections read like marketing, this is a > great idea, you must buy it; err, no, tell me what it is, not the how or > why, and I will decide whether or not to buy it. > > The description only starts at section 5 with a diagram, but this is a > diagram that is worth minus one thousand words - if this is 464, then > why is the first line a v6 address - that makes it 664! And something > you do not explain. > > The terminology too seems ill-chosen. For example, clauses such as > " limited to application > that function in a client server model and is not fit for IPv4 peer- > to-peer communication or inbound IPv4 connections." > does not impart understanding. Of course there is an inbound IPv4 > connection, your diagrams all show that. What I reverse-engineer from > the I-D, is that the destination IP address used to establish the > connection MUST be a global IPv4 address. Which is a much more specific > limitation. > > So let's have an overview in section one and then see if the rest of it > still makes sense. > > > Tom Petch From iesg-secretary@ietf.org Tue May 29 07:39:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FC221F8710; Tue, 29 May 2012 07:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.49 X-Spam-Level: X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrP7jIn5PEFA; Tue, 29 May 2012 07:39:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36A721F86F0; Tue, 29 May 2012 07:39:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2012 07:39:00 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 14:39:01 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ballot/ No IPR declarations have been submitted directly on this I-D. From despres.remi@laposte.net Tue May 29 08:13:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A8911E808C for ; Tue, 29 May 2012 08:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dEX7BFo-2wv for ; Tue, 29 May 2012 08:13:13 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C311E808A for ; Tue, 29 May 2012 08:13:12 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id 549F170000A0; Tue, 29 May 2012 17:13:11 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id C84F9700009C; Tue, 29 May 2012 17:13:10 +0200 (CEST) X-SFR-UUID: 20120529151310820.C84F9700009C@msfrf2316.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120529135003.FB9C.8FE1F57E@jpix.ad.jp> Date: Tue, 29 May 2012 17:13:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EB230CF-31E4-4676-9B62-1373E77C71B3@laposte.net> References: <20120518183342kawashimam@mail.jp.nec.com> <813FF89D-FBAF-4634-BF35-E6021D1777E0@laposte.net> <20120529135003.FB9C.8FE1F57E@jpix.ad.jp> To: MAWATARI Masataka X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 May 2012 15:13:14 -0000 Masataka-san, Please see inline. 2012-05-29 06:50, MAWATARI Masataka: > Dear Remi-san and all, >=20 >=20 > We appreciate your every comments about 464XLAT. >=20 > We will add that the CLAT on 464XLAT architecture does not comply > with "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 > addresses SHOULD use the same prefix." that is described on Section > 3.3. in RFC 6052. >=20 > And about document's category, we do not care about the document's > category as we have told once. The reason that we changed category > from Informational to BCP is due to v6ops chairs' suggestion. If > v6ops chairs say a request to change from BCP to Informational, we > will defer to that. I don't expect the chair would object to your returning to the status = you originally proposed, especially since it permits document = publication without careful comparison with alternative designs = discussed in Softwires. Your announcing that you plan to re-issue the document as Informational = would therefore be appreciated. AFAIAC, it would close this thread of discussion once and for all. Besides, if BCP remains the target, I agree with Tom Petch that = substantial clarification would be needed (overview, framework, = architecture, whatever better describes applicability).=20 > In case of keeping present category, although we don't know whether > you are going to like or not, we would like to propose you. >=20 > What do you think about splitting text of "no dedicated IPv6 prefix > model by using NAT44 with IANA's EUI-64 ID" for mobile service (3G, > LTE, etc.) that does not utilize DHCPv6-PD yet and "dedicated IPv6 > prefix model" for wireline service that utilize DHCPv6-PD as a > convenient function. >=20 > This text is completely splitted by service applicability (moblie > and wireline). This is hard to cause some confusions in audiences > of 464XLAT document. >=20 > We really understood your thoughts, we can save operation and > deployment cost for IPv4 long-life support by using dedicated IPv6 > prefix. >=20 > This is a antinomy between dedicated IPv6 prefix is required and > not required. We understood this. So we are thinking that we > would like to describe the 2 models. In the wireline case with an ISP NAT64, I don't see why CLAT-CPEs = couldn't work like mobile CLATs, i.e. with NAT44 in CLAT node.=20 It seems you have in mind something I couldn't get from the draft or = from given explanations. Regards, RD >=20 >=20 > Kind Regards, > Masataka MAWATARI >=20 >=20 > * On Sat, 19 May 2012 09:32:33 +0200 > * Admin wrote: >=20 >> Masanobu-san, >>=20 >> Thank you for the explanation below. >> Formally, you are right: RFC6145 doesn't cover the case where there = is only one IPv4 address on the IPv4 side, and where therefore a fixed = IPv6 address, non IPv4 translated, can be used. >>=20 >> OTOH, RFC 6052 says, about Stateless translation "Both = IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses = SHOULD use the same prefix". Using different IPv6 prefixes for = customer-side and Internbet-side IPv4 addresses would introduce an = exception to this rule, with the need to explain. >>=20 >> The IANA EUI-64 interface ID remains IMHO worth using, at least when = CLAT nodes contain NAT44s. >>=20 >> Regards, >> RD >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rja.lists@gmail.com Tue May 29 09:38:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E2521F871C; Tue, 29 May 2012 09:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTFUPwKX6zqz; Tue, 29 May 2012 09:38:09 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C79AA21F8714; Tue, 29 May 2012 09:38:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3115642vbb.31 for ; Tue, 29 May 2012 09:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=i41KrFM7W48ASgsd/mhyzOSt/X+Y5a/T8Pb2jeBEIc0=; b=oj9cc+SqVCEf3PCcafhB+Sj13uc/rMuv8uRG7KVHq48inIhwkcxQsAHGNghSOzIVAY Hxp+0hnkeSJoB5xbTeQYstWtP8RoKom97/4UmFqqliLgYgNLpu8VX/66jXdkjOrTwoCK CCX+nXzWc/skrL3Q1/ijy+NDkvIqMPojCfJW9JTQpXbcuBX3AetSpxCZRq3+TMd7xrQq 47dTrP3FrYiaKz2PfM3lEDjnorPcmFzIRvoriVfsvhhvHregYwNC9GSD1YquK+i3mC8Y 5YbLfLdNIZ5o3Zje1IGsFgMvNuNGkXx5+CG4LZA5Q3HyJ9FODh6kywKYO4eeu6T2DbbZ 4gYg== Received: by 10.52.174.52 with SMTP id bp20mr11366120vdc.29.1338309488306; Tue, 29 May 2012 09:38:08 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id s10sm21350938vdg.10.2012.05.29.09.38.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 09:38:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: RJ Atkinson In-Reply-To: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2012 12:38:05 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 May 2012 16:38:10 -0000 On 29 May 2012, at 10:39 , The IESG wrote: > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)' > as Best Current > Practice While I generally support publication of this document, there is a blocking issue that ought to be resolved prior to publication. 1) Layer-2 Processing Rule causes valid IPv6 packets to be dropped MULTIPLE ISSUES: Rule #4 in this document is overly restrictive. Implementing this rule has the effect of changing the IPv6 specifications to prohibit otherwise legitimate packets that violate this new and somewhat arbitrary rule, which is an unreasonable change. In effect, this cure (i.e. Rule 4) is worse operationally than the potential disease. This rule can cause entirely legitimate IPv6 packets to be dropped, neither because they are invalid, nor because those packets violate IPv6 specifications, nor because their header chain is too long (from a specification & legitimacy perspective), nor because they are security risks. Instead, such packets are dropped because a Layer-2 device lacks sufficient information to perform a Layer-3 function (i.e. packet parsing/inspection). Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are commonly, correctly, and legitimately used to interconnect different segments of the same IPv6 subnetwork. So a Layer-2 device cannot know whether a particular RA Advertisement is valid or not -- that information is simply not available at Layer-2 in a dependable way. Absent manual configuration that tells the Layer-2 device which ports might connect to routers, the Layer-2 device separately cannot know which "ports ... are not allowed to send ICMPv6 Router Advertisement messages". Separately, in a network that contains wireless elements, routers might connect to different Layer-2 base stations at different times. In turn, those different Layer-2 base stations are very likely to connect to different Layer-2 ports on different Layer-2 switches/bridges. Such Layer-2 switches/bridges generally cannot know that a wireless aspect exists in the deployment. So this is another reason that a Layer-2 only device is not the correct place to be trying to filter ICMPv6 RA packets. Removing this rule creates no new security risk as the any actual problem packet can be detected and dropped later -- either by an IPv6-capable router or an IPv6-capable firewall -- one that is located at an IPv6 subnetwork boundary. There are existing openly specified, legitimate, IPv6 Destination Options that can be somewhat large in size (notably: CALIPSO). While such packets are not common, they are entirely legitimate and valid. A BCP from an operationally focused WG ought not be recommending that valid IPv6 packets be dropped, as this will impede deployment of IPv6. PROPOSED ACTION: The current Rule #4 should be have its meaning inverted (i.e. If a Layer-2 device is unable to identify whether the packet is an ICMPv6 Router Advertisement, then the packet should be transmitted without modification) and text referring to that rule also should be edited heavily to outline the issues noted above as the reason for the "transmit if in doubt" policy for a Layer-2 device. OBSERVATION: The only fully secure networks are those that move no packets at all. So our goal ought not be a "fully secure" network. Instead, the goal should be taking reasonable, practical steps to reduce operational risks to an acceptable level -- while allowing all valid IPv6 packets to use the network. Yours, Ran From jouni.nospam@gmail.com Tue May 29 12:13:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4463F11E8085 for ; Tue, 29 May 2012 12:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmImyzLzzutE for ; Tue, 29 May 2012 12:13:34 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2011E8074 for ; Tue, 29 May 2012 12:13:34 -0700 (PDT) Received: by bkty8 with SMTP id y8so4187722bkt.31 for ; Tue, 29 May 2012 12:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kFRNsttDZceJMcyaRJLj6Jl0qoEbDIJXeGuwa1GgMLo=; b=x1p5/nSGnmlhD7RdAG7GuDXHji/mZhF3soReKBsQxqiNXdb/MrykCSoWCbbYgOgAkL V5ziD+0GPjuPWVi0sz2GmNMiGvBfOJ4cfdFRZTnimw1mNVwd8OW+lrjM9uGY1YBY5GX7 CFnblHD5zqhxiAk4UXHTidd9mxW1if010aCiKZhOAjGWD6XFr8aHSGxthp2rvV+HmEue 32e6/+22T867A1Zy709lqgm0Jk1HN81xVXYstbvlIY3zjcecjlpIrZZkIvSqbXY3l1tJ HK9JlA/I3pMCBis3nVBYUNB1IxUJQ2kJNQUickugDa6HVXnFmgg9UM4mZzOA80b84jZ3 /CcQ== Received: by 10.205.128.3 with SMTP id hc3mr7119232bkc.29.1338318813165; Tue, 29 May 2012 12:13:33 -0700 (PDT) Received: from a88-114-71-183.elisa-laajakaista.fi (a88-114-71-183.elisa-laajakaista.fi. [88.114.71.183]) by mx.google.com with ESMTPS id u8sm19411088bks.0.2012.05.29.12.13.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 12:13:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20120529135003.FB9C.8FE1F57E@jpix.ad.jp> Date: Tue, 29 May 2012 22:13:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D5AC90B-4DCC-4B22-A0C2-54C1FD5ADCDE@gmail.com> References: <20120518183342kawashimam@mail.jp.nec.com> <813FF89D-FBAF-4634-BF35-E6021D1777E0@laposte.net> <20120529135003.FB9C.8FE1F57E@jpix.ad.jp> To: MAWATARI Masataka X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 May 2012 19:13:35 -0000 Hi, One comment below. On May 29, 2012, at 7:50 AM, MAWATARI Masataka wrote: > Dear Remi-san and all, >=20 >=20 > We appreciate your every comments about 464XLAT. >=20 > We will add that the CLAT on 464XLAT architecture does not comply > with "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 > addresses SHOULD use the same prefix." that is described on Section > 3.3. in RFC 6052. >=20 > And about document's category, we do not care about the document's > category as we have told once. The reason that we changed category > from Informational to BCP is due to v6ops chairs' suggestion. If > v6ops chairs say a request to change from BCP to Informational, we > will defer to that. >=20 > In case of keeping present category, although we don't know whether > you are going to like or not, we would like to propose you. >=20 > What do you think about splitting text of "no dedicated IPv6 prefix > model by using NAT44 with IANA's EUI-64 ID" for mobile service (3G, > LTE, etc.) that does not utilize DHCPv6-PD yet and "dedicated IPv6 > prefix model" for wireline service that utilize DHCPv6-PD as a > convenient function. For the latter I do not think the text needs to explicitly state that the dedicated prefix model is for wireline service. Just saying it applies for any service that utilizes DHCPv6-PD should suffice. - Jouni >=20 > This text is completely splitted by service applicability (moblie > and wireline). This is hard to cause some confusions in audiences > of 464XLAT document. >=20 > We really understood your thoughts, we can save operation and > deployment cost for IPv4 long-life support by using dedicated IPv6 > prefix. >=20 > This is a antinomy between dedicated IPv6 prefix is required and > not required. We understood this. So we are thinking that we > would like to describe the 2 models. >=20 >=20 > Kind Regards, > Masataka MAWATARI >=20 >=20 > * On Sat, 19 May 2012 09:32:33 +0200 > * Admin wrote: >=20 >> Masanobu-san, >>=20 >> Thank you for the explanation below. >> Formally, you are right: RFC6145 doesn't cover the case where there = is only one IPv4 address on the IPv4 side, and where therefore a fixed = IPv6 address, non IPv4 translated, can be used. >>=20 >> OTOH, RFC 6052 says, about Stateless translation "Both = IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses = SHOULD use the same prefix". Using different IPv6 prefixes for = customer-side and Internbet-side IPv4 addresses would introduce an = exception to this rule, with the need to explain. >>=20 >> The IANA EUI-64 interface ID remains IMHO worth using, at least when = CLAT nodes contain NAT44s. >>=20 >> Regards, >> RD >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fernando.gont.netbook.win@gmail.com Tue May 29 13:22:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB51511E8106 for ; Tue, 29 May 2012 13:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUDBIEt-qbE1 for ; Tue, 29 May 2012 13:22:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0611E80DC for ; Tue, 29 May 2012 13:22:05 -0700 (PDT) Received: by yenq13 with SMTP id q13so2898328yen.31 for ; Tue, 29 May 2012 13:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=j+NVwl1pSyBv2esZonvueBGA6TwE1hsokSi2NoNvPx8=; b=bkz4qC7NRVFIUTs1XfV7o8t15zu2+Xmty/rpHPBdHgIVnscKvFAFXFOLYizA0edJ1F 34siozwoe1r9lRcsEbyeXf43Q1cPDPsgAvjkW9wWCFShfVY/wrEVl8/xElKybhEUGxJl nQHbwOvgGAWbB6lRfrr9vpQWZOMUezlFISH5n8BWpufybFr37k8wtNI4GDkcSezRynZB rw7YWQA77mHE5IllACQYeAJ/RQOGNUJ6MFon58ZdhZ9+UUlH6K8GcjjNQOp3r64b+UKz awsiCxxTHooX4iwJtAumKn4GQkZc7lvwceHDxJHezcg56jTj2Ah3P2mtTAesbP+vwZNb Eo2A== Received: by 10.236.76.233 with SMTP id b69mr12849719yhe.52.1338322925164; Tue, 29 May 2012 13:22:05 -0700 (PDT) Received: from [192.168.123.103] ([186.134.30.55]) by mx.google.com with ESMTPS id a13sm21308546anm.5.2012.05.29.13.22.02 (version=SSLv3 cipher=OTHER); Tue, 29 May 2012 13:22:04 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FC52FD3.9060206@gont.com.ar> Date: Tue, 29 May 2012 17:21:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> In-Reply-To: <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 May 2012 20:22:06 -0000 Hi, Ran, Thanks so much for your comments! Meta-answer: This document is a BCP on how to implement RA-Guard, *not* a BCP that RA-Guard should be deployed. -- i.e., we're not saying whether you should or should not deploy ra-guard, but rather "if you implement ra-guard, you should do it this way". -- I'm just double-checking that this is the angle from which you've read the document... More comments inline... On 05/29/2012 01:38 PM, RJ Atkinson wrote: > 1) Layer-2 Processing Rule causes valid IPv6 packets to be dropped > > MULTIPLE ISSUES: > > Rule #4 in this document is overly restrictive. Implementing > this rule has the effect of changing the IPv6 specifications > to prohibit otherwise legitimate packets that violate this new > and somewhat arbitrary rule, which is an unreasonable change. > In effect, this cure (i.e. Rule 4) is worse operationally than > the potential disease. To some extent, RA-Guard does firewalling at layer-2. This means that, as with stateless filtering, there's a point at which you need to draw a line that says what you consider acceptable, and what not... and as with layer-3 stateless firewalls, there is (at leasttheoretically speaking) a risk of false positives. If those false positives outweigh the benefits of firewalling in the first place, you simply do not deploy the firewall (or in this case, RA-Guard) (more comments below) > Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are > commonly, correctly, and legitimately used to interconnect different > segments of the same IPv6 subnetwork. So a Layer-2 device cannot > know whether a particular RA Advertisement is valid or not -- that > information is simply not available at Layer-2 in a dependable way. I those scenarios, you either manually configure every layer-2 device in an appropriate way, or you simply do not deploy ra-guard. > Absent manual configuration that tells the Layer-2 device which ports > might connect to routers, the Layer-2 device separately cannot know > which "ports ... are not allowed to send ICMPv6 Router Advertisement > messages". Exactly. You should manually configure the device with this information, *and* you should manually enable ra-guard. > Separately, in a network that contains wireless elements, routers > might connect to different Layer-2 base stations at different times. > In turn, those different Layer-2 base stations are very likely to > connect to different Layer-2 ports on different Layer-2 switches/bridges. > Such Layer-2 switches/bridges generally cannot know that a wireless > aspect exists in the deployment. So this is another reason that a > Layer-2 only device is not the correct place to be trying to filter > ICMPv6 RA packets. In those scenarios, you'd simply not deploy ra-guard. As noted at the beginning of this e-mail, my take is that you assume that we're encouraging ra-guard deployment for the general case, But this document simply specifies how you should *implement* ra-guard, and doesn't argue in favor (or against) its deployment. > Removing this rule creates no new security risk as the any actual > problem packet can be detected and dropped later -- either by an > IPv6-capable router or an IPv6-capable firewall -- one that is > located at an IPv6 subnetwork boundary. How would you block malicious RAs originating from the local subnetwork? > There are existing openly specified, legitimate, IPv6 Destination > Options that can be somewhat large in size (notably: CALIPSO). My take is that if you setup employs CALIPSO, and it leads to packets with a header chain that spans multiple local MTUs, then you'd simply not deploy RA-Guard. That say, would CALIPSO packets really lead to IPv6 header chains that would span past 1500 bytes, or even past 1280 bytes? > PROPOSED ACTION: > > The current Rule #4 should be have its meaning inverted (i.e. If a > Layer-2 device is unable to identify whether the packet is an ICMPv6 > Router Advertisement, then the packet should be transmitted without > modification) and text referring to that rule also should be edited > heavily to outline the issues noted above as the reason for the > "transmit if in doubt" policy for a Layer-2 device. As noted above, this document just specifies how to implement RA-Guard, When it comes to actual deployment, there are may be trade-offs (as discussed above). But if you do decide to deploy RA-Guard, you probably do not want a "default allow" rule (because attackers would certainly use any of the evasion techniques described in the document)... Please do let me know what you think... Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rja.lists@gmail.com Tue May 29 18:02:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDF521F8716 for ; Tue, 29 May 2012 18:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNJo4VTsP6Bh for ; Tue, 29 May 2012 18:02:39 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6113121F8712 for ; Tue, 29 May 2012 18:02:39 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2940480vcq.31 for ; Tue, 29 May 2012 18:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=a/xtvlOEWlXPY/HOJsyWLMLRjn+i22EFvEy6zBDw5vA=; b=ia4MMMPb56l6uQ3iii63nB8xvP1WJcdZLCkDJ13NcyybJGteF5Ed+82joTXMjGE2x2 WBo6ROfnm9bdMn0+TLZoui4NM0+SZDvEBo9EoxzDUBmsdYUJIzEH9nsPAFFHBZK/BcXA tFszzkluTgIwK7k/FhygZc403lQEXmFf1MvAagbnrbB8OolcYPFOljg4nZH0ga2kiBsC lXdDvKLLTxTboCsKAKiCWiGgwSa4tTC8xjOFJEznoT8KucXUFNUVvoKRn8SGEBa2xRAW VyfuOX5LsPXOxA3czQcThHgzLnYJy4BE7Sl3KDHPcX0DChxVJmH+BNIvQ+dk0fI21B1T CJNg== Received: by 10.52.155.193 with SMTP id vy1mr12660621vdb.123.1338339758403; Tue, 29 May 2012 18:02:38 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id t15sm27116565vdj.3.2012.05.29.18.02.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 18:02:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: RJ Atkinson In-Reply-To: <4FC52FD3.9060206@gont.com.ar> Date: Tue, 29 May 2012 21:02:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1278) Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 01:02:41 -0000 On 29 May 2012, at 16:21 , Fernando Gont wrote: > Meta-answer: This document is a BCP on how to implement RA-Guard, = *not* > a BCP that RA-Guard should be deployed. -- i.e., we're not saying > whether you should or should not deploy ra-guard, but rather "if you > implement ra-guard, you should do it this way". >=20 > -- I'm just double-checking that this is the angle from which you've > read the document... Yes. If a Layer-2 device that implements the RA Guard feature is unable=20= to discern whether a packet contains an RA or not -- then that device=20 ought to bridge/transmit the uncertain packet rather than drop it. > On 05/29/2012 01:38 PM, RJ Atkinson wrote: >> 1) Layer-2 Processing Rule causes valid IPv6 packets to be dropped >>=20 >> MULTIPLE ISSUES: >>=20 >> Rule #4 in this document is overly restrictive. Implementing >> this rule has the effect of changing the IPv6 specifications >> to prohibit otherwise legitimate packets that violate this new >> and somewhat arbitrary rule, which is an unreasonable change. =20 >> In effect, this cure (i.e. Rule 4) is worse operationally than=20 >> the potential disease. >=20 > To some extent, RA-Guard does firewalling at layer-2. No. It doesn't. If one wants to raise the issue of options, optional headers, and fragmentation, then one really really has some Layer-3 capabilities -- or ought to. > This means that,as with stateless filtering, there's a point at which = you > need to draw a line that says what you consider acceptable, and what = not... > and as with layer-3 stateless firewalls, there is (at least = theoretically > speaking) a risk of false positives. If those false positives outweigh = the > benefits of firewalling in the first place, you simply do not deploy = the firewall > (or in this case, RA-Guard) Not a good comparison. Many stateless firewalls that are widely=20 deployed transmit uncertain packets, rather than dropping them. Separately, folks do NOT want IPv6 to be broken and balkanised in the way that IPv4 was. This spec can be fixed. The earlier note described a simple and sufficient fix. >> Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are=20= >> commonly, correctly, and legitimately used to interconnect different=20= >> segments of the same IPv6 subnetwork. So a Layer-2 device cannot=20 >> know whether a particular RA Advertisement is valid or not -- that=20= >> information is simply not available at Layer-2 in a dependable way. >=20 > I those scenarios, you either manually configure every layer-2 device = in > an appropriate way, or you simply do not deploy ra-guard. That doesn't work, as I noted in the original post. >> Absent manual configuration that tells the Layer-2 device which = ports >> might connect to routers, the Layer-2 device separately cannot know >> which "ports ... are not allowed to send ICMPv6 Router Advertisement >> messages". =20 >=20 > Exactly. You should manually configure the device with this = information, > *and* you should manually enable ra-guard. However, this document doesn't require that such implementations even possess the capability of being configured with that data. So again, not a good reason. >> Separately, in a network that contains wireless elements, routers >> might connect to different Layer-2 base stations at different times. >> In turn, those different Layer-2 base stations are very likely to=20 >> connect to different Layer-2 ports on different Layer-2 = switches/bridges. >> Such Layer-2 switches/bridges generally cannot know that a wireless >> aspect exists in the deployment. So this is another reason that a >> Layer-2 only device is not the correct place to be trying to filter >> ICMPv6 RA packets. >=20 > In those scenarios, you'd simply not deploy ra-guard. That is not noted in Security Considerations for this document. > As noted at the beginning of this e-mail, my take is that you assume > that we're encouraging ra-guard deployment for the general case, No I don't.=20 > But this document simply specifies how you should *implement* = ra-guard, and > doesn't argue in favor (or against) its deployment. The proposed implementation is broken. It requires that RA-Guard implementations drop completely valid non-RA IPv6 packets in some=20 situations. >> Removing this rule creates no new security risk as the any actual >> problem packet can be detected and dropped later -- either by an=20 >> IPv6-capable router or an IPv6-capable firewall -- one that is=20 >> located at an IPv6 subnetwork boundary. >=20 > How would you block malicious RAs originating from the local = subnetwork? With a real RA Guard, implemented properly, that knows it is dropping packets that (1) contain an RA message type and (2) are invalid. The problem is with your concept of a Layer-2 only device that is an RA Guard. The functions needed to make a correct determination about packets aren't available in (most, all) Layer-2-only devices. Devices that implement RA Guard need to have at least sufficient=20 Layer-3 capabilities to distinguish RA packets from non-RA packets. With such correct implementations, Rule 4 being inverted is a hop. With incorrect implementations, Rule 4 being inverted ensures that valid IPv6 packets are not dropped. >> PROPOSED ACTION: >>=20 >> The current Rule #4 should be have its meaning inverted (i.e. If a >> Layer-2 device is unable to identify whether the packet is an ICMPv6 >> Router Advertisement, then the packet should be transmitted without >> modification) and text referring to that rule also should be edited=20= >> heavily to outline the issues noted above as the reason for the >> "transmit if in doubt" policy for a Layer-2 device. >=20 > As noted above, this document just specifies how to implement = RA-Guard, ...which specification is incomplete or wrong, as I noted in my previous note. > When it comes to actual deployment, there are may be trade-offs (as > discussed above). But if you do decide to deploy RA-Guard, you = probably > do not want a "default allow" rule (because attackers would certainly > use any of the evasion techniques described in the document)... (ASIDE: "Security Considerations" needs more specific and detailed=20 discussion of those deployment and operational trade-offs than it has at present.) I know of lots of folks who'd be interested in RA-Guard, if the=20 specification weren't broken in a way that can cause valid IPv6 packets=20= that are not RA packets to be dropped. So they would prefer the=20 inversion of Rule 4. One of the main advantages of IPv6 is that it is not currently broken by lots of mis-specified (pseudo-)security devices. Please change this document so that it won't cause valid IPv6 non-RA packets to be dropped. Please don't break IPv6. Yours, Ran From internet-drafts@ietf.org Tue May 29 19:12:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2EB11E80B8; Tue, 29 May 2012 19:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkWv8qfCmruC; Tue, 29 May 2012 19:12:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785CA11E8093; Tue, 29 May 2012 19:12:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120530021215.6434.68998.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2012 19:12:15 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-wireline-incremental-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, 30 May 2012 02:12: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 : Wireline Incremental IPv6 Author(s) : Victor Kuarsingh Lee Howard Filename : draft-ietf-v6ops-wireline-incremental-ipv6-04.txt Pages : 28 Date : 2012-05-29 Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-i= pv6-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-ip= v6-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ From fgont@si6networks.com Tue May 29 23:56:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCEF11E8076 for ; Tue, 29 May 2012 23:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=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 gAli42zfo2Df for ; Tue, 29 May 2012 23:56:58 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 54D5221F8704 for ; Tue, 29 May 2012 23:56:57 -0700 (PDT) Received: from [190.50.173.210] (helo=[192.168.1.42]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZcpv-0007zv-Tn; Wed, 30 May 2012 08:56:56 +0200 Message-ID: <4FC5B638.5000809@si6networks.com> Date: Wed, 30 May 2012 02:55:04 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Fernando Gont Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 06:56:59 -0000 Hi, Ran, On 05/29/2012 10:02 PM, RJ Atkinson wrote: >> -- I'm just double-checking that this is the angle from which you've >> read the document... > > Yes. If a Layer-2 device that implements the RA Guard feature is unable > to discern whether a packet contains an RA or not -- then that device > ought to bridge/transmit the uncertain packet rather than drop it. But that would essentially break RA-Guard's ability of mitigating RA-based attacks... >> To some extent, RA-Guard does firewalling at layer-2. > > No. It doesn't. If one wants to raise the issue of options, > optional headers, and fragmentation, then one really really > has some Layer-3 capabilities -- or ought to. Well, strictly speaking, one already needs some layer-3 capabilities just to parse the layer-3 header... >> This means that,as with stateless filtering, there's a point at which you >> need to draw a line that says what you consider acceptable, and what not... >> and as with layer-3 stateless firewalls, there is (at least theoretically >> speaking) a risk of false positives. If those false positives outweigh the >> benefits of firewalling in the first place, you simply do not deploy the firewall >> (or in this case, RA-Guard) > > Not a good comparison. Many stateless firewalls that are widely > deployed transmit uncertain packets, rather than dropping them. I didn't say "*all* stateless firewalls". That aside, I'm generally of the idea that if you do deploy a firewall, you should do "default deny" (rather than 'default allow'). > Separately, folks do NOT want IPv6 to be broken and balkanised > in the way that IPv4 was. This spec can be fixed. The earlier > note described a simple and sufficient fix. People are already filtering stuff in v6. From ICMPv6, to unrecognized extension headers. Packets in which the IPv6 header chain spans multiple fragments already break things such as state-less translators (which, given the level of v6 deployment, we should expect to be able to live with for quite some time). That aside, since they would essentially make state-less filtering impossible, I really doubt you can assume that they will pass stateless filters. While, packets in which the IPv6 header chain spans multiple packets are, strictly speaking, legitimate, I wonder whether this was actually intended. -- Recent discussions regarding the IPv6 MTU seem to indicate that the magic number '1280' came up from expecting the full IPv6 packet (plus outer headers for tunnels) to fit within the the common 1500-byte MTU. For instance, if the IPv6 header chain spans multiple packets, you end up having more than 50% overhead... >>> Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are >>> commonly, correctly, and legitimately used to interconnect different >>> segments of the same IPv6 subnetwork. So a Layer-2 device cannot >>> know whether a particular RA Advertisement is valid or not -- that >>> information is simply not available at Layer-2 in a dependable way. >> >> I those scenarios, you either manually configure every layer-2 device in >> an appropriate way, or you simply do not deploy ra-guard. > > That doesn't work, as I noted in the original post. Not sure what you mean. You can deploy RA-Guard only in those scenarios in which you know that the router will be connected to a specific layer-2 port (such that you can configure the layer-2 device to allow RAs only on that port). If, for some reason, you cannot tell beforehand on which layer-2 port you will connect your local router, then RA-Guard is not appropriate for your scenario, and you shouldn't deploy/enable it. >> Exactly. You should manually configure the device with this information, >> *and* you should manually enable ra-guard. > > However, this document doesn't require that such implementations > even possess the capability of being configured with that data. > So again, not a good reason. Well, I assumed this to be a 'requirement' ("implication", if you want) from RFC 6105. But I agree that we might need to make this explicit in this document -- I'd also have no problem with adding that the RA-Guard feature should be 'off' by default, too. >>> Separately, in a network that contains wireless elements, routers >>> might connect to different Layer-2 base stations at different times. >>> In turn, those different Layer-2 base stations are very likely to >>> connect to different Layer-2 ports on different Layer-2 switches/bridges. >>> Such Layer-2 switches/bridges generally cannot know that a wireless >>> aspect exists in the deployment. So this is another reason that a >>> Layer-2 only device is not the correct place to be trying to filter >>> ICMPv6 RA packets. >> >> In those scenarios, you'd simply not deploy ra-guard. > > That is not noted in Security Considerations for this document. Good point. I'll craft some text about this, and post it for review... >> But this document simply specifies how you should *implement* ra-guard, and >> doesn't argue in favor (or against) its deployment. > > The proposed implementation is broken. It requires that RA-Guard > implementations drop completely valid non-RA IPv6 packets in some > situations. There's certainly a possibility of false positives (for instance, this is already noted in the document). However, that's the trade-off for being able to prevent RA-based attacks. And it's something that you deploy in your local network -- not some filter that you deploy in the middle of the network. >>> Removing this rule creates no new security risk as the any actual >>> problem packet can be detected and dropped later -- either by an >>> IPv6-capable router or an IPv6-capable firewall -- one that is >>> located at an IPv6 subnetwork boundary. >> >> How would you block malicious RAs originating from the local subnetwork? > > With a real RA Guard, implemented properly, that knows it is dropping > packets that (1) contain an RA message type and (2) are invalid. Then you wouldn't block them. I'd just add multiple extension headers, and fragment the resulting packet... > The problem is with your concept of a Layer-2 only device that > is an RA Guard. The functions needed to make a correct determination > about packets aren't available in (most, all) Layer-2-only devices. > > Devices that implement RA Guard need to have at least sufficient > Layer-3 capabilities to distinguish RA packets from non-RA packets. The only way to do RA-Guard with zero possibility of false positives is to have the ra-guard device implement layer-3 reassembly. But since RAs are supposed to operate on a subnet, such devices is not supposed to be there, and hence such approach wouldn't be purist, either. > With such correct implementations, Rule 4 being inverted is a hop. If it's a hop, then you should decrement the Hop Limit. And the RA would be discarded (since the Hop LImit would not be 255, as currently required). > I know of lots of folks who'd be interested in RA-Guard, if the > specification weren't broken in a way that can cause valid IPv6 packets > that are not RA packets to be dropped. So they would prefer the > inversion of Rule 4. We essentially have to options here: 1) Have RA-Guard be effective to mitigate RA-based attacks, accepting the fact that there's a possibility for false positives. 2) Have RA-Guard have a "default allow" policy, at which point it becomes useless for mitigating RA-based attacks. I have no problem with elaborating on the issue of false positives, and being more explicit about considerations that should be made when enabling RA-guard. But specifying a "security" devices that cannot handle well-known evasion techniques (for which there are even publicly available tools) doesn't seem to make much sense. Regarding false positives: Do you have any estimates regarding how large e.g. CALIPSO options could be in practice? > One of the main advantages of IPv6 is that it is not currently broken > by lots of mis-specified (pseudo-)security devices. Well, strictly speaking, you're right: it is broken by mis-behaving(?) devices. ICMPv6 is reportedly broken, and devices are already filtering unrecognized headers. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marc.lampo@eurid.eu Wed May 30 00:34:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA3121F86F8 for ; Wed, 30 May 2012 00:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAxDA1w8Sfx4 for ; Wed, 30 May 2012 00:34:29 -0700 (PDT) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id CBBFE21F86F7 for ; Wed, 30 May 2012 00:34:27 -0700 (PDT) X-ASG-Debug-ID: 1338363266-02dadd0667384bc0001-b2NLKh Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id iHUAsPvkHxZSe4ua; Wed, 30 May 2012 09:34:26 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 02EC7E4059; Wed, 30 May 2012 09:34:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Augue8s4P84M; Wed, 30 May 2012 09:34:25 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id E2E14E4050; Wed, 30 May 2012 09:34:25 +0200 (CEST) From: "Marc Lampo" To: "'RJ Atkinson'" , "'Fernando Gont'" References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> In-Reply-To: Date: Wed, 30 May 2012 09:34:25 +0200 (CEST) X-ASG-Orig-Subj: RE: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice Message-ID: <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac09/+YZ5pymZ19jSr2iiaO2JIzI1wANaQMw Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.121] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1338363266 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 07:34:29 -0000 Hello, Just focussing on this rule #4 : Seems to me that packets that would match this rule might be theoretically valid, but in practice : questionable/dubious packets. If a packet is constructed is such a way that, before the end of the first fragment is reached, one cannot determine if it is a RA, I do have my questions about the nature (malicious ?) of this packet. Compare it to IPv4 "options" : I always configured my routers to drop IPv4 packets that had any options. Not needed for any "production traffic". (unfortunately, such a simple solution does not exist, for IPv6 ...) (out of scope for this document, but in reply to statement made) About IPv6 not being broken by security devices : I wonder how many security devices actually implement some kind of security for IPv6 and if, to what extend. Fact is that most vendors I had contact with claim to support IPv6, but when starting to ask some further questions, it is usually "back to some guru in the back office", with usually a "not yet" response afterwards. Kind regards, Marc Lampo Security Officer EURid -----Original Message----- From: RJ Atkinson [mailto:rja.lists@gmail.com] Sent: 30 May 2012 03:03 AM To: Fernando Gont Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice ... I know of lots of folks who'd be interested in RA-Guard, if the specification weren't broken in a way that can cause valid IPv6 packets that are not RA packets to be dropped. So they would prefer the inversion of Rule 4. One of the main advantages of IPv6 is that it is not currently broken by lots of mis-specified (pseudo-)security devices. Please change this document so that it won't cause valid IPv6 non-RA packets to be dropped. Please don't break IPv6. Yours, Ran From v6ops@globis.net Wed May 30 01:16:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899CD21F86F7 for ; Wed, 30 May 2012 01:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRee2bq1ED1f for ; Wed, 30 May 2012 01:16:18 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 84BF721F868A for ; Wed, 30 May 2012 01:16:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id F41138700B3; Wed, 30 May 2012 10:16:15 +0200 (CEST) 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 Q8AaEpH0YxaT; Wed, 30 May 2012 10:16:06 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 760CF870070; Wed, 30 May 2012 10:16:06 +0200 (CEST) Message-ID: <4FC5D745.4080203@globis.net> Date: Wed, 30 May 2012 10:16:05 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Fernando Gont References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> In-Reply-To: <4FC52FD3.9060206@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, RJ Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 08:16:19 -0000 +1 Agree with Fernando. Disagree with Ran. I don't agree that this is a blocking factor, and believed the WG had reached rough consensus. IMHO Initially, I was also concerned about false-positives, but after careful consideration I believe that if someone has chosen to implement RA Guard then the benefit of day 0 attack protection from false-negatives is worth far more than the downside of potentially dropping some false-positive link-local-only ICMPv6 packets. Operational experience has proven a "drop unknown by default" rule to be necessary: the reason this ID was written was because previous RA-Guard implementations which only filtered on positive identification were being bypassed in the wild. Flipping the default behaviour to "allow unknown by default" as Ran suggests, would IMVHO require tightening up the spec for an RA message so that they could always be 100% reliably parsed in all instances (including end host implementations) for RA Guard to remain useful, but that is outside the scope of the ID and would also limit future developments. If as an end user you don't like this compromise, don't buy a L2 switch that implements RA-Guard. Or turn it off globally. Or configure the port to be a router port (that allows all messages). regards, RayH Fernando Gont wrote: > Hi, Ran, > > Thanks so much for your comments! > > Meta-answer: This document is a BCP on how to implement RA-Guard, *not* > a BCP that RA-Guard should be deployed. -- i.e., we're not saying > whether you should or should not deploy ra-guard, but rather "if you > implement ra-guard, you should do it this way". > > -- I'm just double-checking that this is the angle from which you've > read the document... > > More comments inline... > > On 05/29/2012 01:38 PM, RJ Atkinson wrote: >> 1) Layer-2 Processing Rule causes valid IPv6 packets to be dropped >> >> MULTIPLE ISSUES: >> >> Rule #4 in this document is overly restrictive. Implementing >> this rule has the effect of changing the IPv6 specifications >> to prohibit otherwise legitimate packets that violate this new >> and somewhat arbitrary rule, which is an unreasonable change. >> In effect, this cure (i.e. Rule 4) is worse operationally than >> the potential disease. > > To some extent, RA-Guard does firewalling at layer-2. This means that, > as with stateless filtering, there's a point at which you need to draw a > line that says what you consider acceptable, and what not... and as with > layer-3 stateless firewalls, there is (at leasttheoretically speaking) a > risk of false positives. If those false positives outweigh the benefits > of firewalling in the first place, you simply do not deploy the firewall > (or in this case, RA-Guard) > > (more comments below) > > >> Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are >> commonly, correctly, and legitimately used to interconnect different >> segments of the same IPv6 subnetwork. So a Layer-2 device cannot >> know whether a particular RA Advertisement is valid or not -- that >> information is simply not available at Layer-2 in a dependable way. > > I those scenarios, you either manually configure every layer-2 device in > an appropriate way, or you simply do not deploy ra-guard. > > >> Absent manual configuration that tells the Layer-2 device which ports >> might connect to routers, the Layer-2 device separately cannot know >> which "ports ... are not allowed to send ICMPv6 Router Advertisement >> messages". > > Exactly. You should manually configure the device with this information, > *and* you should manually enable ra-guard. > > >> Separately, in a network that contains wireless elements, routers >> might connect to different Layer-2 base stations at different times. >> In turn, those different Layer-2 base stations are very likely to >> connect to different Layer-2 ports on different Layer-2 switches/bridges. >> Such Layer-2 switches/bridges generally cannot know that a wireless >> aspect exists in the deployment. So this is another reason that a >> Layer-2 only device is not the correct place to be trying to filter >> ICMPv6 RA packets. > > In those scenarios, you'd simply not deploy ra-guard. > > As noted at the beginning of this e-mail, my take is that you assume > that we're encouraging ra-guard deployment for the general case, But > this document simply specifies how you should *implement* ra-guard, and > doesn't argue in favor (or against) its deployment. > > >> Removing this rule creates no new security risk as the any actual >> problem packet can be detected and dropped later -- either by an >> IPv6-capable router or an IPv6-capable firewall -- one that is >> located at an IPv6 subnetwork boundary. > > How would you block malicious RAs originating from the local subnetwork? > > > >> There are existing openly specified, legitimate, IPv6 Destination >> Options that can be somewhat large in size (notably: CALIPSO). > > My take is that if you setup employs CALIPSO, and it leads to packets > with a header chain that spans multiple local MTUs, then you'd simply > not deploy RA-Guard. > > That say, would CALIPSO packets really lead to IPv6 header chains that > would span past 1500 bytes, or even past 1280 bytes? > > >> PROPOSED ACTION: >> >> The current Rule #4 should be have its meaning inverted (i.e. If a >> Layer-2 device is unable to identify whether the packet is an ICMPv6 >> Router Advertisement, then the packet should be transmitted without >> modification) and text referring to that rule also should be edited >> heavily to outline the issues noted above as the reason for the >> "transmit if in doubt" policy for a Layer-2 device. > > As noted above, this document just specifies how to implement RA-Guard, > When it comes to actual deployment, there are may be trade-offs (as > discussed above). But if you do decide to deploy RA-Guard, you probably > do not want a "default allow" rule (because attackers would certainly > use any of the evasion techniques described in the document)... > > Please do let me know what you think... > > Cheers, From washam.fan@gmail.com Wed May 30 01:39:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461B521F86FC for ; Wed, 30 May 2012 01:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFrPb3plI+Or for ; Wed, 30 May 2012 01:39:09 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id E705021F86B5 for ; Wed, 30 May 2012 01:39:08 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so3026154wgb.1 for ; Wed, 30 May 2012 01:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fsZ0KFeTKHRvADQUDaZaLiOy1CrQjdXK7zwlMGQ5MHU=; b=T+RsCl6ASltp3nxea7yM2p/CGU4ii+teztjNhYcmKZt0mWS/Wj8S8osUL6QCnOA5AU DNOsK+Zaojl5MpYku/Dxz/r0/eR8RzyNf5FssFEGcRHZ7oLcxrt7Du83BHdVK3SgfjOK QEuAaUV4OE+yQTi4lO83zXWlWRKOAq33jC/56zUwAWb+jPrNBfRwn/gBg4qJDS9n6yFc gNwbGO7UQ43ZTfB7vZlfFoU7WRW0C9uHXnsruTc+hOo1FnIiRhR5FlOqc7RC/90MRrOS hGkBxejAUIrbsXipzd5Hu9/WSNf+hyj7AGo4kBT99YtU9XU0y4Wdz0Cj031FWIqISilf i87A== MIME-Version: 1.0 Received: by 10.216.202.14 with SMTP id c14mr10603452weo.63.1338367146951; Wed, 30 May 2012 01:39:06 -0700 (PDT) Received: by 10.216.241.15 with HTTP; Wed, 30 May 2012 01:39:06 -0700 (PDT) In-Reply-To: <4FC5D745.4080203@globis.net> References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> <4FC5D745.4080203@globis.net> Date: Wed, 30 May 2012 16:39:06 +0800 Message-ID: From: Washam Fan To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, RJ Atkinson , Fernando Gont Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 08:39:10 -0000 Hi, There is definitely theoretically false positives. But the possibility should be very slim if rule 1-3 has been passed. Please note that only if pass the previous 3 rules, the rule #4 would apply. Thanks, washam 2012/5/30 Ray Hunter : > +1 Agree with Fernando. Disagree with Ran. I don't agree that this is a > blocking factor, and believed the WG had reached rough consensus. > > IMHO Initially, I was also concerned about false-positives, but after > careful consideration I believe that if someone has chosen to implement R= A > Guard then the benefit of day 0 attack protection from false-negatives is > worth far more than the downside of potentially dropping some false-posit= ive > link-local-only ICMPv6 packets. > > Operational experience has proven a "drop unknown by default" rule to be > necessary: the reason this ID was written was because previous RA-Guard > implementations which only filtered on positive identification were being > bypassed in the wild. > > Flipping the default behaviour to "allow unknown by default" as Ran > suggests, would IMVHO require tightening up the spec for an RA message so > that they could always be 100% reliably parsed in all instances (includin= g > end host implementations) for RA Guard to remain useful, but that is outs= ide > the scope of the ID and would also limit future developments. > > If as an end user you don't like this compromise, don't buy a L2 switch t= hat > implements RA-Guard. Or turn it off globally. Or configure the port to be= a > router port (that allows all messages). > > regards, > RayH > > Fernando Gont wrote: >> >> Hi, Ran, >> >> Thanks so much for your comments! >> >> Meta-answer: This document is a BCP on how to implement RA-Guard, *not* >> a BCP that RA-Guard should be deployed. -- i.e., we're not saying >> whether you should or should not deploy ra-guard, but rather "if you >> implement ra-guard, you should do it this way". >> >> -- I'm just double-checking that this is the angle from which you've >> read the document... >> >> More comments inline... >> >> On 05/29/2012 01:38 PM, RJ Atkinson wrote: >>> >>> 1) Layer-2 Processing Rule causes valid IPv6 packets to be dropped >>> >>> =A0 MULTIPLE ISSUES: >>> >>> =A0 Rule #4 in this document is overly restrictive. =A0Implementing >>> =A0 this rule has the effect of changing the IPv6 specifications >>> =A0 to prohibit otherwise legitimate packets that violate this new >>> =A0 and somewhat arbitrary rule, which is an unreasonable change. >>> =A0 In effect, this cure (i.e. Rule 4) is worse operationally than >>> =A0 the potential disease. >> >> >> To some extent, RA-Guard does firewalling at layer-2. This means that, >> as with stateless filtering, there's a point at which you need to draw a >> line that says what you consider acceptable, and what not... and as with >> layer-3 stateless firewalls, there is (at leasttheoretically speaking) a >> risk of false positives. If those false positives outweigh the benefits >> of firewalling in the first place, you simply do not deploy the firewall >> (or in this case, RA-Guard) >> >> (more comments below) >> >> >>> =A0 Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are >>> =A0 commonly, correctly, and legitimately used to interconnect differen= t >>> =A0 segments of the same IPv6 subnetwork. =A0So a Layer-2 device cannot >>> =A0 know whether a particular RA Advertisement is valid or not -- that >>> =A0 information is simply not available at Layer-2 in a dependable way. >> >> >> I those scenarios, you either manually configure every layer-2 device in >> an appropriate way, or you simply do not deploy ra-guard. >> >> >>> =A0 Absent manual configuration that tells the Layer-2 device which por= ts >>> =A0 might connect to routers, the Layer-2 device separately cannot know >>> =A0 which "ports ... are not allowed to send ICMPv6 Router Advertisemen= t >>> =A0 messages". >> >> >> Exactly. You should manually configure the device with this information, >> *and* you should manually enable ra-guard. >> >> >>> =A0 Separately, in a network that contains wireless elements, routers >>> =A0 might connect to different Layer-2 base stations at different times= . >>> =A0 In turn, those different Layer-2 base stations are very likely to >>> =A0 connect to different Layer-2 ports on different Layer-2 >>> switches/bridges. >>> =A0 Such Layer-2 switches/bridges generally cannot know that a wireless >>> =A0 aspect exists in the deployment. =A0So this is another reason that = a >>> =A0 Layer-2 only device is not the correct place to be trying to filter >>> =A0 ICMPv6 RA packets. >> >> >> In those scenarios, you'd simply not deploy ra-guard. >> >> As noted at the beginning of this e-mail, my take is that you assume >> that we're encouraging ra-guard deployment for the general case, But >> this document simply specifies how you should *implement* ra-guard, and >> doesn't argue in favor (or against) its deployment. >> >> >>> =A0 Removing this rule creates no new security risk as the any actual >>> =A0 problem packet can be detected and dropped later -- either by an >>> =A0 IPv6-capable router or an IPv6-capable firewall -- one that is >>> =A0 located at an IPv6 subnetwork boundary. >> >> >> How would you block malicious RAs originating from the local subnetwork? >> >> >> >>> =A0 There are existing openly specified, legitimate, IPv6 Destination >>> =A0 Options that can be somewhat large in size (notably: CALIPSO). >> >> >> My take is that if you setup employs CALIPSO, and it leads to packets >> with a header chain that spans multiple local MTUs, then you'd simply >> not deploy RA-Guard. >> >> That say, would CALIPSO packets really lead to IPv6 header chains that >> would span past 1500 bytes, or even past 1280 bytes? >> >> >>> =A0 PROPOSED ACTION: >>> >>> =A0 The current Rule #4 should be have its meaning inverted (i.e. If a >>> =A0 Layer-2 device is unable to identify whether the packet is an ICMPv= 6 >>> =A0 Router Advertisement, then the packet should be transmitted without >>> =A0 modification) and text referring to that rule also should be edited >>> =A0 heavily to outline the issues noted above as the reason for the >>> =A0 "transmit if in doubt" policy for a Layer-2 device. >> >> >> As noted above, this document just specifies how to implement RA-Guard, >> When it comes to actual deployment, there are may be trade-offs (as >> discussed above). But if you do decide to deploy RA-Guard, you probably >> do not want a "default allow" rule (because attackers would certainly >> use any of the evasion techniques described in the document)... >> >> Please do let me know what you think... >> >> Cheers, > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wesley.george@twcable.com Wed May 30 09:29:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115C821F85CC for ; Wed, 30 May 2012 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDyNQc33aTbD for ; Wed, 30 May 2012 09:29:35 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 74BAB21F85C7 for ; Wed, 30 May 2012 09:29:35 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,685,1330923600"; d="scan'208";a="387932599" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 30 May 2012 12:28:58 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 30 May 2012 12:29:34 -0400 From: "George, Wes" To: Marc Lampo , 'RJ Atkinson' , 'Fernando Gont' Date: Wed, 30 May 2012 12:29:33 -0400 Thread-Topic: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice Thread-Index: Ac09/+YZ5pymZ19jSr2iiaO2JIzI1wANaQMwABI2LVA= Message-ID: References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu> In-Reply-To: <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 16:29:36 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Marc Lampo > Sent: Wednesday, May 30, 2012 3:34 AM > > > Compare it to IPv4 "options" : I always configured my routers to drop > IPv4 packets that had any options. Not needed for any "production traffi= c". > (unfortunately, such a simple solution does not exist, for IPv6 ...) [WEG] I think there's a point of clarification here that makes this an inva= lid comparison. There's a very big difference between telling your router t= o *ignore* any IP Options it sees in packets going through the box (e.g. pr= ocess/forward the packet as normal, but without taking any actions manipula= ted by the options) and in telling it to actually drop the packets altogeth= er, either in general for all traffic through the box, or more specifically= on "for us" packets destined for the router's control plane. "ip options ignore" in Cisco parlance does the former, not the latter, main= ly to prevent packets from being sent to the punt path and creating a DoS a= ttack vector. Indiscriminately Blocking/dropping packets with options conf= igured is not a good idea unless you are operating a device whose position = in the network means that you will definitely know whether or not there are= any legitimate uses of options on the traffic traversing the device. Unles= s you have a very tight control on all of the uses of the network such that= you know exactly what the traffic does and does not look like, making assu= mptions like that tend to get us into situations like we find ourselves in = with legitimate ICMPv4 traffic being blocked by overzealous security admins= . A recommendation in a BCP can't assume that much about the network, and t= herefore must be very careful in covering this in its recommendations. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jmh@joelhalpern.com Wed May 30 09:41:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3678C11E8086 for ; Wed, 30 May 2012 09:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBP8QhNmIPgg for ; Wed, 30 May 2012 09:41:03 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D602821F8438 for ; Wed, 30 May 2012 09:41:03 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C9424557FB8 for ; Wed, 30 May 2012 09:41:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7CDF71BC98E0; Wed, 30 May 2012 09:41:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.110] (pool-71-161-51-212.clppva.btas.verizon.net [71.161.51.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CE5DD1BCDDB0; Wed, 30 May 2012 09:41:02 -0700 (PDT) Message-ID: <4FC64D8A.2020302@joelhalpern.com> Date: Wed, 30 May 2012 12:40:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: 'Fernando Gont' References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 16:41:04 -0000 I do see the importance of being apply to apply RAGuard in a device which does not accumulate fragment state. (I don't want to try to analyze the potential DoS attack of having such state.) However, the proposal introduces a network limtiation, essentially a protocol change, in the network. I did not think v6Ops was free to recommend behaviors (dropping unclassifiable fragments) which basically violate the base IPv6 spec. It seems that the right answer was discussed much earlier, namely changing the protocol behavior (a 6man activity) to tell hosts to reject RA and ND packets which were received in fragments. If that is the right answer, then we have to be very careful about creating long-lived restrictions as a remediation until such a solution can be adopted. Yours, Joel From rbonica@juniper.net Wed May 30 12:33:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C55D11E8115 for ; Wed, 30 May 2012 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.135 X-Spam-Level: X-Spam-Status: No, score=-106.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIIuVsRVbhJz for ; Wed, 30 May 2012 12:33:44 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0447511E8095 for ; Wed, 30 May 2012 12:33:39 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT8Z2E1wfLI96mUt2Y3lS8XCg8SnrUywU@postini.com; Wed, 30 May 2012 12:33:43 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 30 May 2012 12:32:53 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 30 May 2012 15:32:52 -0400 From: Ronald Bonica To: "Joel M. Halpern" , 'Fernando Gont' Date: Wed, 30 May 2012 15:32:51 -0400 Thread-Topic: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice Thread-Index: Ac0+gwoMVEm2LQA3Q1qLNs2r2W5m+AAFnHNQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D76C387C2C@EMBX01-WF.jnpr.net> References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu> <4FC64D8A.2020302@joelhalpern.com> In-Reply-To: <4FC64D8A.2020302@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 19:33:44 -0000 Joel, On the one hand, I don't think that v6ops is overstepping its charter. It i= sn't modifying IPv6. It is merely identifying a combination of IPv6 feature= s that might spell trouble used in the same datagram.=20 On the other hand, I would be thrilled if the 6man WG would update RFC 4443= to say something like "ICMPv6 packets MUST NOT be fragmented unless the IC= MPv6 Type, Code and Checksum all fit in the first fragment". Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Joel M. Halpern > Sent: Wednesday, May 30, 2012 12:41 PM > To: 'Fernando Gont' > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implementation-04.txt> (Implementation Advice for IPv6 Router > Advertisement Guard (RA-Guard)) to Best Current Practice >=20 > I do see the importance of being apply to apply RAGuard in a device > which does not accumulate fragment state. (I don't want to try to > analyze the potential DoS attack of having such state.) >=20 > However, the proposal introduces a network limtiation, essentially a > protocol change, in the network. I did not think v6Ops was free to > recommend behaviors (dropping unclassifiable fragments) which basically > violate the base IPv6 spec. >=20 > It seems that the right answer was discussed much earlier, namely > changing the protocol behavior (a 6man activity) to tell hosts to > reject RA and ND packets which were received in fragments. >=20 > If that is the right answer, then we have to be very careful about > creating long-lived restrictions as a remediation until such a solution > can be adopted. >=20 > Yours, > Joel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fgont@si6networks.com Wed May 30 12:39:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A1B11E8137 for ; Wed, 30 May 2012 12:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZPAPT6PEl+V for ; Wed, 30 May 2012 12:39:01 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 48DC211E8147 for ; Wed, 30 May 2012 12:39:01 -0700 (PDT) Received: from [181.29.110.67] (helo=[192.168.2.182]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZojP-0005rx-Ln; Wed, 30 May 2012 21:38:56 +0200 Message-ID: <4FC67749.8030309@si6networks.com> Date: Wed, 30 May 2012 16:38:49 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Joel M. Halpern" References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu> <4FC64D8A.2020302@joelhalpern.com> In-Reply-To: <4FC64D8A.2020302@joelhalpern.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , 'Fernando Gont' Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 19:39:01 -0000 On 05/30/2012 01:40 PM, Joel M. Halpern wrote: > However, the proposal introduces a network limtiation, essentially a > protocol change, in the network. It's not a protocol change, but an operational mitigation. -- for instance, there is no change in the way the sending router or the receiving hosts process RAs. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Wed May 30 14:00:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08C611E809C for ; Wed, 30 May 2012 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZITNj5aSSAmo for ; Wed, 30 May 2012 14:00:00 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1016C11E8088 for ; Wed, 30 May 2012 13:59:59 -0700 (PDT) Received: by vcqp1 with SMTP id p1so195924vcq.31 for ; Wed, 30 May 2012 13:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=Qo7XmZMLJwBDf02NqT1wArzh5kxEqBP1IX8tx69C/rM=; b=a3W1CkxWc0kZeIdsjiVjMrltH2k/2rglBK+cP+ho6ith2csNAZ0fR5ZvDthhKVySXr IgwpgZlMsu8lnYwimDx5Z3QU05TwLBrKxXn/ES/A/XEE5vbTS6INy6U9d+W6ru9Wpf7H ZmmkfRrKURXp4A/M6aCzixF1mHK/nO603LFuiHPeBU2z3pjvHn3WUFBl2XqTvaoOQTAd Qw4/h/zo2Rq6xTkgahnNJUPDWHHblnajTz6lnOzn6eg+725h31xHfF4xtpH1p0kw3lH8 KQLncGCV8AHk1V5/ixH5eSs1aiDVFM4Qd4Hn2H+Mtehi7CRxplr3FqFWa/qP1eFukKcm zY9g== Received: by 10.220.115.81 with SMTP id h17mr7737436vcq.66.1338411599419; Wed, 30 May 2012 13:59:59 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id o15sm1328396vdi.15.2012.05.30.13.59.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 May 2012 13:59:58 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 May 2012 16:59:56 -0400 Message-Id: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 21:00:00 -0000 Earlier, Joel Halpern wrote: > It seems that the right answer was discussed much earlier, namely > changing the protocol behavior (a 6man activity) to tell hosts to > reject RA and ND packets which were received in fragments. Earlier, Ron Bonica wrote: > I would be thrilled if the 6man WG would update RFC 4443 to say = something like: > "ICMPv6 packets MUST NOT be fragmented unless the ICMPv6 Type, Code, = and Checksum=20 > all fit in the first fragment". I support Joel and Ron in this. =20 A better approach for the RA Guard document would be: 1) to put together a separate I-D for 6MAN that says approximately=20 the above (and explains why). There is probably a little text clarifying that any host receiving an RA that did not comply with the proposed new rule above MUST be dropped by that receiving host. One imagines this would not be controversial within 6MAN and could=20 proceed quickly. If it were controversial there, that would=20 tend to indicate a significant problem with the current RA Guard = text. This would be a more comprehensive protection. Ultimately, the risk of unauthorised RA messages is a risk to the hosts, so host IPv6 implementers have strong incentive to update their stacks quickly=20 once the IPv6 specifications are updated accordingly. =20 2) in parallel with (1), revise the RA Guard I-D to either delete "Rule 4" (e.g. citing the proposed new rule above) or invert the meaning of Rule 4. Either way, the objective would be that all=20 valid IPv6 packets are passed by an RA Guard all the time. Yours, Ran PS: It seems to me that the V6 OPS WG ought not be recommending=20 behaviours that violate the IPv6 specifications. Instead,=20 if situations arise where V6 OPS thinks the specified behaviour=20 is either wrong or incompletely described, then someone should=20 propose an IPv6 specification update/edit/correction to the 6MAN = WG. From rja.lists@gmail.com Wed May 30 14:09:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE1221F8671 for ; Wed, 30 May 2012 14:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHIfOPBmNkuh for ; Wed, 30 May 2012 14:09:08 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1918C21F8663 for ; Wed, 30 May 2012 14:09:08 -0700 (PDT) Received: by vcqp1 with SMTP id p1so201994vcq.31 for ; Wed, 30 May 2012 14:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=+M5zo/uPw/lJncisQI6gPXDQJpDmH6brgF3l/Rke4cs=; b=KvFUXKPrHb3UqrD2NNqZDWG9oejeBgO+elo8ywTOBixCYDq9FscUtuP03h2scd3SGU TDvEnD5G2pttadh/DETV0nnsZciB8BLbiHOYSY2DeUP6lN0Qh8HRfh2m3K5GeTdQ0jJ1 R0yMPiIjHrOn8vBU4Q6ddwse7YswOS6lIPg3cdq2/dQ25lmfAp+1gtGiVkDbdDDnW4Ar I0Ul+tyDd/3xF/EV5Ess9uEv+d6GVQFfh7WhvgoIZzu5pk03l8lNhAt8G+j4pdmLkklb DNozjT5AGUKfejpep89VlWczLwmlCjI7tsL/P1FvdrtgVkxQvFM9BqPvo8Mh1ozfHAcp g8yw== Received: by 10.220.209.72 with SMTP id gf8mr18748361vcb.72.1338412147268; Wed, 30 May 2012 14:09:07 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id g10sm1395847vdk.2.2012.05.30.14.09.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 May 2012 14:09:06 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 May 2012 17:09:05 -0400 Message-Id: <1F73F9FE-9BA5-4506-A5FB-AE09C1C18626@gmail.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 21:09:08 -0000 Fernando wrote: > It's not a protocol change, Nonsense. > but an operational mitigation. -- for instance, there is no change > in the way the sending router or the receiving hosts process RAs. Rule 4 mandates changes to whether certain IPv6 packets get forwarded, which is a major change to the IPv6 protocol specifications. Rule 4 is both a protocol change and (misguided) operational mitigation. Rule 4 is mandatory according to this document and will cause certain perfectly valid IPv6 packets to be dropped instead of forwarded. The rule damages IPv6 and impairs utility of IPv6 in the real world. The comprehensive fix is to update the hosts as Joel Halpern and Ron Bonica outlined earlier today. I don't think that change would be controversial, so likely it could proceed quickly through 6MAN. In the meantime, Rule 4 could be edited and cleaned up such that no valid IPv6 packets get dropped by an RA Guard. Yours, Ran From ran.atkinson@gmail.com Wed May 30 14:05:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BD21F865F for ; Wed, 30 May 2012 14:05:46 -0700 (PDT) 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=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oGbhMWtT5wT for ; Wed, 30 May 2012 14:05:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84721F85CD for ; Wed, 30 May 2012 14:05:46 -0700 (PDT) Received: by vcqp1 with SMTP id p1so199795vcq.31 for ; Wed, 30 May 2012 14:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=v+j1vEuqgJDXxkW6G4pDBKStRsmAmi6SWbR47pOgwQs=; b=TQXng2M1pSQlx9oiWCSqn80IQFziLn27jmTJB4xTJkUBLQS74/pgdAxISZtDx5tW2s XRIRBblS9+ffzU4ArqkUO/Q+uVidDMJPl16OHu5Lmuc/pAY6HaEQCzizh3JQTNoX0rUN GvJqgyiRV8hsDYAmadAwz7nJoenuGVAFadZh7jvIfNFAgTm9SJY2iJdYmRE1Lk7tSD/8 71VFGwjjFShIQsP2FLR7mMXdFKW9qs5hZLIBxFFNlgboYB/xvDRH9DgUvNkKkBMOLTIT /es9W+Fwj1RboPFMDxlt6zEsaDd81mief5XJdGChZq/x37KxT+csa7UCUkmaeF/hL8wz vqNA== Received: by 10.220.119.147 with SMTP id z19mr18647848vcq.15.1338411945827; Wed, 30 May 2012 14:05:45 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id bv19sm1342885vdc.19.2012.05.30.14.05.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 May 2012 14:05:45 -0700 (PDT) From: Ran Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 May 2012 17:05:43 -0400 Message-Id: <07004891-BB63-4D5A-B858-1069B97CD47F@gmail.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Wed, 30 May 2012 14:21:43 -0700 Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 21:05:47 -0000 Fernando wrote: > It's not a protocol change, but an operational mitigation. -- for > instance, there is no change in the way the sending router or the > receiving hosts process RAs. Nonsense. Rule 4 mandates changes to whether certain IPv6 packets get forwarded, which is a major change to the IPv6 protocol specifications. Rule 4 is both a protocol change and (misguided) operational mitigation. Rule 4 is mandatory according to this document and will cause certain perfectly valid IPv6 packets to be dropped instead of forwarded. The rule damages IPv6 and impairs utility of IPv6 in the real world. The comprehensive fix is to update the hosts as Joel Halpern and Ron Bonica outlined earlier today. I don't think that change would be controversial, so likely it could proceed quickly through 6MAN. In the meantime, Rule 4 could be edited and cleaned up such that no valid IPv6 packets get dropped by an RA Guard. Yours, Ran From joelja@bogus.com Wed May 30 14:55:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A739D1F0C5D for ; Wed, 30 May 2012 14:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSManoUna2fw for ; Wed, 30 May 2012 14:55:33 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2090D1F0C5C for ; Wed, 30 May 2012 14:55:33 -0700 (PDT) Received: from Joels-MacBook-Pro.local (218.sub-166-250-46.myvzw.com [166.250.46.218]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q4ULtQK3079343 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 30 May 2012 21:55:26 GMT (envelope-from joelja@bogus.com) Message-ID: <4FC69747.3090209@bogus.com> Date: Wed, 30 May 2012 14:55:19 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ronald Bonica References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu> <4FC64D8A.2020302@joelhalpern.com> <13205C286662DE4387D9AF3AC30EF456D76C387C2C@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76C387C2C@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 30 May 2012 21:55:28 +0000 (UTC) Cc: "v6ops@ietf.org" , 'Fernando Gont' Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 21:55:33 -0000 On 5/30/12 12:32 , Ronald Bonica wrote: > Joel, > > On the one hand, I don't think that v6ops is overstepping its > charter. It isn't modifying IPv6. It is merely identifying a > combination of IPv6 features that might spell trouble used in the > same datagram. It's saying that that packets matching the criterion should be discarded in order to protect yourself from damage. That is to my mind a fairly operational recommendation. > On the other hand, I would be thrilled if the 6man WG would update > RFC 4443 to say something like "ICMPv6 packets MUST NOT be fragmented > unless the ICMPv6 Type, Code and Checksum all fit in the first > fragment". +1 > Ron > > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: >> Wednesday, May 30, 2012 12:41 PM To: 'Fernando Gont' Cc: >> v6ops@ietf.org Subject: Re: [v6ops] Last Call: >> (Implementation >> Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best >> Current Practice >> >> I do see the importance of being apply to apply RAGuard in a >> device which does not accumulate fragment state. (I don't want to >> try to analyze the potential DoS attack of having such state.) >> >> However, the proposal introduces a network limtiation, essentially >> a protocol change, in the network. I did not think v6Ops was free >> to recommend behaviors (dropping unclassifiable fragments) which >> basically violate the base IPv6 spec. >> >> It seems that the right answer was discussed much earlier, namely >> changing the protocol behavior (a 6man activity) to tell hosts to >> reject RA and ND packets which were received in fragments. >> >> If that is the right answer, then we have to be very careful about >> creating long-lived restrictions as a remediation until such a >> solution can be adopted. >> >> Yours, 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 > From fgont@si6networks.com Wed May 30 16:19:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9570911E80EC for ; Wed, 30 May 2012 16:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMk-jpr5cKIt for ; Wed, 30 May 2012 16:19:24 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5CD11E80D5 for ; Wed, 30 May 2012 16:19:24 -0700 (PDT) Received: from [2001:5c0:1000:a::223] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZsAk-0000WP-7T; Thu, 31 May 2012 01:19:22 +0200 Message-ID: <4FC6AAD4.4090108@si6networks.com> Date: Wed, 30 May 2012 20:18:44 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> In-Reply-To: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 May 2012 23:19:24 -0000 On 05/30/2012 05:59 PM, RJ Atkinson wrote: > > A better approach for the RA Guard document would be: > > 1) to put together a separate I-D for 6MAN that says approximately > the above (and explains why). There is probably a little text > clarifying that any host receiving an RA that did not comply with > the proposed new rule above MUST be dropped by that receiving host. FWIW, something like that has already been published and presented at the last IETF: * Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rbonica@juniper.net Thu May 31 06:54:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4758221F8658 for ; Thu, 31 May 2012 06:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp8+JObZxGxX for ; Thu, 31 May 2012 06:54:09 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3C21F84BF for ; Thu, 31 May 2012 06:54:05 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT8d3/NMnMgWer7tee96VZg0qNfHd4xBF@postini.com; Thu, 31 May 2012 06:54:09 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 May 2012 06:53:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 31 May 2012 09:53:32 -0400 From: Ronald Bonica To: Fernando Gont , RJ Atkinson Date: Thu, 31 May 2012 09:53:31 -0400 Thread-Topic: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice Thread-Index: Ac0+urf3eurbOELfRiCIageJy4wFRAAdwA8Q Message-ID: <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> In-Reply-To: <4FC6AAD4.4090108@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 13:54:10 -0000 Fernando, The problem that we are wrestling with isn't specific to RA Guard. The kind= of fragmentation that we are discussing will cause problems for firewalls,= in general. Therefore, we might want to request the following from 6man: 1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6 header, al= l extension headers, the ICMPv6 type, code, and checksum are included in th= e first fragment 2) Hosts MUST NOT send fragmented packets carrying any next-layer protocol = unless the IPv6 header, all extension headers, the entire next-layer protoc= ol header are included in the first fragment. TCP and UDP are examples of n= ext-layer protocols. Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Fernando Gont > Sent: Wednesday, May 30, 2012 7:19 PM > To: RJ Atkinson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implementation-04.txt> (Implementation Advice for IPv6 Router > Advertisement Guard (RA-Guard)) to Best Current Practice >=20 > On 05/30/2012 05:59 PM, RJ Atkinson wrote: > > > > A better approach for the RA Guard document would be: > > > > 1) to put together a separate I-D for 6MAN that says approximately > > the above (and explains why). There is probably a little text > > clarifying that any host receiving an RA that did not comply with > > the proposed new rule above MUST be dropped by that receiving > host. >=20 > FWIW, something like that has already been published and presented at > the last IETF: >=20 > * 02.txt> >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marc.blanchet@viagenie.ca Thu May 31 07:03:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CFC21F8618 for ; Thu, 31 May 2012 07:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McZDQRalIaxJ for ; Thu, 31 May 2012 07:03:18 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2B97021F8587 for ; Thu, 31 May 2012 07:02:57 -0700 (PDT) Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3796541306; Thu, 31 May 2012 10:02:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> Date: Thu, 31 May 2012 10:02:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DF1A945-EBB7-4B24-B7C1-2FF9CD93868A@viagenie.ca> References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1278) Cc: Fernando Gont , "v6ops@ietf.org" , RJ Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 14:03:19 -0000 - I like that idea, since fragments have been a problem (from a security = perspective, both v4 and v6). This writing seems to provide a good way = to enable any middle box to be able to apply policies. =20 - should the 6man mailing list be added to that thread? Marc. Le 2012-05-31 =E0 09:53, Ronald Bonica a =E9crit : > Fernando, >=20 > The problem that we are wrestling with isn't specific to RA Guard. The = kind of fragmentation that we are discussing will cause problems for = firewalls, in general. Therefore, we might want to request the following = from 6man: >=20 > 1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6 = header, all extension headers, the ICMPv6 type, code, and checksum are = included in the first fragment >=20 > 2) Hosts MUST NOT send fragmented packets carrying any next-layer = protocol unless the IPv6 header, all extension headers, the entire = next-layer protocol header are included in the first fragment. TCP and = UDP are examples of next-layer protocols. >=20 > Ron > >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Fernando Gont >> Sent: Wednesday, May 30, 2012 7:19 PM >> To: RJ Atkinson >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Last Call: > implementation-04.txt> (Implementation Advice for IPv6 Router >> Advertisement Guard (RA-Guard)) to Best Current Practice >>=20 >> On 05/30/2012 05:59 PM, RJ Atkinson wrote: >>>=20 >>> A better approach for the RA Guard document would be: >>>=20 >>> 1) to put together a separate I-D for 6MAN that says approximately >>> the above (and explains why). There is probably a little text >>> clarifying that any host receiving an RA that did not comply with >>> the proposed new rule above MUST be dropped by that receiving >> host. >>=20 >> FWIW, something like that has already been published and presented at >> the last IETF: >>=20 >> * > 02.txt> >>=20 >> Cheers, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >>=20 >>=20 >>=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 fgont@si6networks.com Thu May 31 07:55:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C766421F8630 for ; Thu, 31 May 2012 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhDgSAnpuPCn for ; Thu, 31 May 2012 07:55:21 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA421F8587 for ; Thu, 31 May 2012 07:55:21 -0700 (PDT) Received: from 61-128-17-190.fibertel.com.ar ([190.17.128.61] helo=[192.168.0.173]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sa6mT-00088u-9e; Thu, 31 May 2012 16:55:17 +0200 Message-ID: <4FC7864D.8000307@si6networks.com> Date: Thu, 31 May 2012 11:55:09 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ronald Bonica References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "v6ops@ietf.org" , RJ Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 14:55:24 -0000 Hi, Ron, On 05/31/2012 10:53 AM, Ronald Bonica wrote: > The problem that we are wrestling with isn't specific to RA Guard. We're kind of discussing to different, but entangled, problems: a) Use of fragmentation in Neighbor Discovery b) IPv6 header chains that span multiple fragments Regarding "a)", use of fragmentation with ND prevents feature-parity with IPv4: It becomes virtually impossible to e.g. perform Neighbor Discovery inspection (a la arpwatch or the like) Regarding "b)", it essentially prevents stateless filtering, and also breaks stateless translators. And is not limited to ICMPv6, but to all traffic. (please see below) > Therefore, we might want to request the > following from 6man: > > 1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6 > header, all extension headers, the ICMPv6 type, code, and checksum > are included in the first fragment This is a subset of "2)" below. Additionally, if you still allow fragmentation, ND inspection (i.e. inspection of the ND packets contents) is still virtually impossible -- and fragmentation is not needed for ND, anyway. So one can safely forbid fragmentation with ND (for the general case). This is why I wrote > 2) Hosts MUST NOT send fragmented packets carrying any next-layer > protocol unless the IPv6 header, all extension headers, the entire > next-layer protocol header are included in the first fragment. TCP > and UDP are examples of next-layer protocols. Fully agree. For instance, that's why we wrote: My take is that these "packets with an IPv6 header chain that spans multiple fragments" will be unreliable in the public Internet (stateless firewalls and stateless translators). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rbonica@juniper.net Thu May 31 08:18:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BFE21F874C for ; Thu, 31 May 2012 08:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXOjCeCVboQz for ; Thu, 31 May 2012 08:18:21 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id E2ED621F8743 for ; Thu, 31 May 2012 08:18:20 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT8eLuf0rO296ot/1TP229PuKH+zjUvsm@postini.com; Thu, 31 May 2012 08:18:20 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 May 2012 08:17:45 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 31 May 2012 08:17:44 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 31 May 2012 11:16:55 -0400 From: Ronald Bonica To: Fernando Gont Date: Thu, 31 May 2012 11:16:54 -0400 Thread-Topic: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice Thread-Index: Ac0/PWx/a3iNV5SQShq1dD1gtHDQTgAAf8uA Message-ID: <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> In-Reply-To: <4FC7864D.8000307@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , RJ Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 15:18:22 -0000 Fernando, If I read what you are saying correctly, our request to 6man should say: 1) Hosts MUST NOT fragment ICMPv6 Router Solicitation, Router Advertisement= , Neighbor Solicitation, Neighbor Advertisement or Redirect messages. 1) Hosts MUST NOT fragment any other ICMPv6 message unless the IPv6 header,= all extension headers, the ICMPv6 type, code, and checksum are included in= the first fragment 3) Hosts MUST NOT fragment packets carrying any next-layer protocol unless = the IPv6 header, all extension headers, the entire next-layer protocol head= er are included in the first fragment. TCP and UDP are examples of next-lay= er protocols. Do I have this right? Ron > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Thursday, May 31, 2012 10:55 AM > To: Ronald Bonica > Cc: Fernando Gont; RJ Atkinson; v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implementation-04.txt> (Implementation Advice for IPv6 Router > Advertisement Guard (RA-Guard)) to Best Current Practice >=20 > Hi, Ron, >=20 > On 05/31/2012 10:53 AM, Ronald Bonica wrote: > > The problem that we are wrestling with isn't specific to RA Guard. >=20 > We're kind of discussing to different, but entangled, problems: >=20 > a) Use of fragmentation in Neighbor Discovery > b) IPv6 header chains that span multiple fragments >=20 >=20 > Regarding "a)", use of fragmentation with ND prevents feature-parity > with IPv4: It becomes virtually impossible to e.g. perform Neighbor > Discovery inspection (a la arpwatch or the like) >=20 > Regarding "b)", it essentially prevents stateless filtering, and also > breaks stateless translators. And is not limited to ICMPv6, but to all > traffic. (please see below) >=20 >=20 > > Therefore, we might want to request the following from 6man: > > > > 1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6 > > header, all extension headers, the ICMPv6 type, code, and checksum > are > > included in the first fragment >=20 > This is a subset of "2)" below. Additionally, if you still allow > fragmentation, ND inspection (i.e. inspection of the ND packets > contents) is still virtually impossible -- and fragmentation is not > needed for ND, anyway. So one can safely forbid fragmentation with ND > (for the general case). >=20 > This is why I wrote > >=20 >=20 >=20 > > 2) Hosts MUST NOT send fragmented packets carrying any next-layer > > protocol unless the IPv6 header, all extension headers, the entire > > next-layer protocol header are included in the first fragment. TCP > and > > UDP are examples of next-layer protocols. >=20 > Fully agree. For instance, that's why we wrote: > 01.txt> >=20 > My take is that these "packets with an IPv6 header chain that spans > multiple fragments" will be unreliable in the public Internet > (stateless firewalls and stateless translators). >=20 > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 From fgont@si6networks.com Thu May 31 08:19:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5121F879E for ; Thu, 31 May 2012 08:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0bIYFZKDD4p for ; Thu, 31 May 2012 08:19:12 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6899E21F8760 for ; Thu, 31 May 2012 08:19:12 -0700 (PDT) Received: from 61-128-17-190.fibertel.com.ar ([190.17.128.61] helo=[192.168.0.174]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sa79b-0008Na-8w; Thu, 31 May 2012 17:19:11 +0200 Message-ID: <4FC78BE8.6060102@si6networks.com> Date: Thu, 31 May 2012 12:19:04 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ran Atkinson References: <07004891-BB63-4D5A-B858-1069B97CD47F@gmail.com> In-Reply-To: <07004891-BB63-4D5A-B858-1069B97CD47F@gmail.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 15:19:13 -0000 On 05/30/2012 06:05 PM, Ran Atkinson wrote: > Rule 4 is both a protocol change and (misguided) operational mitigation. > Rule 4 is mandatory according to this document and will cause certain > perfectly valid IPv6 packets to be dropped instead of forwarded. The > rule damages IPv6 and impairs utility of IPv6 in the real world. I have asked (some of) this already, but will retry: 1) How large do you expect packets employing CALIPSO become? (mostly curious here) 2) Do you find it acceptable to have your (mtu-zized) traffic be 50% overhead (at the very least)? (FWIW, I'm obviously implying that the IPv6 header chain is spanning multiple fragments, and hence at least the first fragment is 100% headers -- and not necessarily as a result of employing CALIPSO). 3) Don't you find packets breaking stateless translators "impairing the utility of IPv6 in the real world"? (FWIW, packets with an IPv6 header chain spanning multiple fragments do) 4) Do you expect there will not be stateless filtering in IPv6? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Thu May 31 08:27:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C5911E8095 for ; Thu, 31 May 2012 08:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoAr0d4bszY3 for ; Thu, 31 May 2012 08:27:30 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D9DEA11E808C for ; Thu, 31 May 2012 08:27:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6C47C870100; Thu, 31 May 2012 17:27:25 +0200 (CEST) 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 NxfjwD6kTlyf; Thu, 31 May 2012 17:27:20 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 88FE68700CA; Thu, 31 May 2012 17:27:20 +0200 (CEST) Message-ID: <4FC78DD7.3080901@globis.net> Date: Thu, 31 May 2012 17:27:19 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: RJ Atkinson References: <1F73F9FE-9BA5-4506-A5FB-AE09C1C18626@gmail.com> In-Reply-To: <1F73F9FE-9BA5-4506-A5FB-AE09C1C18626@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 15:27:33 -0000 May I humbly suggest that fragmentation headers are merely one (recently discovered) way of bypassing a parser (in RA Guard) that relies on positive identification of (RA) messages. Who says that there aren't others? I think you'll find it impossible to write a parsing rule today that guarantees catching 100% of all RA messages without any false negatives. >From an operational standpoint, I think false negatives in this particular case are far worse than false positives. IMHO Until the RA message or other control messages themselves are 100% guaranteed parse-able by all entities on the network in exactly the same way to avoid false negatives (including all RA Guard implementations, and all end nodes deployed in the field) we'll need a default discard rule. Otherwise there's always going to be someone looking for a way to confuse the (RA Guard) parser into giving up on its parsing and permit forwarding of a malformed or unusual (RA) message to some unsuspecting end node implementation that interprets the packet in a different way and which then accepts and installs the (evil) default route or other option, thus rendering RA Guard or other on-the-wire filter useless. I suspect, going down this path might require quite a culture change in 6man, removing a lot of flexibility for the future in the interests of allowing effective on-the-wire filtering today. It also probably wouldn't be in the spirit of the principle founded in RFC760 "In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." regards, RayH RJ Atkinson wrote: > Fernando wrote: >> It's not a protocol change, > > Nonsense. > >> but an operational mitigation. -- for instance, there is no change >> in the way the sending router or the receiving hosts process RAs. > > > Rule 4 mandates changes to whether certain IPv6 packets get forwarded, > which is a major change to the IPv6 protocol specifications. No. It merely continues the well established practice of on-the-wire filtering. > > Rule 4 is both a protocol change and (misguided) operational mitigation. > Rule 4 is mandatory according to this document and will cause certain > perfectly valid IPv6 packets to be dropped instead of forwarded. The > rule damages IPv6 and impairs utility of IPv6 in the real world. Please identify the affected false-positive packets so further mitigation can be added. > > The comprehensive fix is to update the hosts as Joel Halpern and Ron Bonica > outlined earlier today. I don't think that change would be controversial, > so likely it could proceed quickly through 6MAN. In the meantime, > Rule 4 could be edited and cleaned up such that no valid IPv6 > packets get dropped by an RA Guard. Not comprehensive at all. It does fix the current problem. However, the real problem is the natural conflict between the need for flexible end-node implementations versus tight inflexible security filters. Please suggest the rule clean up. I don't believe it's possible. This is fundamentally because of the way IPv6 is specified (without a fixed structure, with flexible header chains, and with loose interpretation of received packets). > Yours, > > Ran > From jmh@joelhalpern.com Thu May 31 08:34:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF10511E808C for ; Thu, 31 May 2012 08:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM3uzBiTQ5gA for ; Thu, 31 May 2012 08:34:00 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 610AB21F879F for ; Thu, 31 May 2012 08:34:00 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id CF13155803C for ; Thu, 31 May 2012 08:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 464291C08BB; Thu, 31 May 2012 08:33:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.110] (pool-71-161-51-209.clppva.btas.verizon.net [71.161.51.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D6EE41C0878; Thu, 31 May 2012 08:33:57 -0700 (PDT) Message-ID: <4FC78F51.7070602@joelhalpern.com> Date: Thu, 31 May 2012 11:33:37 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ray Hunter References: <1F73F9FE-9BA5-4506-A5FB-AE09C1C18626@gmail.com> <4FC78DD7.3080901@globis.net> In-Reply-To: <4FC78DD7.3080901@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fernando Gont , v6ops@ietf.org, RJ Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 15:34:01 -0000 Fortunately, this is a very different problem from detecting an exertnal->internal message with a collaborating internal partner. For an RA to be an attack vector, it has to be parsed by the large majority of hosts. Thus, it follows that we do actually know what encodings can be used. Yours, Joel On 5/31/2012 11:27 AM, Ray Hunter wrote: > May I humbly suggest that fragmentation headers are merely one (recently > discovered) way of bypassing a parser (in RA Guard) that relies on > positive identification of (RA) messages. Who says that there aren't > others? > > I think you'll find it impossible to write a parsing rule today that > guarantees catching 100% of all RA messages without any false negatives. >> From an operational standpoint, I think false negatives in this > particular case are far worse than false positives. > > IMHO Until the RA message or other control messages themselves are 100% > guaranteed parse-able by all entities on the network in exactly the same > way to avoid false negatives (including all RA Guard implementations, > and all end nodes deployed in the field) we'll need a default discard > rule. Otherwise there's always going to be someone looking for a way to > confuse the (RA Guard) parser into giving up on its parsing and permit > forwarding of a malformed or unusual (RA) message to some unsuspecting > end node implementation that interprets the packet in a different way > and which then accepts and installs the (evil) default route or other > option, thus rendering RA Guard or other on-the-wire filter useless. > > I suspect, going down this path might require quite a culture change in > 6man, removing a lot of flexibility for the future in the interests of > allowing effective on-the-wire filtering today. > > It also probably wouldn't be in the spirit of the principle founded in > RFC760 "In general, an implementation should be conservative in its > sending behavior, and liberal in its receiving behavior. That is, it > should be careful to send well-formed datagrams, but should accept any > datagram that it can interpret (e.g., not object to technical errors > where the meaning is still clear)." > > regards, > RayH > > RJ Atkinson wrote: >> Fernando wrote: >>> It's not a protocol change, >> >> Nonsense. >> >>> but an operational mitigation. -- for instance, there is no change >>> in the way the sending router or the receiving hosts process RAs. >> >> >> Rule 4 mandates changes to whether certain IPv6 packets get forwarded, >> which is a major change to the IPv6 protocol specifications. > No. It merely continues the well established practice of on-the-wire > filtering. >> >> Rule 4 is both a protocol change and (misguided) operational mitigation. >> Rule 4 is mandatory according to this document and will cause certain >> perfectly valid IPv6 packets to be dropped instead of forwarded. The >> rule damages IPv6 and impairs utility of IPv6 in the real world. > Please identify the affected false-positive packets so further > mitigation can be added. >> >> The comprehensive fix is to update the hosts as Joel Halpern and Ron >> Bonica >> outlined earlier today. I don't think that change would be controversial, >> so likely it could proceed quickly through 6MAN. In the meantime, >> Rule 4 could be edited and cleaned up such that no valid IPv6 >> packets get dropped by an RA Guard. > Not comprehensive at all. It does fix the current problem. However, the > real problem is the natural conflict between the need for flexible > end-node implementations versus tight inflexible security filters. > > Please suggest the rule clean up. I don't believe it's possible. This is > fundamentally because of the way IPv6 is specified (without a fixed > structure, with flexible header chains, and with loose interpretation of > received packets). >> Yours, >> >> Ran >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fgont@si6networks.com Thu May 31 08:50:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7D11E8139 for ; Thu, 31 May 2012 08:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6v+eCGqde1L for ; Thu, 31 May 2012 08:50:45 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id DDDEC11E813A for ; Thu, 31 May 2012 08:50:44 -0700 (PDT) Received: from 61-128-17-190.fibertel.com.ar ([190.17.128.61] helo=[192.168.0.176]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sa7e5-0000CT-6x; Thu, 31 May 2012 17:50:41 +0200 Message-ID: <4FC7934B.4010205@si6networks.com> Date: Thu, 31 May 2012 12:50:35 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ronald Bonica References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , RJ Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 15:50:46 -0000 Hi, Ron, On 05/31/2012 12:16 PM, Ronald Bonica wrote: > 1) Hosts MUST NOT fragment ICMPv6 Router Solicitation, Router > Advertisement, Neighbor Solicitation, Neighbor Advertisement or > Redirect messages. This one is correct. Note that in draft-gont-6man-nd-extension-headers, we're currently saying "SHOULD NOT", but this should probably be changed to "MUST NOT", as you indicate. > 1) Hosts MUST NOT fragment any other ICMPv6 message unless the IPv6 > header, all extension headers, the ICMPv6 type, code, and checksum > are included in the first fragment This one is a subset of "3)" below, so need for special requirements here -- i.e., we don't need to make ICMPv6 a special case. > 3) Hosts MUST NOT fragment packets carrying any next-layer protocol > unless the IPv6 header, all extension headers, the entire next-layer > protocol header are included in the first fragment. TCP and UDP are > examples of next-layer protocols. This is correct. We have expressed this requirement (in draft-gont-6man-oversized-header-chain-01.txt) as: All IPv6 packets MUST contain the entire IPv6 header chain within the first "assumed Path-MTU" bytes of the packet. If a packet is fragmented, the first fragment of the packet (i.e., that with a Fragment Offset of 0) must contain the entire IPv6 header chain within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the packet. > Do I have this right? Yes. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rbonica@juniper.net Thu May 31 09:05:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727EC11E8094 for ; Thu, 31 May 2012 09:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.438 X-Spam-Level: X-Spam-Status: No, score=-106.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oExiVmLpo2oo for ; Thu, 31 May 2012 09:05:54 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5215911E8091 for ; Thu, 31 May 2012 09:05:52 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT8eW37b6sA1wPcEWe/H4p8dKytAY0Vjh@postini.com; Thu, 31 May 2012 09:05:54 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 May 2012 09:04:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 31 May 2012 12:04:08 -0400 From: Ronald Bonica To: Fernando Gont Date: Thu, 31 May 2012 12:04:07 -0400 Thread-Topic: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice Thread-Index: Ac0/RSV95x4ssIk4R36HQkHoTpVeAwAAdTXQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D76C45028B@EMBX01-WF.jnpr.net> References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> In-Reply-To: <4FC7934B.4010205@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , RJ Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 16:05:55 -0000 Wfm! > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Thursday, May 31, 2012 11:51 AM > To: Ronald Bonica > Cc: RJ Atkinson; v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implementation-04.txt> (Implementation Advice for IPv6 Router > Advertisement Guard (RA-Guard)) to Best Current Practice >=20 > Hi, Ron, >=20 > On 05/31/2012 12:16 PM, Ronald Bonica wrote: > > 1) Hosts MUST NOT fragment ICMPv6 Router Solicitation, Router > > Advertisement, Neighbor Solicitation, Neighbor Advertisement or > > Redirect messages. >=20 > This one is correct. >=20 > Note that in draft-gont-6man-nd-extension-headers, we're currently > saying "SHOULD NOT", but this should probably be changed to "MUST NOT", > as you indicate. >=20 >=20 >=20 > > 1) Hosts MUST NOT fragment any other ICMPv6 message unless the IPv6 > > header, all extension headers, the ICMPv6 type, code, and checksum > are > > included in the first fragment >=20 > This one is a subset of "3)" below, so need for special requirements > here -- i.e., we don't need to make ICMPv6 a special case. >=20 >=20 >=20 > > 3) Hosts MUST NOT fragment packets carrying any next-layer protocol > > unless the IPv6 header, all extension headers, the entire next-layer > > protocol header are included in the first fragment. TCP and UDP are > > examples of next-layer protocols. >=20 > This is correct. >=20 > We have expressed this requirement (in > draft-gont-6man-oversized-header-chain-01.txt) as: >=20 > All IPv6 packets MUST contain the entire IPv6 header chain within > the > first "assumed Path-MTU" bytes of the packet. If a packet is > fragmented, the first fragment of the packet (i.e., that with a > Fragment Offset of 0) must contain the entire IPv6 header chain > within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the > packet. >=20 >=20 > > Do I have this right? >=20 > Yes. >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 From rja.lists@gmail.com Thu May 31 10:51:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436AF21F861C for ; Thu, 31 May 2012 10:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012, 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 PF6aqbeztib6 for ; Thu, 31 May 2012 10:51:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6C621F861A for ; Thu, 31 May 2012 10:51:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so861771vbb.31 for ; Thu, 31 May 2012 10:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=uMkEMkEFKeoItA00gqKMK+PL+Y1alH8g7tdBmZE26RA=; b=WykYiKUhXPcVaSvu9TVY+QgTo2fFwASnjr6hKVJnqxYjQHiHyjUVtV9Wjs/VfcHo7b dBpAGndQXSf1SGEn9hJUVHANQLKqEnagVg6TvYKeIFvAjvNCR0KysfsGybVq29aPz6eB zy+/weHJz/mjRea5u2ViuOy5cJotWvBLVjyYQnrh/2LHT8xCrEJjUD29VbK7uRfIqaty 5iQhWVKG8qS5PMI0MXpVMCQU6zMqkCRAWuqleVfZeD8H44/VRgf87xIbqpWu4ROragsS P2HKXB/3XZ4HNhLaIzzkuOcfzfS86VAD3QhR6S9K8R1IIc3iEwlr2vCk5OsSRtF922ck BWOA== Received: by 10.220.151.80 with SMTP id b16mr3152412vcw.4.1338486678075; Thu, 31 May 2012 10:51:18 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id m14sm5928903vdh.4.2012.05.31.10.51.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 10:51:17 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: RJ Atkinson In-Reply-To: <4FC78DD7.3080901@globis.net> Date: Thu, 31 May 2012 13:51:17 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <1F73F9FE-9BA5-4506-A5FB-AE09C1C18626@gmail.com> <4FC78DD7.3080901@globis.net> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 17:51:19 -0000 On 31 May 2012, at 11:27 , Ray Hunter wrote: > May I humbly suggest that fragmentation headers are merely one > (recently discovered) way of bypassing a parser (in RA Guard) > that relies on positive identification of (RA) messages. Unlike some protocols, IPv6 extension headers (fragmentation or otherwise) can be parsed even if the particular IPv6 option is not recognised. Further, several deployed IPv6 routers have silicon with the ability to parse past an optional IPv6 header (e.g. Dest Opts header) at wire-speed, for example in order to be able to read the TCP/UDP ports to apply a user-configured per-interface ACL to IPv6 packets. The difficult property of the Fragmentation Header is unique to the function of fragmentation; a device can't parse past the Fragmentation Header of the 1st packet to discover whether a 2nd (or Nth) fragment contains an RA, unless the device sees all fragments and reassembles the packet before parsing. > IMHO Until the RA message or other control messages themselves > are 100% guaranteed parse-able by all entities on the network ... That is true already -- provided only that the RA is not hidden behind a Fragment Header. By mandating that hosts receiving an RA from a fragmented packet drop that packet without processing the RA, the only fully comprehensive solution is provided, without dropping any valid IPv6 packets. Further, hosts ought to do that check anyway, as not all IPv6 deployments will include an RA Guard device, and a host can't know a priori whether its deployment does or does not include an RA Guard. Since hosts are the devices at risk from a rogue RA, host stack implementers have incentive to implement and deploy such an IPv6 specification update quickly -- probably more quickly than RA Guard implementations compliant with this draft could be widely implemented and widely deployed. > I suspect, going down this path might require quite a culture change > in 6man, removing a lot of flexibility for the future in the interests > of allowing effective on-the-wire filtering today. IPv6 already went down the path of being much simpler to parse. That is a done deal long since. Further, the 6MAN WG recently reinforced this with RFC-6564, which codifies strict rules about all future potential IPv6 Extension Headers. Those rules are specifically designed to ensure that silicon designed now will be able to parse/parse-past all future IPv6 Extension headers at wire speed without modification. So the culture you seek already exists in 6MAN, and as I recall even existed in the IPv6 WG in the 1990s. A previous employer of mine shipped silicon circa 2003 that could parse through an IPv6 packet -- including parsing past IPv6 Extension Headers and unrecognised options -- and apply TCP/UDP port based ACLs that had IPv6 optional headers before the TCP/UDP header -- all at (very fast) wire speed (N Gbps). The only header that silicon couldn't do much with was a Fragment Header, because it has the one unique property of splitting a packet in two (as noted earlier). ASIDE: That Verilog enhancement was not a lot of gates, did not increase the die size, and did not increase manufacturing cost. As with software, it helps to have good engineers designing one's silicon, but it isn't rocket science, in large part because IPv6 was designed to be readily parseable at speed. Yours, Ran Atkinson From rja.lists@gmail.com Thu May 31 11:09:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3E321F8747 for ; Thu, 31 May 2012 11:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlR69q+iGQOR for ; Thu, 31 May 2012 11:09:38 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 721DE21F8746 for ; Thu, 31 May 2012 11:09:38 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so876313vbb.31 for ; Thu, 31 May 2012 11:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=YYL4pAVl64/v0kdYlaKeSAZK62neFg2hatA/0SnFzEE=; b=pw7mxdnl/gX6JKJw7Nct4PylpDSf/uTKtpwokHAyAlk/hoRX5yAlWh7HD5SeaU8G2Y tgwRKs6HdkAOJN73uIMWgM9gE6A2r9BhwEDFKxeq9450IPn60e0HrejEAZ2Q/8UZOYqy MJDxkxCnQ0sZPEzJudECVgf4OXS8znyaB3wIReXdjxkkKfldlL9jc3dzNMRk7yHYL0u2 Q3ov9qj6+4sWIok1ZR9IfjDUNHsSlRJlwZKB/56hn0xCFRyanbYX4T03AvVCOXjxYdGF Uuuy1shiXcftlxlMw67olIVjkW0/9q7YpCTp1H9cjjhoJ1rrWJV8r3X8kO4m5C4isD+V fJ+Q== Received: by 10.220.151.80 with SMTP id b16mr3215099vcw.4.1338487777929; Thu, 31 May 2012 11:09:37 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id g10sm6010811vdk.2.2012.05.31.11.09.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 11:09:37 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: RJ Atkinson In-Reply-To: <4FC7934B.4010205@si6networks.com> Date: Thu, 31 May 2012 14:09:37 -0400 Content-Transfer-Encoding: 7bit Message-Id: <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 18:09:39 -0000 On 31 May 2012, at 11:50 , Fernando Gont wrote: > On 05/31/2012 12:16 PM, Ronald Bonica wrote: >> 1) Hosts MUST NOT fragment ICMPv6 Router Solicitation, Router >> Advertisement, Neighbor Solicitation, Neighbor Advertisement or >> Redirect messages. > > This one is correct. > > Note that in draft-gont-6man-nd-extension-headers, we're currently > saying "SHOULD NOT", but this should probably be changed to "MUST NOT", > as you indicate. Agree. "MUST NOT" seems to be functionally necessary here. >> 3) Hosts MUST NOT fragment packets carrying any next-layer protocol >> unless the IPv6 header, all extension headers, the entire next-layer >> protocol header are included in the first fragment. TCP and UDP are >> examples of next-layer protocols. > > This is correct. > > We have expressed this requirement (in > draft-gont-6man-oversized-header-chain-01.txt) as: > > All IPv6 packets MUST contain the entire IPv6 header chain within the > first "assumed Path-MTU" bytes of the packet. If a packet is > fragmented, the first fragment of the packet (i.e., that with a > Fragment Offset of 0) must contain the entire IPv6 header chain > within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the > packet. That seems OK at first reading. I hope there already is text that has the effect of requiring a receiving IPv6 node to drop any received ICMPv6 that hid behind a Fragment Header. One imagines the actual requirement for receiving IPv6 nodes might be written more generically. As an example to clarify things, it would not hurt to explicitly note that this does NOT preclude the use of TCP Jumbo data payloads, but instead merely requires that all *headers*, starting from IPv6 base header and continuing up to & including the TCP header, be present in the 1st packet. This means that the RA Guard document ought to: (1) cite (normatively) draft-gont-6man-oversized-header-chain, (2) delete Rule 4 of the RA Guard draft (which is not needed), and (3) add clarifying text to the RA Guard draft noting that the referenced 6MAN document ensures that RA messages that try to hide behind a Fragment Header will be dropped by the receiving IPv6 node. Yours, Ran From fgont@si6networks.com Thu May 31 11:53:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D267121F8633 for ; Thu, 31 May 2012 11:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMxOaYaEJjjv for ; Thu, 31 May 2012 11:53:01 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id F163E21F8630 for ; Thu, 31 May 2012 11:52:59 -0700 (PDT) Received: from 61-128-17-190.fibertel.com.ar ([190.17.128.61] helo=[192.168.0.212]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SaAUU-0001my-IX; Thu, 31 May 2012 20:52:58 +0200 Message-ID: <4FC7BE00.10403@si6networks.com> Date: Thu, 31 May 2012 15:52:48 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> In-Reply-To: <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 18:53:03 -0000 Hi, Ran, On 05/31/2012 03:09 PM, RJ Atkinson wrote: >> This one is correct. >> >> Note that in draft-gont-6man-nd-extension-headers, we're currently >> saying "SHOULD NOT", but this should probably be changed to "MUST NOT", >> as you indicate. > > Agree. > > "MUST NOT" seems to be functionally necessary here. Ok, I will update the doc and resubmit, such that 6man wg is polled about adoption of this I-D with this change 'in'. Note: the only possible "issue" here is that with SEND, packets *might* grow large enough to need fragmentation. However: 1) The aforementioned behaviour would be specified for traditional ND, rather than SEND. 2) At least the packet sizes sampled in the SEND spec are not larger than 1280 bytes 3) If you do deploy send, you don't really want to rely on fragmentation. If you do, then an attacker could trivially "disable" SEND by performing fragmentation (DoS) attacks. -- Just wanted to double-check this with you before the s/SHOULD/MUST/ change. >> We have expressed this requirement (in >> draft-gont-6man-oversized-header-chain-01.txt) as: >> >> All IPv6 packets MUST contain the entire IPv6 header chain within the >> first "assumed Path-MTU" bytes of the packet. If a packet is >> fragmented, the first fragment of the packet (i.e., that with a >> Fragment Offset of 0) must contain the entire IPv6 header chain >> within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the >> packet. > > That seems OK at first reading. > > I hope there already is text that has the effect of requiring > a receiving IPv6 node to drop any received ICMPv6 that hid > behind a Fragment Header. Such requirement is in draft-gont-6man-nd-extension-headers. Essentially, draft-gont-6man-nd-extension-headers forbids the use of fragmentation with ND, and hence this means that when it comes to ND you'll always have the entire IPv6 header chain available in the same packet (if you don't, the packet was fragmented, and you're required to fragment it). draft-gont-6man-oversized-header-chain tackles a more general problem: since we cannot ban IPv6 fragmentation altogether for general traffic (for obvious reasons), for the general case we require the first fragment to include the entire IPv6 header chain (i.e., "put as many headers as you want (including fragmentation)... but the entire IPv6 header chain must be available in the first fragment"). > One imagines the actual requirement > for receiving IPv6 nodes might be written more generically. > > As an example to clarify things, it would not hurt to explicitly > note that this does NOT preclude the use of TCP Jumbo data payloads, > but instead merely requires that all *headers*, starting from IPv6 > base header and continuing up to & including the TCP header, > be present in the 1st packet. You mean this could/should be clarified in draft-gont-6man-oversized-header-chain-01, or somewhere else? > This means that the RA Guard document ought to: > (1) cite (normatively) draft-gont-6man-oversized-header-chain, > (2) delete Rule 4 of the RA Guard draft (which is not needed), > and > (3) add clarifying text to the RA Guard draft noting that the > referenced 6MAN document ensures that RA messages that > try to hide behind a Fragment Header will be dropped > by the receiving IPv6 node. But if it's agreed that packets that do not contain the entire IPv6 header chain shouldn't be there, what would be the motivation for allowing them through ra-guard? -- Put another way, if we include a normative reference to draft-gont-6man-oversized-header-chain, this implicitly mean that, even with rule #4 in, the posibility of false positives is 0 (and OTOH, leaving rule #4 in allows ra-guard to protect 'legacy' implementations. (Me just wanting to follow your reasoning here) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Thu May 31 13:32:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9E921F863B for ; Thu, 31 May 2012 13:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6ydwI3aXgft for ; Thu, 31 May 2012 13:32:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0FE221F8639 for ; Thu, 31 May 2012 13:32:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so976312vbb.31 for ; Thu, 31 May 2012 13:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pDh3nNRlI+s6sv3I78glC5w4ytc92qrQ0a81jz6pDfQ=; b=rN3f7L19xnxwcmmGDKQpe3rXI8mRkoooG/HCXEYa3DuVNNI0MDD/241I62iw6iXiLc YuV4XKj9Jylgo9Bi4LJdfaxGVuzknbCEYVnq7vmR3cWe/h7mUROHPfP3bwNYWgiHoG5W zopbSyL2AlvPlhcZjJ4gAi+viIW5agPvgrm06NQQmxmQi5qP+aTIX/AnwDnbn3uT1HRV eF8TAwy+NrbIq0RCgP9mjL4AHhKIVoP5Epa72ltDFQ24GDAA+zybxLZaZ37mKzXcp+nW AfYCS+ogouFS/cCHwLoBlektvoHb3HM6xuaHmA0jYXnY9+EkPG6KlOs2Y9kXj8KWNXvJ EffQ== Received: by 10.52.93.50 with SMTP id cr18mr116629vdb.41.1338496355717; Thu, 31 May 2012 13:32:35 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id n2sm3390361vdj.3.2012.05.31.13.32.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 13:32:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: RJ Atkinson In-Reply-To: <4FC7BE00.10403@si6networks.com> Date: Thu, 31 May 2012 16:32:35 -0400 Content-Transfer-Encoding: 7bit Message-Id: <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com> References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> <4FC7BE00.10403@si6networks.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1278) Cc: Ran Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 May 2012 20:32:38 -0000 On 31 May 2012, at 14:52 , Fernando Gont wrote: > Note: the only possible "issue" here is that with SEND, packets *might* > grow large enough to need fragmentation. However: > > 1) The aforementioned behaviour would be specified for traditional ND, > rather than SEND. OK. As you say, it makes sense to except SEND from the restriction, since it provides stronger authentication already. > 2) At least the packet sizes sampled in the SEND spec are not larger > than 1280 bytes > 3) If you do deploy send, you don't really want to rely on > fragmentation. If you do, then an attacker could trivially "disable" > SEND by performing fragmentation (DoS) attacks. > > -- Just wanted to double-check this with you before the s/SHOULD/MUST/ > change. That sounds reasonable to me at first read, but one caveat. CAVEAT: I'm not a SEND expert. I don't know whether a SEND expert might have concerns. >>> We have expressed this requirement (in >>> draft-gont-6man-oversized-header-chain-01.txt) as: >>> >>> All IPv6 packets MUST contain the entire IPv6 header chain within the >>> first "assumed Path-MTU" bytes of the packet. If a packet is >>> fragmented, the first fragment of the packet (i.e., that with a >>> Fragment Offset of 0) must contain the entire IPv6 header chain >>> within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the >>> packet. >> >> That seems OK at first reading. >> >> I hope there already is text that has the effect of requiring >> a receiving IPv6 node to drop any received ICMPv6 that hid >> behind a Fragment Header. > > Such requirement is in draft-gont-6man-nd-extension-headers. > Essentially, draft-gont-6man-nd-extension-headers forbids the use of > fragmentation with ND, and hence this means that when it comes to ND > you'll always have the entire IPv6 header chain available in the same > packet (if you don't, the packet was fragmented, and you're required to > fragment it). > > draft-gont-6man-oversized-header-chain tackles a more general problem: > since we cannot ban IPv6 fragmentation altogether for general traffic > (for obvious reasons), for the general case we require the first > fragment to include the entire IPv6 header chain (i.e., "put as many > headers as you want (including fragmentation)... but the entire IPv6 > header chain must be available in the first fragment"). For the RA Guard problem, I strongly prefer the approach you indicate is defined in draft-gont-6man-nd-extension-headers -- because it is better scoped. Also, the sender always knows the link MTU for directly attached links (i.e. always known for the ND case) and ND is always link-local. So there are fewer unknowns operationally. I am not as enthusiastic about the *-oversized-header-chain approach, which appears to have much broader scope, because a sending node can't reliably know the Path MTU, sadly, and because I know of some odd-sized IPv6 link MTUs in the deployed world. Also, as I recall, you identified some special cases where the Path MTU might be less than the theoretical IPv6 minimum MTU and yet the Path MTU could be valid per various other IETF (transition-related ??) specs. However, I can tolerate *-oversized-header-chain, if that really is preferred collectively over the more focused *nd-extension-headers approach. >> One imagines the actual requirement >> for receiving IPv6 nodes might be written more generically. >> >> As an example to clarify things, it would not hurt to explicitly >> note that this does NOT preclude the use of TCP Jumbo data payloads, >> but instead merely requires that all *headers*, starting from IPv6 >> base header and continuing up to & including the TCP header, >> be present in the 1st packet. > > You mean this could/should be clarified in > draft-gont-6man-oversized-header-chain-01, or somewhere else? ...or in *-nd-extension-headers, as applicable. >> This means that the RA Guard document ought to: >> (1) cite (normatively) draft-gont-6man-oversized-header-chain, >> (2) delete Rule 4 of the RA Guard draft (which is not needed), >> and >> (3) add clarifying text to the RA Guard draft noting that the >> referenced 6MAN document ensures that RA messages that >> try to hide behind a Fragment Header will be dropped >> by the receiving IPv6 node. > > But if it's agreed that packets that do not contain the entire IPv6 > header chain shouldn't be there, what would be the motivation for > allowing them through ra-guard? That logic seems to include a somewhat theoretical assumption -- namely that an RA Guard implementation built out of available CPUs and available silicon will be able to read all of the bytes in the IPv6 packet and will be able to do so at some interesting fraction of line-rate for common interfaces. In theory, that might be true, and for some specific implementations it could be true, but it won't be universally true in practice. For example, it is unlikely to be true anytime soon for very high speed Ethernet links. In the real world, some (many ?) implementations of RA Guard will have an implementation-specific limit to packet inspection that is less than the Link MTU. Such limits are commonplace, possibly universal. Even "Deep Packet Inspection (DPI)" firewall implementations normally only can read several hundred bytes (perhaps 200 or 300) into a packet -- whereas a valid IPv6/Ethernet packet (e.g. ~1500 bytes long) legitimately might not reach the final (TCP, UDP, ICMP) header by the point that the implementation-specific DPI limit of the RA Guard implementation is reached. So some (we hope not many) real world RA Guard implementations will not be able to figure out whether a particular valid IPv6 packet is valid or not, due to implementation-specific limitations of that particular RA Guard implementation. When an RA Guard can't reliably figure out whether the packet is valid, the RA Guard should send the packet along -- on the principle of not dropping any valid IPv6 packets (aka: "do no harm"). Since the hosts will be protecting themselves from any RAs trying to hide behind Fragment Headers, there is no risk to having Rule 4 either disappear or be changed to allow all packets where the particular RA Guard implementation can't figure out whether a given IPv6 packet is valid or not. At a more architectural level, if the IPv6 specs need to change, then I'd like to see those changes proposed and accepted by the 6MAN WG (or its successors) -- rather than having an IETF recommended operational practice have the result of changing the IPv6 specs without bothering to update the actual IPv6 specs. Yours, Ran From fernando.gont.netbook.win@gmail.com Thu May 31 18:43:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D0621F8541 for ; Thu, 31 May 2012 18:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K93stofz6PE for ; Thu, 31 May 2012 18:43:00 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF621F8540 for ; Thu, 31 May 2012 18:42:59 -0700 (PDT) Received: by yhq56 with SMTP id 56so1410856yhq.31 for ; Thu, 31 May 2012 18:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=kpRFL4pp/wXr+PId6GUdq3vSj8xl53HYUmn3PGONnh4=; b=VsD7JG5XNAkiltIAGLBFEZCMniKdYulq+YtQuUcc+oxHVmpeAG93aygUh0eo8gLxLB aNHsXzxoe2NlNVu3YuKrKehN8FuVZseKCTWZCLWrLc++YXQk0vSL61JCR7T+f90AYcIn 1I12i3e6eSMdn4/InPppD1SBms3jlXt7V3Kc+cF6ZkJVE7x0NI4EhUpHBms8B9St9LO/ XHFaA2bgGm0PKPbguzJPJekbpqIVWlsWeSoyopFCrjmZ7BqkH559r0ToyMPPoIKzv8im UjC3fU5dkH96xzCqCU4GyTh1NxNiGMLkaug6ay2TB7ay/XeLOo/0YqFlKFSlJwMXjxv5 ApSQ== Received: by 10.236.125.135 with SMTP id z7mr861911yhh.44.1338514979246; Thu, 31 May 2012 18:42:59 -0700 (PDT) Received: from [192.168.123.103] ([186.134.30.55]) by mx.google.com with ESMTPS id q44sm1561384yhg.3.2012.05.31.18.42.54 (version=SSLv3 cipher=OTHER); Thu, 31 May 2012 18:42:58 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FC81786.10207@gont.com.ar> Date: Thu, 31 May 2012 22:14:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> <4FC7BE00.10403@si6networks.com> <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com> In-Reply-To: <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Ran Atkinson Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jun 2012 01:43:01 -0000 Hi, Ran, On 05/31/2012 05:32 PM, RJ Atkinson wrote: > On 31 May 2012, at 14:52 , Fernando Gont wrote: >> Note: the only possible "issue" here is that with SEND, packets >> *might* grow large enough to need fragmentation. However: >> >> 1) The aforementioned behaviour would be specified for traditional >> ND, rather than SEND. > > OK. As you say, it makes sense to except SEND from the restriction, > since it provides stronger authentication already. Well, in the case of SEND, one *might* want to relax the restriction to "SHOULD". However, I'd note that having SEND rely on fragmentation seems to me like a very bad idea: essentially, an attacker could perform a fragmentation-based DoS attack against SEND, and hence nodes would typically employ the malicious and non-authenticated information sent by the attacker (unless there's no fall back for non-send nodes). >> 2) At least the packet sizes sampled in the SEND spec are not >> larger than 1280 bytes 3) If you do deploy send, you don't really >> want to rely on fragmentation. If you do, then an attacker could >> trivially "disable" SEND by performing fragmentation (DoS) >> attacks. >> [....] > I don't know whether a SEND expert might have concerns. I will drop a note to the authors of the SEND spec and ask for input... >> draft-gont-6man-oversized-header-chain tackles a more general >> problem: since we cannot ban IPv6 fragmentation altogether for >> general traffic (for obvious reasons), for the general case we >> require the first fragment to include the entire IPv6 header chain >> (i.e., "put as many headers as you want (including >> fragmentation)... but the entire IPv6 header chain must be >> available in the first fragment"). > > For the RA Guard problem, I strongly prefer the approach you > indicate is defined in draft-gont-6man-nd-extension-headers -- > because it is better scoped. Also, the sender always knows the link > MTU for directly attached links (i.e. always known for the ND case) > and ND is always link-local. So there are fewer unknowns > operationally. Well, draft-gont-6man-nd-extension-headers kind of tackles the underlying problem behind filtering/monitoring ND-traffic. OTOH, draft-gont-6man-oversized-header-chain tackles a related but different problem (that's why it's not as scoped). > I am not as enthusiastic about the *-oversized-header-chain > approach, which appears to have much broader scope, because a sending > node can't reliably know the Path MTU, sadly, and because I know of > some odd-sized IPv6 link MTUs in the deployed world. Well, what *-oversized-header-chain essentially says is that if you fragment your packets, the entire IPv6 header should be present in the first fragment. As long as there is no intermmediate system that fragments your datagrams *and* splits the IPv6 header chain into multiple fragments, you're fine. > Also, as I recall, you identified some special cases where the Path > MTU might be less than the theoretical IPv6 minimum MTU and yet the > Path MTU could be valid per various other IETF (transition-related > ??) specs. What can be less than the IPv6 minimum MTU is the advertised MTU in an ICMPv6 PTB message (which would trigger the inclusion of a fragment header in all further packets). However, the minimum MTU is still considered to be 1280 bytes. > However, I can tolerate *-oversized-header-chain, if that really is > preferred collectively over the more focused *nd-extension-headers > approach. I think that both documents complement each other. Since *nd-extension-headers bans the use of fragmentation in ND, it not only simplifies the implementation of ra-guard, but *also* enables ND-monitoring (i.e., inspecting the contents of ND packets e.g. a la arpwatch). >>> This means that the RA Guard document ought to: (1) cite >>> (normatively) draft-gont-6man-oversized-header-chain, (2) delete >>> Rule 4 of the RA Guard draft (which is not needed), and (3) add >>> clarifying text to the RA Guard draft noting that the referenced >>> 6MAN document ensures that RA messages that try to hide behind a >>> Fragment Header will be dropped by the receiving IPv6 node. >> >> But if it's agreed that packets that do not contain the entire >> IPv6 header chain shouldn't be there, what would be the motivation >> for allowing them through ra-guard? > > That logic seems to include a somewhat theoretical assumption -- > namely that an RA Guard implementation built out of available CPUs > and available silicon will be able to read all of the bytes in the > IPv6 packet and will be able to do so at some interesting fraction of > line-rate for common interfaces. In theory, that might be true, and > for some specific implementations it could be true, but it won't be > universally true in practice. For example, it is unlikely to be true > anytime soon for very high speed Ethernet links. Well, this is the reason for which the first version of *nd-extension-headers tried to ban the use of all extension headers with ND. But it was argued (in 6man) that of parsing the entire IPv6 header chain at a layer-2 device was easily doable, and hence there was no need to limit possible extensions of ND (based on ext headers). In any case, if anything, this would be an argument to the extent to which ra-guard is simple/possible to implement, rather than about whether we should leave rule #4 in or out. > In the real world, some (many ?) implementations of RA Guard will > have an implementation-specific limit to packet inspection that is > less than the Link MTU. [....] > So some (we hope not many) real world RA Guard implementations will > not be able to figure out whether a particular valid IPv6 packet is > valid or not, due to implementation-specific limitations of that > particular RA Guard implementation. I would expect that RA-Guard implementation enforce a limit on the number of ext headers that they process (rather than of "bytes" that are "jumped over"). In that case, if they enforce some sensible limit (10?) they could prevent possible DoS attacks while still allowing all legitimate traffic. > When an RA Guard can't reliably > figure out whether the packet is valid, the RA Guard should send the > packet along -- on the principle of not dropping any valid IPv6 > packets (aka: "do no harm"). My take is that those packets will not survive the public IPv6 Internet. Stateless firewalls will block those packets when the implementation-specific limit is hit. > Since the hosts will be protecting themselves from any RAs trying to > hide behind Fragment Headers, there is no risk to having Rule 4 > either disappear or be changed to allow all packets where the > particular RA Guard implementation can't figure out whether a given > IPv6 packet is valid or not. I fully agree with this when it comes to updated host implementations. However, if the rules are changed as you indicate, those "legacy" implementations that still allow the use of fragmentation with ND would remain vulnerable. > At a more architectural level, if the IPv6 specs need to change, then > I'd like to see those changes proposed and accepted by the 6MAN WG > (or its successors) -- rather than having an IETF recommended > operational practice have the result of changing the IPv6 specs > without bothering to update the actual IPv6 specs. I personally believe that the specs should be changed -- for instance, we're pursuing that effort in 6man with draft-gont-6man-oversized-header-chain (about which 6man should be polled soon). Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From joelja@bogus.com Thu May 31 21:02:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D919211E8080 for ; Thu, 31 May 2012 21:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-Jw3E8P1CHb for ; Thu, 31 May 2012 21:02:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7799D11E8072 for ; Thu, 31 May 2012 21:02:44 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q5142hjV014543 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 1 Jun 2012 04:02:44 GMT (envelope-from joelja@bogus.com) Message-ID: <4FC83EE3.3080000@bogus.com> Date: Thu, 31 May 2012 21:02:43 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPv6 Ops WG References: <20120601035829.5632.30137.idtracker@ietfa.amsl.com> In-Reply-To: <20120601035829.5632.30137.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120601035829.5632.30137.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 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 Jun 2012 04:02:44 +0000 (UTC) Subject: [v6ops] FYI v6ops - New Meeting Session Request for IETF 84 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Jun 2012 04:02:45 -0000 --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Joel Jaeggli Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 300 Conflicts to Avoid: First Priority: 6man behave homenet softwire Second Priority: 6renum Third Priority: opsarea opsawg Special Requests: --------------------------------------------------------- If there are notable conflict that we should have listed but don't, that would be could to know. WG that have requested sessions so far that list us as a conflict include: dhc, multimob, sunset4, netconf, homenet, opsec, trill, 6renum, 6man, radext, dmm, dnsop, netext, behave