From Fred.L.Templin@boeing.com Mon Jul 1 09:00:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF7911E8215 for ; Mon, 1 Jul 2013 09:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 FhUs01FodXnT for ; Mon, 1 Jul 2013 08:59:56 -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 338D111E814F for ; Mon, 1 Jul 2013 08:59:48 -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 r61G0SQR026640 for ; Mon, 1 Jul 2013 09:00:28 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r61G0RpT026632 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 1 Jul 2013 09:00:27 -0700 Received: from XCH-BLV-103.nw.nos.boeing.com (130.247.25.118) by XCH-NWHT-06.nw.nos.boeing.com (130.247.25.110) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 1 Jul 2013 08:59:46 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-103.nw.nos.boeing.com ([169.254.3.252]) with mapi id 14.02.0328.011; Mon, 1 Jul 2013 08:59:46 -0700 From: "Templin, Fred L" To: Ole Troan Subject: RE: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOdJWoUZaGJnzSMU6ZOUB9nA7EbJlP+NBA Date: Mon, 1 Jul 2013 15:59:46 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B19B9@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AEA5F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180B0221@XCH-BLV-504.nw.nos.boeing.com> <520FB317-19E8-4DCA-81FB-124B17732FE0@employees.org> In-Reply-To: <520FB317-19E8-4DCA-81FB-124B17732FE0@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:00:03 -0000 Hi Ole, > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Friday, June 28, 2013 11:56 PM > To: Templin, Fred L > Cc: Brian E Carpenter; 6man > Subject: Re: draft-bonica-6man-frag-deprecate >=20 > Fred, >=20 > >> in my understanding the 1280 minimum MTU for IPv6 was already chosen > to > >> accommodate nested tunnels. > > > > Right, but.. > > > >> the expectation made, I believe, was that native links support at > least > >> an MTU of 1500 bytes, > > > > But, that expectation went out the window at the same time the IPv6 > > minMTU was set to 1280 - so now 1280 is all that can be expected. >=20 > quite the opposite. > physical link MTUs aren't getting smaller. > do you have any evidence that operators set the IPv6 MTU to a value > smaller than the MTU supported > by the link-layer? The evidence is in RFC2460, where the minMTU is set to 1280. Plus, there are links (e.g., 6lowpan, aviation data links, tactical military links etc.) where setting an MTU larger than 1280 might not be practical. =20 > as far as I can see the setting IPv6 minimum MTU to 1280, which gives > ample room for > nested tunnels works as designed. But, what would that look like in real life? The first tunnel (T1) would have to set a 1280 MTU so that its tunneled packets would emerge as 1320 bytes. Then, the next tunnel (T2) would have to set a 1320 MTU so its tunneled packets would emerge as 1360. Then the next tunnel (T3) would have to set a 1360 MTU so that its tunneled packets would emerge as 1400, etc. until we run out of available MTU. The question is, how can those tunnels be so carefully coordinated so that the nesting is nailed down enough so that we will never have an MTU infraction? In a single administrative domain where an operator can lay hands on every tunnel ingress this may be possible, but we need to engineer for the general case. > > So, without fragmentation, when the tunnel ingress receives a 1280 > > packet, it emits a (1280+HLEN) packet. If that packet is dropped > > at a link that configures a 1280 MTU, then it simply black holes. > > > >> allowing 220 bytes for tunnel encap (5 IPv6 headers). > > > > Tunnels within tunnels presents an additional pain point, but the > > plain truth is that IPv6 links only need to configure a 1280 MTU; > > not a 1500. >=20 > again, why would anyone do that? Performance. What matters is time on the wire, and some "wires" may not be fast enough to support anything larger than 1280 (see above). > the pain here is fragmentation, not supporting an MTU larger than 1280. Fragmentation and reassembly is a pain point for some (but not all) routers. The pain may be observed by the hosts which would (selfishly) like to do something to improve their performance. With SEAL, to get better performance (and in the process ease the burden on the routers) the hosts can use RFC4821 and begin sending packets larger than 1500.=20 =20 > >> you want to avoid reassembly at tunnel endpoints, if you care about > >> performance that is. > > > > Unfortunately, reassembly is absolutely necessary if the tunnel is > > configured over a path that contains at least one 1280 link (see > above). >=20 > reassembly in the network is a non-starter. Let me say again what I said several messages ago. Never say "always" and never say "never". The answer as to whether reassembly can be tolerated is: "it depends" (i.e., it depends on where the tunnel endpoints are positioned).=20 > the vendor I'm most familiar with does not do this in hardware. sure, > you can get reassembly, but at an order of one or two magnitudes less. > if anyone know of platforms doing IPv6 fragment reassembly at line rate > for 10G or 100G interfaces I'll stand corrected. ;-) > for now reassembly in the network is not realistic. Reassembly is required by RFC2460, RFC2473 and I think others have also been mentioned. To support tunnels, and especially tunnels within tunnels, it needs to be there. Thanks - Fred fred.l.templin@boeing.com > cheers, > Ole From Fred.L.Templin@boeing.com Mon Jul 1 09:07:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE25621F926E for ; Mon, 1 Jul 2013 09:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lmNlau+LXmZ for ; Mon, 1 Jul 2013 09:07:16 -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 B521111E81B2 for ; Mon, 1 Jul 2013 09:06: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 r61G6k66015469 for ; Mon, 1 Jul 2013 09:06:47 -0700 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r61G6jUB015462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 1 Jul 2013 09:06:45 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.176]) with mapi id 14.02.0328.011; Mon, 1 Jul 2013 09:06:44 -0700 From: "Templin, Fred L" To: Brian E Carpenter Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOdH/xXUHRKTNXHUOg8dTW41rHC5lP/xTA Date: Mon, 1 Jul 2013 16:06:44 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B19ED@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <51CDF8BF.6060002@gmail.com> <2134F8430051B64F815C691A62D983180B00B6@XCH-BLV-504.nw.nos.boeing.com> <51CE0D90.7090007@gmail.com> <2134F8430051B64F815C691A62D983180B02A3@XCH-BLV-504.nw.nos.boeing.com> <51CE6079.7060205@gmail.com> In-Reply-To: <51CE6079.7060205@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:07:21 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IEZyaWRheSwgSnVuZSAyOCwgMjAxMyA5OjIwIFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwNCj4g Q2M6IGphbWVzIHdvb2R5YXR0OyA2bWFuDQo+IFN1YmplY3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWJvbmljYS02bWFuLWZyYWctDQo+IGRlcHJlY2F0ZS0wMC50eHQN Cj4gDQo+IE9uIG9uZSBwb2ludC4uLg0KPiANCj4gDQo+IE9uIDI5LzA2LzIwMTMgMTA6NDQsIFRl bXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gLi4uDQo+ID4+IGFuZCAoYikgYWNjZXB0aW5nIHRoYXQg c3RyYXBwaW5nIHRoZSBNVFUgYXQgMTI4MCBpcw0KPiA+PiBhIHJlYXNvbmFibGUgc2hvcnQgdGVy bSBwb2xpY3kuIElmIChhKSBwcm9ncmVzc2l2ZWx5IHBlcnZhZGVzDQo+ID4+IHRoZSBpbnN0YWxs ZWQgYmFzZSB0aGVuIChiKSBjYW4gYmUgZHJvcHBlZCBhcyB0aGUgeWVhcnMgZ28gYnkuDQo+ID4N Cj4gPiBPbmNlIGEgbGluayBzZXRzIGEgMTI4MCBNVFUsIGhvdyB3aWxsIGl0IGtub3cgdGhhdCBp dCBpcyBub3cNCj4gPiBzYWZlIHRvIGluY3JlYXNlIHRoZSBNVFU/IEFuZCwgb25jZSBzZXQsIGhv dyBjYW4gd2UgZXhwZWN0DQo+ID4gb3BlcmF0b3JzIHRvIGdvIGJhY2sgYW5kIHJlLXNldCBpbiB0 aGUgZnV0dXJlLiBJTUhPLCBzdHJhcHBpbmcNCj4gPiB0aGUgTVRVIHRvIDEyODAgZXZlcnl3aGVy ZSBub3cgd291bGQgYmVjb21lIG9zc2lmaWVkIGxvbmcgaW50bw0KPiA+IHRoZSBmdXR1cmUuDQo+ IA0KPiBJdCB3b3VsZCBjZXJ0YWlubHkgdGFrZSB5ZWFycywgYnV0IEkgdGhpbmsgdGhlIGVuZCBy ZXN1bHQgd291bGQgYmUNCj4gaW1wbGVtZW50b3JzIHJhaXNpbmcgdGhlIGRlZmF1bHQgdG8gdGhl IHJlYWwgbGluayBNVFUsIG9uZSBzdGFjaw0KPiBhdCBhIHRpbWUuIEkgZG9uJ3QgdGhpbmsgeW91 IGZpbmQgbWFueSBJUHY0IHN0YWNrcyB0b2RheSB3aXRoDQo+IHRoZSBNVFUgc2V0IGxvdyBieSBk ZWZhdWx0Lg0KDQpUaGUgdHJhbnNpdGlvbiBhbnRpY2lwYXRlZCBieSBTRUFMIGlzIGFzIGZvbGxv d3MuIFBhY2tldHMgdGhhdA0KYXJlIG5vIGxhcmdlciB0aGFuIDE1MDAgYnl0ZXMgYXJlIHVuY29u ZGl0aW9uYWxseSBhY2NvbW1vZGF0ZWQNCndpdGggZnJhZ21lbnRhdGlvbi9yZWFzc2VtYmx5IHVz ZWQgaWYgbmVjZXNzYXJ5LiBIb3N0cyB3aWxsIHRoZW4NCm5vdGljZSB0aGF0IHRoZXkgY2FuIGdl dCBiZXR0ZXIgcGVyZm9ybWFuY2UgYnkgc2VuZGluZyBwYWNrZXRzDQp0aGF0IGFyZSBsYXJnZXIg dGhhbiAxNTAwLCBhbmQgd2lsbCB1c2UgUkZDNDgyMSB0byBlbnN1cmUgdGhhdA0KdGhvc2UgbGFy Z2VyIHBhY2tldHMgYXJlIGdldHRpbmcgdGhyb3VnaC4gVGhlIEludGVybmV0IHdpbGwgdGhlbg0K bmF0dXJhbGx5IGdyYXZpdGF0ZSB0b3dhcmQgbGFyZ2VyIHBhY2tldHMsIGFuZCBldmVudHVhbGx5 IHRoZQ0KSW50ZXJuZXQgImNlbGwgc2l6ZSIgd2lsbCBidW1wIHVwIGZyb20gMTUwMCB0byA4S0Iu DQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAgICAgQnJp YW4NCg== From Fred.L.Templin@boeing.com Mon Jul 1 09:14:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279C611E810E for ; Mon, 1 Jul 2013 09:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 tXnBXfkz3l2c for ; Mon, 1 Jul 2013 09:14:39 -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 C7CD311E80D7 for ; Mon, 1 Jul 2013 09:14:39 -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 r61GEcdS021607 for ; Mon, 1 Jul 2013 09:14:39 -0700 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r61GEcTE021596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 1 Jul 2013 09:14:38 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.94]) with mapi id 14.02.0328.011; Mon, 1 Jul 2013 09:14:37 -0700 From: "Templin, Fred L" To: Ole Troan Subject: RE: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOdJWoUZaGJnzSMU6ZOUB9nA7EbJlQAeKQ Date: Mon, 1 Jul 2013 16:14:37 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B1A36@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AEA5F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180B0221@XCH-BLV-504.nw.nos.boeing.com> <520FB317-19E8-4DCA-81FB-124B17732FE0@employees.org> In-Reply-To: <520FB317-19E8-4DCA-81FB-124B17732FE0@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:14:46 -0000 FYI, from a historical perspective here is the origin of the 1280 minMTU: Thanks - Fred fred.l.templin@boeing.com --- List: ipng Subject: (IPng 4802) increasing the IPv6 minimum MTU From: Steve Deering Date: 1997-11-14 0:37:00 [Download message RAW] In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e.= , 1500 minus room for a couple layers of encapsulating headers, so that min- MTU-size packets that are tunneled across 1500-byte-MTU paths won't be subject to fragmentation/reassembly on ingress/egress from the tunnels, in most cases). After the short discussion in the Munich meeting, I called for a show of hands, and of those who raised their hands (about half the attendees, if I recall correctly), the vast majority were in favor of this change -- there were only two or three people opposed. However, we recognized that a fundamental change of this nature requires thoughtful discussion and analysis on the mailing list, to allow those who were not at the meeting and those who were there but who have since had second thoughts, to express their opinions. A couple of people have already, in private conversation, raised some concerns that were not identified in the discussion at the meeting, which I report below. We would like to get this issue settled as soon as possible, since this is the only thing holding up the publication of the updated Proposed Standard IPv6 spec (the version we expect to advanc= e to Draft Standard), so let's see if we can come to a decision before the ID deadline at the end of next week (hoping there isn't any conflict between "thoughtful analysis" and "let's decide quickly" :-). The reason I would like to increase the minimum MTU is that there are some applications for which Path MTU Discovery just won't work very well, and which will therefore limit themselves to sending packets no larger than the minimum MTU. Increasing the minimum MTU would improve the bandwidth efficiency, i.e., reduce the header overhead (ratio of header bytes to payload bytes), for those applications. Some examples of such applications are: (1) Large-fanout, high-volume multicast apps, such as multicast video ("Internet TV"), multicast netnews, and multicast software distribution. I believe these applications will end up limiting themselves to packets no large than the min MTU in order to avoid the danger of incurring an "implosion" of ICMP Packet-Too-Big messages in response. Even though we have specified that router implementations must carefully rate-limit the emission of ICMP error messages, I am nervous about how well this will work in practice, especially once there is a lot of high-speed, bulk multicasting happening. An appropriate choice of rate or probability of emission of Packet-Too-Big responses to multicasts really depends on the fan-out of the multicast trees and the MTUs of all the branches in that tree, which is unknown and unknowable to the routers. Being sensibly conservative by choosing a very low rate could, in many cases, significantly increase the delay before the multicast source learns the right MTU for the tree and, hence, before receivers on smaller-MTU branches can start receiving the data. (2) DNS servers, or other similar apps that have the requirement of sending a small amount of data (a few packets at most) to a very large and transient set of clients. Such servers often reside on links, such as Ethernet, that have an MTU bigger than the links on which many of their clients may reside, such as dial-up links. If those servers were to send many reply messages of the size of their own links (as required by PMTU Discovery), they could incur very many ICMP packet-too-big messages and consequent retransmissions of the replies -- in the worse case, multiplying the total bandwidth consumption (and delivery delay) by 2 or 3 times that of the alternative approach of just using the min MTU always. Furthermore, the use of PMTU Discovery could result in such servers filling up lots of memory withed cached PMTU information that will never be used again (at least, not before it gets garbage-collected). The number I propose for the new minimum MTU is 1280 bytes (1024 + 256, as compared to the classic 576 value which is 512 + 64). That would leave generous room for encapsulating/tunnel headers within the Ethernet MTU of 1500, e.g., enough for two layers of secure tunneling including both ESP and AUTH headers. For medium-to-high speed links, this change would reduce the IPv6 header overhead for min MTU packets from 7% to 3% (a little less than the IPv4 header overhead for 576-byte IPv4 packets). For low-speed links such as analog dial-up or low-speed wireless, I assume that header compression will be employed, which compresses out the IPv6 header completely, so the IPv6 header overhead on such links is effectively zero in any case. Here is a list of *disadvantages* to increasing the IPv6 minimum MTU that have been raised, either publically or privately: (1) This change would require the specification of link-specific fragmentation and reassembly protocols for those link-layers that can support 576-byte packets but not 1280-byte packets, e.g., AppleTalk. I think such a protocol could be very simple, and I briefly sketch such a protocol in Appendix I of this message, as an example. Often, those links that have a small native MTU are also the ones that have low bandwidth. On low-bandwidth links, it is often desirable to locally fragment and reassemble IPv6 packets anyway (even 576-byte ones) in order to avoid having small, interactive packets (e.g., keystrokes, character echoes, or voice samples) be delayed excessively behind bigger packets (e.g., file transfers); the small packets can be interleaved with the fragments of the big packets. Someone mentioned in the meeting in Munich that the ISSLL WG was working on a PPP-specific fragmentation and reassembly protocol for precisely this reason, so maybe the job of specifying such a protocol is already being taken care of. (2) Someone raised the concern that, if we make the minimum MTU close to Ethernet size, implementors might never bother to implement PMTU Discovery. That would be regrettable, especially if the Internet evolves to much more widespread use of links with MTUs bigger than Ethernet's, since IPv6 would then fail to take advantage of the bandwidth efficiencies possible on larger MTU paths. (3) Peter Curran pointed out to me that using a larger minimum MTU for IPv6 may result in much greater reliance on *IPv4* fragmentation and reassembly during the transition phase while much of the IPv6 traffic is being tunneled over IPv4. This could incur unfortunate performance penalties for tunneled IPv6 traffic (disasterous penalties if there is non-negligible loss of IPv4 fragments). I have included Peter's message, describing his concern in more detail, in Appendix II of this message. (4) Someone expressed the opinion that the requirement for link-layer fragmentation and reassembly of IPv6 over low-cost, low-MTU links like Firewire, would doom the potential use of IPv6 in cheap consumer devices in which minimizing code size is important -- implementors of cheap Firewire devices would choose IPv4 instead, since it would not need a fragmenting "shim" layer. This may well be true, though I suspect the code required for local frag/reasm would be negligible compared to the code required for Neighbor Discovery. Personally, I am not convinced by the above concerns that increasing the minimum MTU would be a mistake, but I'd like to hear what the rest of the WG thinks. Are there other problems that anyone can think of? As I mentioned earlier, the clear consensus of the Munich attendees was to increase the minimum MTU, so we need to find out if these newly-identified problems are enough to swing the consensus in the other direction. Your feedback is heartily requested. Steve ---------- Appendix I Here is a sketch of a fragmentation and reassembly protocol (call it FRP) to be employed between the IP layer and the link layer of a link with nativ= e (or configured) MTU less than 1280 bytes. Identify a Block Size, B, which is the lesser of (a) the native MTU of the link or (b) a value related to the bandwidth of the link, chosen to bound the latency that one block can impose on a subsequent block. For example, to stay within a latency of 200 ms on a 9600 bps link, choose a block size of .2 * 9600 =3D 2400 bits =3D 240 bytes. IPv6 packets of length <=3D B are transmitted directly on the link. IPv6 packets of length > B are fragmented into blocks of size B (the last block possibly being shorter than B), and those fragments are transmitted on the link with an FRP header containing the following fields: [packet ID, block number, end flag] where: packet ID is the same for all fragments of the same packet, and is incremented for each new fragmented packet. The size of the packet ID field limits how many packets can be in flight or interleaved on the link at any one time. block number identifies the blocks within a packet, starting at block zero. The block number field must be large enough to identify 1280/B blocks. end flag is a one-bit flag which is used to mark the last block of a packet. For example, on a 9600 bps serial link, one might use a block size of 240 bytes and an 8-bit FRP header of the following format: 4-bit packet ID, which allows interleaving of up to 16 packets. 3-bit block number, to identify blocks numbered 0 through 5. 1-bit end flag. On a 256 kpbs AppleTalk link, one might use the AppleTalk-imposed block size of ~580 bytes and an 8-bit FRP header of the following format: 5-bit packet ID, which allows for up to 32 fragmented packets in flight from each source across the AppleTalk internet. 2-bit block number, to identify blocks numbered 0 through 2. 1-bit end flag. On a multi-access link, like AppleTalk, the receiver uses the link-level source address as well as the packet ID to identify blocks belonging to the same packet. If a receiver fails to receive all of the blocks of a packet by the time the packet number wraps around, it discards the incompletely-reassembled packet. Taking this approach, no timers should be needed at the receiver to detect fragment loss. We expect the transport layer (e.g., TCP) checksu= m at the final IPv6 destination to detect mis-assembly that might be caused b= y extreme misordering/delay during transit across the link. On links on which IPv6 header compression is being used, compression is performed before fragmentation, and reassembly is done before decompression= . ---------- Appendix II From: Peter Curran Subject: Re: IPv6 MTU issue To: deering@cisco.com (Steve Deering) Date: Mon, 22 Sep 1997 11:50:34 +0100 (BST) Steve My problem was that moving the MTU close to 1500 would have an adverse effect on the transition strategy. The current strategy assumes that the typical Internet MTU is >576, and that sending an IPv6 packet close to the minimum MTU will not require any IPv4 fragmentation to support the tunnel transparently. The PMTU discovery mechanism will 'tune' IPv6 to use a suitable MTU. If the IPv4 MTU is <=3D 576 then IPv4 fragmentation will be required to provide a tunnel with a minimum MTU of 576 for IPv6. This clearly places a significant strain on the tunnelling nodes - as these will normally be routers then there will be a demand for memory (for reassembly buffers) as well as CPU (for the frag/reassembly process) that will have an overall impact on performance. This is an acceptable risk, as Internet MTU's of <=3D 576 are not too commo= n. However, if the minimum MTU of IPv6 is increased to something of the order of 1200-1500 octets then the likelihood of finding an IPv4 path with an MTU lower than this value increases (I think significantly) and this will have a performance impact on these devices. During the brief discussion of this matter in the IPNG session at Munich you stated that MTU's less than 1500 where rare. I don't agree with this completely - it seems to be pretty common practise for smaller 2nd and 3rd tier ISP's in the UK to use an MTU of 576 for connection to their transit provider. Their objective, I believe, is to 'normalize' the packet sizes on relatively low bandwidth circuits (typically <1Mbps) to provide better performance for interactive sessions compared to bulk-file transfer users. I think that before we go ahead and make a decision on an increased minimum MTU for IPv6 then we should discuss the issues a little more. Incidentally, I am not convinced of the benefits of doing this anyway (ignoring the issue raised above). With a properly setup stack the PMTU discovery mechanism seems to be able to select a good MTU for use on the path - at least that is my experience on our test network and the 6Bone. I appreciate that you are trying to address the issues of PMTU for multi- casting but I don't see how raising the minumum MTU is going to help much. PMTU discovery will still be required irrespective of the minimum MTU adopted, unless we adopt a value that can be used on all link-layer technol= o- gies. I would welcome wider discussion of these issues before pressing ahead with a change. Best regards Peter Curran TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From sthaug@nethelp.no Mon Jul 1 09:31:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338FD21F9B8F for ; Mon, 1 Jul 2013 09:31:45 -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 NeuffzVpzFP2 for ; Mon, 1 Jul 2013 09:31:40 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 85FE621F9B22 for ; Mon, 1 Jul 2013 09:31:39 -0700 (PDT) Received: (qmail 27280 invoked from network); 1 Jul 2013 16:31:32 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 1 Jul 2013 16:31:32 -0000 Date: Mon, 01 Jul 2013 18:31:32 +0200 (CEST) Message-Id: <20130701.183132.78726456.sthaug@nethelp.no> To: Fred.L.Templin@boeing.com Subject: Re: draft-bonica-6man-frag-deprecate From: sthaug@nethelp.no In-Reply-To: <2134F8430051B64F815C691A62D983180B19B9@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983180B0221@XCH-BLV-504.nw.nos.boeing.com> <520FB317-19E8-4DCA-81FB-124B17732FE0@employees.org> <2134F8430051B64F815C691A62D983180B19B9@XCH-BLV-504.nw.nos.boeing.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:31:45 -0000 > > as far as I can see the setting IPv6 minimum MTU to 1280, which gives > > ample room for > > nested tunnels works as designed. > > But, what would that look like in real life? The first tunnel > (T1) would have to set a 1280 MTU so that its tunneled packets > would emerge as 1320 bytes. Then, the next tunnel (T2) would > have to set a 1320 MTU so its tunneled packets would emerge as > 1360. Then the next tunnel (T3) would have to set a 1360 MTU > so that its tunneled packets would emerge as 1400, etc. until > we run out of available MTU. The question is, how can those > tunnels be so carefully coordinated so that the nesting is > nailed down enough so that we will never have an MTU infraction? I strongly disagree that we should make provisions for umpteen levels of tunneling. In my network, native IPv6 with no tunnels is clearly the goal. Anything more than one level of tunneling is a *failure*. I run my IPv6 customer links with MTU 1500. > > the vendor I'm most familiar with does not do this in hardware. sure, > > you can get reassembly, but at an order of one or two magnitudes less. > > if anyone know of platforms doing IPv6 fragment reassembly at line rate > > for 10G or 100G interfaces I'll stand corrected. ;-) > > for now reassembly in the network is not realistic. > > Reassembly is required by RFC2460, RFC2473 and I think others > have also been mentioned. To support tunnels, and especially > tunnels within tunnels, it needs to be there. Reassembly is required by end systems, which typically don't run at 100G. If I were to vote with my wallet, reassembly at 100G and similar line rates is *way* down on my requirements list. Requiring L4 info in the first fragment (*and* in each subsequent fragment) is far more important. Steinar Haug, AS 2116 From Fred.L.Templin@boeing.com Mon Jul 1 09:48:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7FC11E8112 for ; Mon, 1 Jul 2013 09:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 DdRPtSlNyUiZ for ; Mon, 1 Jul 2013 09:48:06 -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 AC0B311E8143 for ; Mon, 1 Jul 2013 09:48:06 -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 r61Gm5JZ021317 for ; Mon, 1 Jul 2013 09:48:05 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r61Gm3Wr021265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 1 Jul 2013 09:48:04 -0700 Received: from XCH-EXCO-103.nw.nos.boeing.com (130.247.25.37) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 1 Jul 2013 09:48:04 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-EXCO-103.nw.nos.boeing.com ([fe80::7434:66d:a0ba:2234%15]) with mapi id 14.02.0328.011; Mon, 1 Jul 2013 09:48:03 -0700 From: "Templin, Fred L" To: "sthaug@nethelp.no" Subject: RE: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOdnhxUZaGJnzSMU6ZOUB9nA7EbJlQBFpw Date: Mon, 1 Jul 2013 16:48:02 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B1AC9@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983180B0221@XCH-BLV-504.nw.nos.boeing.com> <520FB317-19E8-4DCA-81FB-124B17732FE0@employees.org> <2134F8430051B64F815C691A62D983180B19B9@XCH-BLV-504.nw.nos.boeing.com> <20130701.183132.78726456.sthaug@nethelp.no> In-Reply-To: <20130701.183132.78726456.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:48:20 -0000 Hi Steinar, > -----Original Message----- > From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] > Sent: Monday, July 01, 2013 9:32 AM > To: Templin, Fred L > Cc: otroan@employees.org; ipv6@ietf.org > Subject: Re: draft-bonica-6man-frag-deprecate >=20 > > > as far as I can see the setting IPv6 minimum MTU to 1280, which > gives > > > ample room for > > > nested tunnels works as designed. > > > > But, what would that look like in real life? The first tunnel > > (T1) would have to set a 1280 MTU so that its tunneled packets > > would emerge as 1320 bytes. Then, the next tunnel (T2) would > > have to set a 1320 MTU so its tunneled packets would emerge as > > 1360. Then the next tunnel (T3) would have to set a 1360 MTU > > so that its tunneled packets would emerge as 1400, etc. until > > we run out of available MTU. The question is, how can those > > tunnels be so carefully coordinated so that the nesting is > > nailed down enough so that we will never have an MTU infraction? >=20 > I strongly disagree that we should make provisions for umpteen levels > of tunneling. In my network, native IPv6 with no tunnels is clearly > the goal. Anything more than one level of tunneling is a *failure*. Tunnels within tunnels are a fact of life in real networks today. Tunnels are used for many things other than transition, including security, mobility, routing control, etc. and deployment of IPv6 would sustain rather than reverse that trend. Plus, it is not just about tunnels within tunnels but also native links that configure a small MTU. Back to tunnels within tunnels, there are *many* examples that would prove my point but I will give just one. A mobile node configures a 1280 MTU tunnel to a "home agent" and keeps the tunnel alive as it moves around. A second mobile node comes onto the link provided by the first mobile, and also configures a 1280 MTU tunnel. The second mobile node emits a 1280 packet which (when tunneled) becomes 1320. The first mobile node drops the packet and returns "Packet Too Big". In response, the second mobile has two choices: 1) fragment, or 2) shut down the tunnel.=20 > I run my IPv6 customer links with MTU 1500. Good, but I would like to see you push that to 8KB. =20 > > > the vendor I'm most familiar with does not do this in hardware. > sure, > > > you can get reassembly, but at an order of one or two magnitudes > less. > > > if anyone know of platforms doing IPv6 fragment reassembly at line > rate > > > for 10G or 100G interfaces I'll stand corrected. ;-) > > > for now reassembly in the network is not realistic. > > > > Reassembly is required by RFC2460, RFC2473 and I think others > > have also been mentioned. To support tunnels, and especially > > tunnels within tunnels, it needs to be there. >=20 > Reassembly is required by end systems, which typically don't run at > 100G. Reassembly is also required by any node that configures an RFC2473 egress tunnel endpoint.=20 > If I were to vote with my wallet, reassembly at 100G and similar line > rates is *way* down on my requirements list. Two things about this is that 1) the location of the tunnel egress should be carefully selected, and 2) the SEAL tunnel egress can use RFC4821-style probing to tune out fragmentation when the path supports a sufficiently large MTU. SEAL is not about steady-state, use-all-the-time fragmentation; it is about doing what needs to be done while being as efficient as possible. > Requiring L4 info in the first fragment SEAL does that. > (*and* in each subsequent fragment) SEAL doesn't do that unless some new IPv6 extension header was defined. Then, SEAL would use the extension header the same as any other IPv6 protocol. > is far more important. Good; let's make it happen. Thanks - Fred fred.l.templin@boeing.com =20 > Steinar Haug, AS 2116 From Fred.L.Templin@boeing.com Mon Jul 1 12:44:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7C11E8258 for ; Mon, 1 Jul 2013 12:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 kHV9pBX1ohyF for ; Mon, 1 Jul 2013 12:44:28 -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 A78C421F9301 for ; Mon, 1 Jul 2013 12:43:55 -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 r61Jhs3E025430 for ; Mon, 1 Jul 2013 12:43:54 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r61JhrGb025416 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 1 Jul 2013 12:43:53 -0700 Received: from XCH-BLV-203.nw.nos.boeing.com (10.57.37.65) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 1 Jul 2013 12:43:53 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.169]) with mapi id 14.02.0328.011; Mon, 1 Jul 2013 12:43:53 -0700 From: "Templin, Fred L" To: Brian E Carpenter Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOdH/xI1L7sow7kkSTr5SDOLoWMJlP/xTAgAA87/A= Date: Mon, 1 Jul 2013 19:43:52 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B1CEF@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <51CDF8BF.6060002@gmail.com> <2134F8430051B64F815C691A62D983180B00B6@XCH-BLV-504.nw.nos.boeing.com> <51CE0D90.7090007@gmail.com> <2134F8430051B64F815C691A62D983180B02A3@XCH-BLV-504.nw.nos.boeing.com> <51CE6079.7060205@gmail.com> <2134F8430051B64F815C691A62D983180B19ED@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180B19ED@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:44:34 -0000 Hi, I would like to make one minor edit to what I have been saying: > The Internet will then > naturally gravitate toward larger packets, and eventually the > Internet "cell size" will bump up from 1500 to 8KB. I am not looking for a fixed "Internet cell size", and the 8KB I mentioned was intended more as a near term goal rather than a fixed size for the long term. What I am really looking for is an Internet that can support "unlimited" MTUs (theoretical limit is 2^16 for IPv4 and 2^32 for IPv6). Thanks - Fred fred.l.templin@boeing.com From bob.hinden@gmail.com Wed Jul 3 11:09:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446F721F93E1 for ; Wed, 3 Jul 2013 11:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWcBkNhMVFOp for ; Wed, 3 Jul 2013 11:09:24 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9161F21F93D1 for ; Wed, 3 Jul 2013 11:09:24 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id c4so257483eek.29 for ; Wed, 03 Jul 2013 11:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SI7ARd0yZvrd3k5SzvI/stQn2Kyy/ehRQ9I3wfNGAws=; b=UI4x2Y/vPFTz+5nKz/2q8eeoOiht/JwnQiR3nd6IMRr2cBoJxsJxsG7sJ2UA+sNdxi fKNdXOhSFCI0iQ5SB/0+eizakFo0dmd4HicNv7rvI16HvdUParlekNsQ6Et8eowMvM6Q vMRYF20rhJr1goNt0QFGXtYwEumSOGIG31r3Lc2pET5GfQuBDOD5D/7kL9bTd4XsMOkG fWEeZk3+4RbQQQV+WA3Yz88ubFbi+oKRUf+RfJEwuvrCv1HQODgZv7njKvK/luiA4flC A8Kf5hjGY9scwqHoQ2v1+/RQ3pRYpUuf6Lt4vBdFS+Dbdx5+aEqOz+fgvcslNnhz145p +7tw== X-Received: by 10.14.176.199 with SMTP id b47mr2201091eem.117.1372874962721; Wed, 03 Jul 2013 11:09:22 -0700 (PDT) Received: from ?IPv6:2601:9:4080:10:5031:b321:2ebd:47b7? ([2601:9:4080:10:5031:b321:2ebd:47b7]) by mx.google.com with ESMTPSA id n45sm45895352eew.1.2013.07.03.11.09.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 11:09:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Fwd: Draft submission deadlines change From: Bob Hinden Date: Wed, 3 Jul 2013 11:09:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> To: "ipv6@ietf.org 6man-wg" X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 18:09:25 -0000 FYI Begin forwarded message: > From: IETF Chair > Subject: Draft submission deadlines change > Date: July 2, 2013 10:17:01 PM PDT > To: IETF Announcement List > Reply-To: ietf@ietf.org >=20 > Please note that for IETF 87, there is only one deadline for draft = submission: Monday 15th July. Previously, there had been two different = deadlines, one for -00 and another one for other versions. The IESG has = decided to experiment with just one deadline for now to simplify the set = of deadlines and enable easier submission of new drafts. While we = realise that the change comes near the deadline, we hope that you find = the extra time useful. >=20 > But please do note that working group chairs will continue to make = smart decisions about what topics are worthwhile for discussing in a = session in the upcoming meeting, and will also set their agendas in a = timely manner and create deadlines for their working groups that must be = adhered to. The earlier new drafts are submitted, the more time there is = to talk about them on the mailing lists and consider them for the = session agendas. This is particularly important for BoFs. >=20 > Jari Arkko for the IESG From warren@kumari.net Wed Jul 3 16:58:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFC211E8108 for ; Wed, 3 Jul 2013 16:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDkgxJqix9fl for ; Wed, 3 Jul 2013 16:58:16 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53A811E8104 for ; Wed, 3 Jul 2013 16:58:15 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id 9F2A71B407D8; Wed, 3 Jul 2013 19:58:13 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [6MAN] [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) From: Warren Kumari In-Reply-To: Date: Wed, 3 Jul 2013 19:58:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <30729D62-6324-4E2F-8B8B-F3C55EC84252@kumari.net> References: <20130612174908.GT2504@Space.Net><51B6876A.9020202@si6networks.com><20130612003800.0374235C2E8B@drugs.dv.isc.org><51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu><10707.1371062690@perseus.noi.kre.to><51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net><51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1508) Cc: ipv6@ietf.org, "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 23:58:20 -0000 On Jun 14, 2013, at 6:00 PM, Warren Kumari wrote: >=20 > On Jun 14, 2013, at 2:56 PM, Doug Barton wrote: >=20 >> On 06/14/2013 01:39 AM, t.petch wrote: >>> ----- Original Message ----- >>> From: "Doug Barton" >>> To: >>> Sent: Thursday, June 13, 2013 9:23 PM >>>> On 06/13/2013 01:17 AM, Randy Bush wrote: >>>>>> FWIW, I don't think anyone has proposed "if the chain is larger >>> than X, >>>>>> then drop". >>>>>=20 >>>>> i am saying that i am telling my neighbor that, if the header = length >>> is >>>>> larger than X, it is likely that their packet will not propagate. >>> it's >>>>> an ops bcp statement, not a statement of ipv6 protocol definition. >>>>>=20 >>>>> same as telling them that a bgp announcement of a prefix longer = than >>> a >>>>> /24 likely will not propagete. >>>>>=20 >>>>> today, real routers really do drop packets with headers longer = than >>>>> various limits. as an op, i am trying to remove the surprise in = the >>>>> 'various'. >>>>=20 >>>> I agree with Randy, providing guidance on this topic will be very >>>> helpful, and BCP is the right category. >>>>=20 >>>> As for what the number should be, if 256 is in the 80th percentile = or >>>> higher of Warren's survey, that should be fine. A few vendors who = are >>>> examining less than that now may be encouraged to increase up to = 256 >>>> knowing that they have a reasonable upper bound to shoot for, as >>> opposed >>>> to an arbitrarily large number that varies from implementation to >>>> implementation. >>>=20 >>> I would like to check with current hardware designers that 256 is a = good >>> number for them, as opposed to 240, say. >>=20 >> Others (more knowledgeable than I) had already made that point, but = for the record, yes, we should check with the hardware folks on this. >=20 > I've already mentioned this in one of the N (where is is becoming = distressingly large) threads on this, but we are planning on: > A: adding something like this (you should be able to look N bytes / = headers in the packet) to the long headers draft (RSN, promise!) and / = or > B: writing an advice to implementers draft. RSN finally happened.=20 A new version of I-D, draft-wkumari-long-headers-01.txt has been successfully submitted by Warren Kumari and posted to the IETF repository. Filename: draft-wkumari-long-headers Revision: 01 Title: Operational Issues Associated With Long IPv6 Extension = Header Chains Creation date: 2013-07-04 Group: Individual Submission Number of pages: 8 URL: = http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt Status: = http://datatracker.ietf.org/doc/draft-wkumari-long-headers Htmlized: = http://tools.ietf.org/html/draft-wkumari-long-headers-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-wkumari-long-headers-01 Abstract: This document explains why IPv6 header chain length affects the cost of ASIC-based packet forwarding. It also explains why some network service providers discard packets with exceptionally long header chains. Finally, it identifies a reasonable header chain length. While a network service provider can enforce any filtering policy that supports its security model, a network service provider should not discard IPv6 packets based solely upon header chain length if the header chain is not longer than the value specified herein. Apologies all for how long this took, we kept getting pulled into other = things=85 W >=20 > One of the co-authors (Ron) of the long-headers draft works for = Juniper and has discussed this with their forwarding folk. We are also = having discussions with other vendors on the same topic, and will = hopefully have another author from at least one of the other large = chappies=85 >=20 > W >=20 >>=20 >>> What I mean is that 256 is a nice round number, for us as for them, = and >>> so is a natural choice. But sometimes that has to include red tape, >>> control information and such like, so what you get as a nice round >>> number is a bit less when you pass it on to the next level of >>> processing. Of course, with some hardware, that is built in, so = that >>> the hardware gets something greater and passes on a nice round = number to >>> its user (as with memory cards) but I have known occasions in the = past >>> when this was not the case and the choice of a nice round number = caused >>> problems. >>>=20 >>> Apart from that 'detail', I agree with the approach. >>>=20 >>> Tom Petch >>>=20 >>>> Doug >>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>>=20 >>>=20 >>>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -- > Credo quia absurdum est. >=20 >=20 >=20 --- Schizophrenia beats being alone. From warren@kumari.net Wed Jul 3 16:58:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6050011E8265 for ; Wed, 3 Jul 2013 16:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 zUTlgYq00dhn for ; Wed, 3 Jul 2013 16:58:29 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79F811E8267 for <6man@ietf.org>; Wed, 3 Jul 2013 16:58:26 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id B03501B407D8; Wed, 3 Jul 2013 19:58:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Fwd: New Version Notification for draft-wkumari-long-headers-01.txt From: Warren Kumari Date: Wed, 3 Jul 2013 19:58:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <40FF6567-5B8D-4C9F-A164-F2415B54BD79@kumari.net> References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> To: "6man@ietf.org" <6man@ietf.org> X-Mailer: Apple Mail (2.1508) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 23:58:34 -0000 Begin forwarded message: > A new version of I-D, draft-wkumari-long-headers-01.txt > has been successfully submitted by Warren Kumari and posted to the > IETF repository. >=20 > Filename: draft-wkumari-long-headers > Revision: 01 > Title: Operational Issues Associated With Long IPv6 = Extension Header Chains > Creation date: 2013-07-04 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt > Status: = http://datatracker.ietf.org/doc/draft-wkumari-long-headers > Htmlized: = http://tools.ietf.org/html/draft-wkumari-long-headers-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-wkumari-long-headers-01 >=20 > Abstract: > This document explains why IPv6 header chain length affects the cost > of ASIC-based packet forwarding. It also explains why some network > service providers discard packets with exceptionally long header > chains. Finally, it identifies a reasonable header chain length. > While a network service provider can enforce any filtering policy > that supports its security model, a network service provider should > not discard IPv6 packets based solely upon header chain length if = the > header chain is not longer than the value specified herein. >=20 -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they = can talk but choose not to do so in case humans put them to work, = possibly in the television industry. In fact they can talk. It's just = that they talk in Orang-utan. Humans are only capable of listening in = Bewilderment. -- Terry Practhett From Francis.Dupont@fdupont.fr Thu Jul 4 04:11:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891A921F9F8F for ; Thu, 4 Jul 2013 04:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r78ORAKmhKQ for ; Thu, 4 Jul 2013 04:11:03 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id CB40A21F9F58 for ; Thu, 4 Jul 2013 04:11:02 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r64BB19R058289; Thu, 4 Jul 2013 13:11:01 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201307041111.r64BB19R058289@givry.fdupont.fr> From: Francis Dupont To: Fernando Gont Subject: Re: Meta-issues: On the deprecation of the fragmentation function In-reply-to: Your message of Fri, 28 Jun 2013 23:53:41 +0200. <51CE05E5.4040202@si6networks.com> Date: Thu, 04 Jul 2013 13:11:01 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 11:11:03 -0000 In your previous mail you wrote: > Considering the above, I guess I'm in the camp of "avoid fragmentation > where possible". However, I don't think I'd go as far as deprecating it. => I have private notes about the deprecation of reassembly so not so far... BTW there was (still is) a TCP/IP stack so poor it doesn't handle reassembly of out of order TCP fragments, so the idea is not so silly. Regards Francis.Dupont@fdupont.fr From marc.lampo.ietf@gmail.com Thu Jul 4 22:49:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3675921F940D for ; Thu, 4 Jul 2013 22:49: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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7PrmNaSrdNk for ; Thu, 4 Jul 2013 22:49:25 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD121F9256 for ; Thu, 4 Jul 2013 22:49:24 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gf11so1371451vcb.11 for ; Thu, 04 Jul 2013 22:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iWxSqwxroXGsguROSsH175eO+cze0mLnQQq4KDDYRqk=; b=V1F3LlcxWMin5hxOunGLAC3MQtPhKn66n6bOIc5jX8UEHtMaiB3xtAZ4aYcVrfR+Ss 5WS604xGwnsglRWwfyoOg982OZMGqtg5tmj4oOX+HSnMA1MJ43Vkl4KSZh++8K0kmMSU iWevIAZceYQnoAwCpU5yR2sr2znmImMJE8pvuYGi0GM3GgciRJnQknzr0rTogY+wobrH MvEMrVnoRDz4b4Zk2BN51uHzmxCa/2NVOsjJDdvKN3WWUC4Ta/cojGx6+3KcmvMF2eJI zy8m5kwv2DipWGNHuLW02pssNAY1ltLKaAMbEgWaYUYP3Gxax5qZUD2UfQ04JcYELIoh uydg== MIME-Version: 1.0 X-Received: by 10.58.204.195 with SMTP id la3mr5415852vec.66.1373003363352; Thu, 04 Jul 2013 22:49:23 -0700 (PDT) Received: by 10.59.2.101 with HTTP; Thu, 4 Jul 2013 22:49:23 -0700 (PDT) In-Reply-To: <201307041111.r64BB19R058289@givry.fdupont.fr> References: <51CE05E5.4040202@si6networks.com> <201307041111.r64BB19R058289@givry.fdupont.fr> Date: Fri, 5 Jul 2013 07:49:23 +0200 Message-ID: Subject: Re: Meta-issues: On the deprecation of the fragmentation function From: Marc Lampo To: Francis Dupont Content-Type: multipart/alternative; boundary=047d7bd76d7ebf912f04e0bd414b Cc: Fernando Gont , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 05:49:26 -0000 --047d7bd76d7ebf912f04e0bd414b Content-Type: text/plain; charset=ISO-8859-1 let's write a draft on deprecating the statement, from RFC 793, that The TCP must recover from data that is ... delivered out of order by the internet communication system. (my feeling : just like this would actually create a new, incompatible, transport protocol; deprecating the fragmentation extension header creates a new, incompatible to IPv6, network protocol) Kind regards, Marc On Thu, Jul 4, 2013 at 1:11 PM, Francis Dupont wrote: > In your previous mail you wrote: > > > Considering the above, I guess I'm in the camp of "avoid fragmentation > > where possible". However, I don't think I'd go as far as deprecating it. > > => I have private notes about the deprecation of reassembly so > not so far... BTW there was (still is) a TCP/IP stack so poor it > doesn't handle reassembly of out of order TCP fragments, so the idea > is not so silly. > > Regards > > Francis.Dupont@fdupont.fr > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7bd76d7ebf912f04e0bd414b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
let's write a draft on deprecating the statement, from= RFC 793, that
The TCP must recover from data that is ..=
.
    delivered out of order by the internet communication system.

(my feeling :
=A0just like this would actu=
ally create a new, incompatible, transport protocol;

=A0deprecating the fragmentation extension header creates a new, incompatib=
le to IPv6, network protocol)


K=
ind regards,

Marc



On Thu, Jul 4, 2013 at 1:11 PM, Francis Dupont <Francis.Dupont@fdu=
pont.fr> wrote:


=A0In your previous mail you wrote:



> =A0Considering the above, I guess I'm in the camp of "avoid f=
ragmentation

> =A0where possible". However, I don't think I'd go as far =
as deprecating it.




=3D> I have private notes about the deprecation of reassembly so
not so far... BTW there was (still is) a TCP/IP stack so poor it

doesn't handle reassembly of out of order TCP fragments, so the idea
is not so silly.



Regards



Francis.Dupont@fdupont.fr<=
br>

-----------------------------------=
---------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

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

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

--047d7bd76d7ebf912f04e0bd414b-- From fgont@si6networks.com Fri Jul 5 07:47:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16D211E82CD for ; Fri, 5 Jul 2013 07:47:15 -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 3Xp6LZCYas3W for ; Fri, 5 Jul 2013 07:47:15 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 23AE511E8286 for ; Fri, 5 Jul 2013 07:47:15 -0700 (PDT) Received: from [186.134.55.157] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uv7I0-000876-0A; Fri, 05 Jul 2013 16:47:13 +0200 Message-ID: <51D6C710.6090908@si6networks.com> Date: Fri, 05 Jul 2013 15:16:00 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Francis Dupont Subject: Re: Meta-issues: On the deprecation of the fragmentation function References: <201307041111.r64BB19R058289@givry.fdupont.fr> In-Reply-To: <201307041111.r64BB19R058289@givry.fdupont.fr> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 14:47:15 -0000 On 07/04/2013 01:11 PM, Francis Dupont wrote: > In your previous mail you wrote: > >> Considering the above, I guess I'm in the camp of "avoid fragmentation >> where possible". However, I don't think I'd go as far as deprecating it. > > => I have private notes about the deprecation of reassembly so > not so far... BTW there was (still is) a TCP/IP stack so poor it > doesn't handle reassembly of out of order TCP fragments, so the idea > is not so silly. If you're going to deprecate something on the assumption that some implementation does something stupid about it, then I wonder what we'd be left with. -- for instance, you should be deprecating Neighbor Discovery, because many implementations do things such as allowing the NCE to consume all memory, not doing any sanity checks on the received link-layer addresses, etc., etc. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Fri Jul 5 08:00:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FFC21F9E08 for ; Fri, 5 Jul 2013 08:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ZaJpt2Wg0WfV for ; Fri, 5 Jul 2013 08:00:04 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 78ACE21F9DE6 for ; Fri, 5 Jul 2013 08:00:04 -0700 (PDT) Received: from [186.134.55.157] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uv7UL-0008NE-1k; Fri, 05 Jul 2013 16:59:58 +0200 Message-ID: <51D6DF54.9030304@si6networks.com> Date: Fri, 05 Jul 2013 16:59:32 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "C. M. Heard" Subject: Re: Meta-issues: On the deprecation of the fragmentation function References: <51CE05E5.4040202@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <51C98103.4050008@fud.no> <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> <20130625233717.618C53642429@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:00:05 -0000 On 06/30/2013 10:42 PM, C. M. Heard wrote: > Fernando> So far (and without having read Ron's recent I-D -- shame on me), it > Fernando> looks like the main two reasons for deprecating the fragmentation > Fernando> function are: > Fernando> > Fernando> 1) The inability of middle-boxes to parse past the first XXX bytes of a > Fernando> packet > Fernando> > Fernando> 2) Unavailability of the connection-id (five-tuple) in the non-first > Fernando> fragments. > > I disagree -- I think Mark Andrews got it (mostly) right in his message of Wed, 26 Jun 2013: > > Mark> One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment. Do you have this in IPv4? -- No. Then, why is it that special in v6? > However, it won't help middle boxes that implement stateless packet filters. Indeed, such > boxes have fundamental problems with non-first fragments irrespective of how many bytes of > extension headers they can parse or whether there are sufficient length limits on the extension > header chain that guarantee that the L4 header always appears in the first fragment. If you want to do stateless filtering, you should focus on filtering the first fragment. And have the end nodes (severs or whatever) implement sensible garbage collection for queued fragments (as it's usually the case). > As I see it, the biggest meta-issue in this discussionis for the IPv6 WG is to decide out whether > middle boxes that implement stateless packet filters with a "default-deny" policy will be a > significant part of the landscape indefinitely, regardless of what the IETF says about their > merits or lack thereof. Again: Why is this more special in v6 than in v4? -- You seem to be ignored the "questions" that I've asked. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From albert.e.manfredi@boeing.com Fri Jul 5 13:23:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D337E21F9FCF for ; Fri, 5 Jul 2013 13:23:07 -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 EaD+5iArbs8c for ; Fri, 5 Jul 2013 13:23:01 -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 994F121F9F4F for ; Fri, 5 Jul 2013 13:23:01 -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 r65KN07f022590 for ; Fri, 5 Jul 2013 15:23:00 -0500 Received: from XCH-PHX-201.sw.nos.boeing.com (xch-phx-201.sw.nos.boeing.com [137.136.238.12]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r65KMvX1022579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 5 Jul 2013 15:22:58 -0500 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.45]) by XCH-PHX-201.sw.nos.boeing.com ([169.254.1.221]) with mapi id 14.02.0328.011; Fri, 5 Jul 2013 13:22:57 -0700 From: "Manfredi, Albert E" To: Fernando Gont Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOeY6SRRfQ7VoN4UKig8aCMjk6VplWhlNg Date: Fri, 5 Jul 2013 20:22:56 +0000 Message-ID: <021E64FECA7E5A4699562F4E667164810B463771@XCH-PHX-503.sw.nos.boeing.com> References: <201307041111.r64BB19R058289@givry.fdupont.fr> <51D6C710.6090908@si6networks.com> In-Reply-To: <51D6C710.6090908@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 20:23:07 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > If you're going to deprecate something on the assumption that some > implementation does something stupid about it, then I wonder what we'd > be left with. -- for instance, you should be deprecating Neighbor > Discovery, because many implementations do things such as allowing the > NCE to consume all memory, not doing any sanity checks on the received > link-layer addresses, etc., etc. The more I read arguments pro and con, the less I think fragmentation shoul= d be deprecated. Even in IPv4, fragmentation is always discouraged, but there are times when= it comes in very handy. I'm honestly not sure why anything should be diffe= rent, in this regard, with IPv6. The more differences IPv6 introduces, the = more of a complete nuisance it becomes. Bert From marka@isc.org Fri Jul 5 19:06:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA411E80EC for ; Fri, 5 Jul 2013 19:06:21 -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 vtqTPg0AfNTA for ; Fri, 5 Jul 2013 19:06:16 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D98F811E80AE for ; Fri, 5 Jul 2013 19:06:16 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 210CEC94FF; Sat, 6 Jul 2013 02:06:07 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1373076376; bh=8JfSnfkdIl+z7nzdj9bv3bv6PbgzgGwMLDAJOD9cmig=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ZV6a8T8pWC772rrVqCjiAdnmi6km/Aw5XJF6LmGOjvC6ehkowzm+UFGzydtFg9/oo t/MeBtVe8Q2dLjwLijEcShSa359oLYYSfvsJ+ttao0v2pHkJVZZxl73fltZa7uHeaN z6/2z4jmg0Pdb206IQDxTcv7rXVTuf/adPUoH4VU= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 6 Jul 2013 02:06:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 20F73160105; Sat, 6 Jul 2013 02:08:01 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qubzoJ7pT5pu; Sat, 6 Jul 2013 02:07:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D2F8F160104; Sat, 6 Jul 2013 02:07:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ow13z3-6zqcv; Sat, 6 Jul 2013 02:07:58 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 484DB160103; Sat, 6 Jul 2013 02:07:58 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 61F4736F1E1F; Sat, 6 Jul 2013 12:05:57 +1000 (EST) To: Fernando Gont From: Mark Andrews References: <51CE05E5.4040202@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <51C98103.4050008@fud.no> <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> <20130625233717.618C53642429@drugs.dv.isc.org> <51D6DF54.9030304@si6networks.com> Subject: Re: Meta-issues: On the deprecation of the fragmentation function In-reply-to: Your message of "Fri, 05 Jul 2013 16:59:32 +0200." <51D6DF54.9030304@si6networks.com> Date: Sat, 06 Jul 2013 12:05:56 +1000 Message-Id: <20130706020557.61F4736F1E1F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "C. M. Heard" , IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 02:06:21 -0000 In message <51D6DF54.9030304@si6networks.com>, Fernando Gont writes: > On 06/30/2013 10:42 PM, C. M. Heard wrote: > > Fernando> So far (and without having read Ron's recent I-D -- shame on me), > it > > Fernando> looks like the main two reasons for deprecating the fragmentation > > Fernando> function are: > > Fernando> > > Fernando> 1) The inability of middle-boxes to parse past the first XXX > > Fernando> bytes of a packet > > Fernando> > > Fernando> 2) Unavailability of the connection-id (five-tuple) in the > > Fernando> non-first fragments. > > > > I disagree -- I think Mark Andrews got it (mostly) right in his message of > > Wed, 26 Jun 2013: > > > > Mark> One needs to get the L4 information the firewall/loadbalancer uses in > > *each* fragment. > > Do you have this in IPv4? -- No. > > Then, why is it that special in v6? It's not special in IPv6. It is however easily *fixable* in IPv6 as the IPv6 packet format was designed to extended. Additionally IPv6 is the future and we are still very early into the lifetime of IPv6. If one wants to extend IPv4 to have similar capabilities go for it. I just think doing so will be wasted effort but I'm not going to stand in the way of someone that wants to do it. > > However, it won't help middle boxes that implement stateless packet > > filters. Indeed, such boxes have fundamental problems with non-first > > fragments irrespective of how many bytes of extension headers they can > > parse or whether there are sufficient length limits on the extension > > header chain that guarantee that the L4 header always appears in the > > first fragment. > > If you want to do stateless filtering, you should focus on filtering the > first fragment. And have the end nodes (severs or whatever) implement > sensible garbage collection for queued fragments (as it's usually the case). Which is what I do but it doesn't help with those that worry about those non initial fragments filling pipes and reassembly queues to the point where legitimate fragments that they want get discarded too soon. We need to be able to better classify non-initial fragments. At the moment we are classifying them to the L4 type (tcp, udp, icmp6, ipv6, ipv4, etc.) > > As I see it, the biggest meta-issue in this discussionis for the IPv6 > > WG is to decide out whether middle boxes that implement stateless packet > > filters with a "default-deny" policy will be a significant part of the > > landscape indefinitely, regardless of what the IETF says about their > > merits or lack thereof. > > Again: Why is this more special in v6 than in v4? > > -- You seem to be ignored the "questions" that I've asked. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ietf@rozanak.com Sun Jul 7 14:10:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E9711E8110 for ; Sun, 7 Jul 2013 14:10: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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xuo8Jk26xKNe for ; Sun, 7 Jul 2013 14:10:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 01C2911E810C for ; Sun, 7 Jul 2013 14:10:13 -0700 (PDT) Received: from kopoli (e179165227.adsl.alicedsl.de [85.179.165.227]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Megzo-1UXe4X3D9E-00OvjB; Sun, 07 Jul 2013 17:10:10 -0400 From: "Hosnieh Rafiee" To: Subject: I-D action : RA- based privacy - an update to RFC 4941 Date: Sun, 7 Jul 2013 23:09:44 +0200 Message-ID: <004b01ce7b56$5b31fe50$1195faf0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01CE7B67.1EBCCA20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac57VWiGa5o9PkzKSLm0VOnc6VEkMQ== Content-Language: en-us X-Provags-ID: V02:K0:YCDqoWl2GA2q8zF70Lt9WayGKrzAT9GRhqiosiWQ+sV qit44qQq2qQPHVH2bUv9VznUwfTWUXw6buWwHn6r/CRPkTopJn ft0NYKSX6Ul7SqxNItvqSDq5E2Y+giAMUTRnTX+76YVAlVotKz 4yjzF2w2lqiUZFRfmVuuCLFGZVJq59/MQMtQYTAlmoHshqEls6 s/NIpCm+ukX/fHWIyNtmAXu6B3gG0yKCCyG+QmbSr4oLQaIHaW RSdJyqsRlfVpndWFXxgowb34pIiJiAuWjkL5hvThV3VuvApmER v3hivnGYKx6vq8PLPpsNx2xVB86lPC704U1YwYB68hm+mV7bdP gMOVHUczo5mnHEp765uk= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 21:10:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004C_01CE7B67.1EBCCA20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Any comments or suggestions before IETF meeting? For those of you who haven't read it yet, in brief, it offers an improvement to the deficiencies present in RFC 4941. In the introduction the purpose of this update is clearly explained. http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy Best, Hosnieh ------=_NextPart_000_004C_01CE7B67.1EBCCA20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

Any = comments or suggestions before IETF meeting? For those of you who = haven't read it yet, in brief, it offers an improvement to the = deficiencies present in RFC 4941. In the introduction the purpose of = this update is clearly explained.

 

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

 

Best,

Hosnieh

 

------=_NextPart_000_004C_01CE7B67.1EBCCA20-- From rbonica@juniper.net Sun Jul 7 14:46:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3364B11E8132 for ; Sun, 7 Jul 2013 14:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.467 X-Spam-Level: X-Spam-Status: No, score=-101.467 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB1roN5OmbKk for ; Sun, 7 Jul 2013 14:46:23 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 373DE11E8123 for ; Sun, 7 Jul 2013 14:46:21 -0700 (PDT) Received: from mail144-co9-R.bigfish.com (10.236.132.246) by CO9EHSOBE009.bigfish.com (10.236.130.72) with Microsoft SMTP Server id 14.1.225.22; Sun, 7 Jul 2013 21:46:20 +0000 Received: from mail144-co9 (localhost [127.0.0.1]) by mail144-co9-R.bigfish.com (Postfix) with ESMTP id 62F563A00B2 for ; Sun, 7 Jul 2013 21:46:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz17326ah18602eh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail144-co9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail144-co9 (localhost.localdomain [127.0.0.1]) by mail144-co9 (MessageSwitch) id 1373233577787305_7639; Sun, 7 Jul 2013 21:46:17 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.244]) by mail144-co9.bigfish.com (Postfix) with ESMTP id B40F98005A for ; Sun, 7 Jul 2013 21:46:17 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 7 Jul 2013 21:46:16 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 7 Jul 2013 14:46:15 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Sun, 7 Jul 2013 14:46:15 -0700 Received: from CO9EHSOBE029.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 7 Jul 2013 14:50:04 -0700 Received: from mail160-co9-R.bigfish.com (10.236.132.248) by CO9EHSOBE029.bigfish.com (10.236.130.92) with Microsoft SMTP Server id 14.1.225.22; Sun, 7 Jul 2013 21:46:14 +0000 Received: from mail160-co9 (localhost [127.0.0.1]) by mail160-co9-R.bigfish.com (Postfix) with ESMTP id AF84A2E02BC for ; Sun, 7 Jul 2013 21:46:14 +0000 (UTC) Received: from mail160-co9 (localhost.localdomain [127.0.0.1]) by mail160-co9 (MessageSwitch) id 13732335733059_10177; Sun, 7 Jul 2013 21:46:13 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.228]) by mail160-co9.bigfish.com (Postfix) with ESMTP id F1C39C005F for ; Sun, 7 Jul 2013 21:46:12 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 7 Jul 2013 21:46:12 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.72]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0329.000; Sun, 7 Jul 2013 21:46:12 +0000 From: Ronald Bonica To: "ipv6@ietf.org" Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: Ac57W2R7CV12aalQR0ONSXITtNZaPQ== Date: Sun, 7 Jul 2013 21:46:10 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F9532C@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 21:46:29 -0000 Folks, I have just received private communication from someone associated with htt= p://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf= . He informs me that I may have misinterpreted the paper's results. Specifically, packets fragmented to 1280 bytes were filtered on only 10% of= paths. However, packets fragmented to 1496 bytes were lost on ~40% of path= s. In the next few days, I will post an updated version of the draft with the= authors' comments. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From sarikaya2012@gmail.com Mon Jul 8 10:06:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F5D21F9D2B for ; Mon, 8 Jul 2013 10:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cqhTs0-Z1dP for ; Mon, 8 Jul 2013 10:06:17 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEC321F9D01 for <6man@ietf.org>; Mon, 8 Jul 2013 10:06:14 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fn20so4019462lab.14 for <6man@ietf.org>; Mon, 08 Jul 2013 10:06:12 -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:content-type; bh=ezBJ3rF0XIokr+5OcNyH1DOlwGGNPrWeM7bBIUG8B+s=; b=lWUN/eBx/pflkdH3+/kGJT0ckpNc3rTEiJq+oJxW39Wcs9G0CJR1pnzC5mwaCk0VaF jESRcBLhK+NkfhA1gnE477BaAJxNAM2Rr6/NJwQmHUhuRzOSwX96r4xUPKIMyYCp0QWC Rl2i8P47MgbM9HeeAsiaBb/geBaRkQT+m7qzH/1DNHR/cbw/oO3zWQs4R03aJxPLXuoM scIQN8Kn3/yj5LWn5DS0sG9QZufhUZHROlAahBWyq0fuxKGaXMR4BsMu1Q5152bVypOF dJGfXmKkvBXqqVdS5gJ1pgaxNWdBhMLmY6mmVc6Nv4Hd/x9H1rkqstLKhb5yrqURC2tC MA/Q== MIME-Version: 1.0 X-Received: by 10.152.120.105 with SMTP id lb9mr11026113lab.20.1373303172868; Mon, 08 Jul 2013 10:06:12 -0700 (PDT) Received: by 10.114.176.37 with HTTP; Mon, 8 Jul 2013 10:06:12 -0700 (PDT) In-Reply-To: <20130708170331.21564.5258.idtracker@ietfa.amsl.com> References: <20130708170331.21564.5258.idtracker@ietfa.amsl.com> Date: Mon, 8 Jul 2013 12:06:12 -0500 Message-ID: Subject: New Version Notification for draft-sarikaya-6man-rfc4191bis-00.txt From: Behcet Sarikaya To: 6man@ietf.org Content-Type: multipart/alternative; boundary=089e0122868ac9b1d804e1030f52 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:06:18 -0000 --089e0122868ac9b1d804e1030f52 Content-Type: text/plain; charset=ISO-8859-1 A new version of I-D, draft-sarikaya-6man- > > rfc4191bis-00.txt > has been successfully submitted by Behcet Sarikaya and posted to the > IETF repository. > > Filename: draft-sarikaya-6man-rfc4191bis > Revision: 00 > Title: IPv6 RA Options for Next Hop Routes > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-sarikaya-6man-rfc4191bis-00.txt > Status: > http://datatracker.ietf.org/doc/draft-sarikaya-6man-rfc4191bis > Htmlized: > http://tools.ietf.org/html/draft-sarikaya-6man-rfc4191bis-00 > > > Abstract: > This proposes an update on RFC 4191 in order to define new Router > Advertisement options for configuring next hop routes on the mobile > or fixed nodes. Using these options, an operator can easily > configure nodes with multiple interfaces (or otherwise multi-homed) > to enable them to select the routes to a destination. Each option is > defined together with definitions of host and router behaviors. --089e0122868ac9b1d804e1030f52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A new version of I-D, draft-sarikaya-6man-
rfc4191bis-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sarikaya-6man-rfc4191bis
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 IPv6 RA Options for Next Hop Routes
Creation date: =A0 2013-07-08
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 15
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.o= rg/internet-drafts/draft-sarikaya-6man-rfc4191bis-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/do= c/draft-sarikaya-6man-rfc4191bis
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-s= arikaya-6man-rfc4191bis-00


Abstract:
=A0 =A0This proposes an update on RFC 4191 in order to define new Router =A0 =A0Advertisement options for configuring next hop routes on the mobile<= br> =A0 =A0or fixed nodes. =A0Using these options, an operator can easily
=A0 =A0configure nodes with multiple interfaces (or otherwise multi-homed)<= br> =A0 =A0to enable them to select the routes to a destination. =A0Each option= is
=A0 =A0defined together with definitions of host and router behaviors.
--089e0122868ac9b1d804e1030f52-- From rja.lists@gmail.com Tue Jul 9 08:02:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CCB21F8ECE for ; Tue, 9 Jul 2013 08:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIIKZKOdVSY0 for ; Tue, 9 Jul 2013 08:02:24 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 663AF21F93B9 for ; Tue, 9 Jul 2013 08:02:22 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so2978245qab.11 for ; Tue, 09 Jul 2013 08:02:18 -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=Wp1kBTsprnUNKKeypD5DWGyf0wkujsftP0wKA093W7g=; b=DxepoymFoO9aqg4BJ45SWFDYmrCncr7O+RDnjR6bHu8nz0LKN+2kNZc3wGCSa8aM0M hdvdYVAk2TNy/POJHUxMahGrQtOwobIHwu/szvJgecOu6j46hykbrjfsS9phiV1vg5Rk avpfWOUXn5U92L0nbNEZqy1t0xSmiCN6KTayZOyAUylG1rYBh3W+GXh8PGx0n23ChJLV +ESzEoIBRnR875dxCV/ea3bzuyYaKmRuiTSpHcL2gJp3AHmsZVQ6kIKP6IvJjwMldU3b r2w9qHqWPw1mk21CTtO5A9rgjQ53IjPuohOcLaWU4SJkbNjvt8aUsLf4yuW6DHGUyR8M ZrUg== X-Received: by 10.49.35.233 with SMTP id l9mr21733145qej.23.1373382138712; Tue, 09 Jul 2013 08:02:18 -0700 (PDT) Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id o10sm19743624qax.13.2013.07.09.08.02.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 08:02:17 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: Meta-issues: On the deprecation of the fragmentation function Date: Tue, 9 Jul 2013 11:02:16 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:02:25 -0000 All, I think everyone agrees that intermediate fragmentation (e.g. by routers having high-speed links in the middle of the path) can be problematic,and that is why IPv6 does NOT require that (i.e. RFC-2460 says that the "DF" bit is invisible but always set for IPv6). That noted, I agree very much with Fernando Gont's comments on 5th July 2013 that IPv6 fragmentation in end systems ought NOT be deprecated -- and I find his reasoning compelling. (SEPARATELY) Not all deployed links are built out of wired/wireless Ethernet or SONET. The assumption that everything is either Ethernet or SONET (or perhaps WDM) is a bit of a "First World" assumption and puts lesser-developed countries/regions at a significant disadvantage for Internet access. Frankly it is embarrassing for IETF participants to make such an assumption (i.e. that all links are Ethernet, SONET, WDM, or better). While it is fine to optimise so that Ethernet or SONET links have great performance, for example by eliminating the requirement for backbone routers to fragment packets, we ought to retain the ancient "IP OVER EVERYTHING" mantra that has served the Internet (and ALL regions of the world) so well for so many years now. I know of a number of link technologies that simply can't support the existing 1280 byte minimum IPv6 MTU. Links with the lower MTU overwhelmingly are relatively low speed wireless links (everything in the gamut from HF radio to SATCOM). My concerns about this have been expressed in IPv6 WG meetings dating back to the early 1990s, as IETF meeting minutes show. All the data available to me indicates that these lower-speed (and smaller MTU) links are NOT going away. For HF radio links, link transmission speed is usually measured in Kbps, with some deployed IPv4/HF links today running as low as 2.4 Kbps. VHF and UHF line-of-sight links tend to be much faster than HF, but are still well below the slowest modern Ethernet link (i.e. 10 Mbps). The IPv6 concept of adding a special link-specific fragmentation/reassembly protocol layer has never been practical. By definition, these links have severe bandwidth limitations already. I've seen multiple instances where specialised routers that are connected to these LOW speed links insert IPv6 Fragmentation Headers and perform intermediate fragmentation to get IPv6 packets through such links. In these special cases, there is no performance issue because these wireless links have such low data rates. A result of deprecating the IPv6 Fragmentation Header will be that such links will be running IPv4 *forever*. This is the opposite of encouraging IPv6 transition -- it is preventing IPv6 transition. It also probably requires the ongoing deployment of IPv6::IPv4 protocol translation gateways -- and also probably inhibits Internet deployment outside of "1st World" countries. Sigh. Deprecating IPv6 Fragmentation Header and related end-system support is going to harm users and inhibit transition to IPv6. PLEASE, PLEASE, let us NOT go there. Sincerely Yours, Ran Atkinson From randy@psg.com Tue Jul 9 09:24:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC37D21F9D11 for ; Tue, 9 Jul 2013 09:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szspTwgGoZ00 for ; Tue, 9 Jul 2013 09:24:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5063C21F9CFE for ; Tue, 9 Jul 2013 09:24:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UwaiR-0000sI-M0; Tue, 09 Jul 2013 16:24:35 +0000 Date: Tue, 09 Jul 2013 06:24:35 -1000 Message-ID: From: Randy Bush To: RJ Atkinson Subject: Re: Meta-issues: On the deprecation of the fragmentation function In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:24:46 -0000 > Not all deployed links are built out of wired/wireless > Ethernet or SONET. The assumption that everything is either > Ethernet or SONET (or perhaps WDM) is a bit of a "First > World" assumption and puts lesser-developed countries/regions > at a significant disadvantage for Internet access. my small experience is that there are no technologies unique to the Nth world. we all buy and use the same crap from the carriers, vendors, ... From bjones@vt.edu Tue Jul 9 08:17:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC8821F9B1B for ; Tue, 9 Jul 2013 08:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK9sVCN2xioa for ; Tue, 9 Jul 2013 08:17:13 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietfa.amsl.com (Postfix) with ESMTP id 84EAA21F9BD8 for ; Tue, 9 Jul 2013 08:17:12 -0700 (PDT) Received: from dagger.cc.vt.edu (dagger.cc.vt.edu [198.82.163.114]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r69FGfHF016517 for ; Tue, 9 Jul 2013 11:16:41 -0400 Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by dagger.cc.vt.edu (MOS 4.3.3-GA) with ESMTP id CFI76605; Tue, 9 Jul 2013 11:16:41 -0400 X-Mirapoint-Received-SPF: 209.85.128.48 mail-qe0-f48.google.com 0 softfail Received: by mail-qe0-f48.google.com with SMTP id 2so3051354qea.21 for ; Tue, 09 Jul 2013 08:16:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=/SoHFT1+GBePxIH6bDHawrnPDyRgTzygJotpAwoyYNQ=; b=B4B9VQOroRrZMCcgxH2IGyMNghI5Ll3FNCCJVw6VcIJ4kBg5Gal6MG2sbR0hRq7Io9 rPeCny6MnjXh28OkyTxCGQx5tmLlNe/Smsyya83a1TsAF6XwtLnZjlnk1PMfqHM2muxS sefmhE+QpV/hOQYW8x/FSK5NLDFVLtcNqQB3wklA2voKDOvz075yShFxX34q+EjDrtsA wdM3KzIkGU4PeQ0Ob/5h4Elvh4UrnWoa16/60IzCBrT4cxY+6MfYURUXeHBXPcAI+8E7 WnOMXZjl6XQZa1Gi/6+bMXSQqt5RBZIucjrBBF03JJA7WC9G64kGgORXqcqDbDmJZQ6+ W+5Q== X-Received: by 10.224.79.203 with SMTP id q11mr24262343qak.35.1373383001160; Tue, 09 Jul 2013 08:16:41 -0700 (PDT) X-Received: by 10.224.79.203 with SMTP id q11mr24262336qak.35.1373383001091; Tue, 09 Jul 2013 08:16:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.197 with HTTP; Tue, 9 Jul 2013 08:16:20 -0700 (PDT) In-Reply-To: References: From: Brian Jones Date: Tue, 9 Jul 2013 11:16:20 -0400 Message-ID: Subject: Re: Meta-issues: On the deprecation of the fragmentation function To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=047d7bdca7f0ebbb9404e115a5ee X-Gm-Message-State: ALoCoQlQreRLmI4yzI9WPTtkKZ4Ci7H+e7fwi9TSJQIGx3GXdpJVn2w/vEn8yCE+jbpISQrJcRhMiw9CdIZgO1jbCxXnguwPIbDohLthWHp21ZSCUvsgIEQcjruKgHp+haN5T2ouijwB X-Mailman-Approved-At: Tue, 09 Jul 2013 09:25:19 -0700 Cc: RJ Atkinson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bjones@vt.edu List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:17:23 -0000 --047d7bdca7f0ebbb9404e115a5ee Content-Type: text/plain; charset=UTF-8 +1 - All of RJ's comments. There has to be a solution that not only allows for but encourages IPv6 deployment, not prevents it. -- Brian On Tue, Jul 9, 2013 at 11:02 AM, RJ Atkinson wrote: > All, > > I think everyone agrees that intermediate fragmentation > (e.g. by routers having high-speed links in the middle of the path) > can be problematic,and that is why IPv6 does NOT require that > (i.e. RFC-2460 says that the "DF" bit is invisible but always > set for IPv6). > > That noted, I agree very much with Fernando Gont's > comments on 5th July 2013 that IPv6 fragmentation in > end systems ought NOT be deprecated -- and I find his > reasoning compelling. > > > (SEPARATELY) > > Not all deployed links are built out of wired/wireless > Ethernet or SONET. The assumption that everything is either > Ethernet or SONET (or perhaps WDM) is a bit of a "First > World" assumption and puts lesser-developed countries/regions > at a significant disadvantage for Internet access. > > Frankly it is embarrassing for IETF participants to make > such an assumption (i.e. that all links are Ethernet, > SONET, WDM, or better). > > While it is fine to optimise so that Ethernet or SONET links > have great performance, for example by eliminating the > requirement for backbone routers to fragment packets, > we ought to retain the ancient "IP OVER EVERYTHING" mantra > that has served the Internet (and ALL regions of the world) > so well for so many years now. > > I know of a number of link technologies that simply can't > support the existing 1280 byte minimum IPv6 MTU. Links > with the lower MTU overwhelmingly are relatively low speed > wireless links (everything in the gamut from HF radio > to SATCOM). My concerns about this have been expressed in > IPv6 WG meetings dating back to the early 1990s, as IETF > meeting minutes show. All the data available to me indicates > that these lower-speed (and smaller MTU) links are NOT going away. > > For HF radio links, link transmission speed is usually > measured in Kbps, with some deployed IPv4/HF links today > running as low as 2.4 Kbps. VHF and UHF line-of-sight > links tend to be much faster than HF, but are still well > below the slowest modern Ethernet link (i.e. 10 Mbps). > > The IPv6 concept of adding a special link-specific > fragmentation/reassembly protocol layer has never been > practical. By definition, these links have severe bandwidth > limitations already. I've seen multiple instances where > specialised routers that are connected to these LOW speed > links insert IPv6 Fragmentation Headers and perform > intermediate fragmentation to get IPv6 packets through > such links. In these special cases, there is no performance > issue because these wireless links have such low data rates. > > A result of deprecating the IPv6 Fragmentation Header will be > that such links will be running IPv4 *forever*. This is > the opposite of encouraging IPv6 transition -- it is preventing > IPv6 transition. It also probably requires the ongoing deployment > of IPv6::IPv4 protocol translation gateways -- and also > probably inhibits Internet deployment outside of "1st World" > countries. > > Sigh. > > > Deprecating IPv6 Fragmentation Header and related end-system > support is going to harm users and inhibit transition to IPv6. > > > PLEASE, PLEASE, let us NOT go there. > > > Sincerely Yours, > > Ran Atkinson > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7bdca7f0ebbb9404e115a5ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 - All of RJ's comments.

There has to= be a solution that not only allows for but encourages IPv6 deployment, not= prevents it.
--
Brian


On Tue, Jul 9, 2013 at 11:0= 2 AM, RJ Atkinson <rja.lists@gmail.com> wrote:
All,

I think everyone agrees that intermediate fragmentation
(e.g. by routers having high-speed links in the middle of the path)
can be problematic,and that is why IPv6 does NOT require that
(i.e. RFC-2460 says that the "DF" bit is invisible but always
set for IPv6).

That noted, I agree very much with Fernando Gont's
comments on 5th July 2013 that IPv6 fragmentation in
end systems ought NOT be deprecated -- and I find his
reasoning compelling.


(SEPARATELY)

Not all deployed links are built out of wired/wireless
Ethernet or SONET. =C2=A0The assumption that everything is either
Ethernet or SONET (or perhaps WDM) is a bit of a "First
World" assumption and puts lesser-developed countries/regions
at a significant disadvantage for Internet access.

Frankly it is embarrassing for IETF participants to make
such an assumption (i.e. that all links are Ethernet,
SONET, WDM, or better).

While it is fine to optimise so that Ethernet or SONET links
have great performance, for example by eliminating the
requirement for backbone routers to fragment packets,
we ought to retain the ancient =C2=A0"IP OVER EVERYTHING" =C2=A0m= antra
that has served the Internet (and ALL regions of the world)
so well for so many years now.

I know of a number of link technologies that simply can't
support the existing 1280 byte minimum IPv6 MTU. =C2=A0Links
with the lower MTU overwhelmingly are relatively low speed
wireless links (everything in the gamut from HF radio
to SATCOM). =C2=A0My concerns about this have been expressed in
IPv6 WG meetings dating back to the early 1990s, as IETF
meeting minutes show. =C2=A0All the data available to me indicates
that these lower-speed (and smaller MTU) links are NOT going away.

For HF radio links, link transmission speed is usually
measured in Kbps, with some deployed IPv4/HF links today
running as low as 2.4 Kbps. =C2=A0VHF and UHF line-of-sight
links tend to be much faster than HF, but are still well
below the slowest modern Ethernet link (i.e. 10 Mbps).

The IPv6 concept of adding a special link-specific
fragmentation/reassembly protocol layer has never been
practical. =C2=A0By definition, these links have severe bandwidth
limitations already. =C2=A0I've seen multiple instances where
specialised routers that are connected to these LOW speed
links insert IPv6 Fragmentation Headers and perform
intermediate fragmentation to get IPv6 packets through
such links. =C2=A0In these special cases, there is no performance
issue because these wireless links have such low data rates.

A result of deprecating the IPv6 Fragmentation Header will be
that such links will be running IPv4 *forever*. =C2=A0This is
the opposite of encouraging IPv6 transition -- it is preventing
IPv6 transition. =C2=A0It also probably requires the ongoing deployment
of IPv6::IPv4 protocol translation gateways -- and also
probably inhibits Internet deployment outside of "1st World"
countries.

Sigh.


Deprecating IPv6 Fragmentation Header and related end-system
support is going to harm users and inhibit transition to IPv6.


PLEASE, PLEASE, let us NOT go there.


Sincerely Yours,

Ran Atkinson


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

--047d7bdca7f0ebbb9404e115a5ee-- From cabo@tzi.org Tue Jul 9 09:38:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB63D21F9E34 for ; Tue, 9 Jul 2013 09:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 yD-crGSLASsd for ; Tue, 9 Jul 2013 09:38:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E527E21F9E18 for ; Tue, 9 Jul 2013 09:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r69Gc6eR001466; Tue, 9 Jul 2013 18:38:06 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 376133687; Tue, 9 Jul 2013 18:38:06 +0200 (CEST) Subject: Re: Meta-issues: On the deprecation of the fragmentation function Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 9 Jul 2013 18:38:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> References: To: RJ Atkinson X-Mailer: Apple Mail (2.1508) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:38:16 -0000 On Jul 9, 2013, at 17:02, RJ Atkinson wrote: > The IPv6 concept of adding a special link-specific > fragmentation/reassembly protocol layer has never been > practical. =20 For 6LoWPAN, we did (we had to). And it works well enough. But for one problem: adaptation layer fragmentation is *transparent*, so = there is no way for an application to do the equivalent of PMTUD to = avoid/minimize adaptation layer fragmentation. A feeble attempt at addressing this: http://tools.ietf.org/html/draft-bormann-intarea-alfi-03 Gr=FC=DFe, Carsten From rja.lists@gmail.com Tue Jul 9 10:28:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBA021F9F2A for ; Tue, 9 Jul 2013 10:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr01BzJbWAm5 for ; Tue, 9 Jul 2013 10:28:05 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EB67321F9F0D for ; Tue, 9 Jul 2013 10:28:04 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id 1so3157164qec.6 for ; Tue, 09 Jul 2013 10:28:04 -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=ZBbYwxj3cHEM8UntptRegeyo9oJHXiqgx+RcbSTHHks=; b=vy0cYV/UyayI4Wz2K2RSg+EGcKRfQaK3+MDziG0J+xUuFtPuCdD2K5rNKMKk8RJTzn 9qs78OVHljD0Si2nKv4SG8OFe2NFuVcWQiwUMMSNF2kUiEhxy4fMtDIicmQHWwdLycFP s4lE1nAKSkAOQ8i5SYyobCnP3Yu1XUCuOtczLckjduPiEkgKvgvb8Zfr0Ab5vOWRGn1G YsdcZzelJoF7TgNry0Cp2h86MhD89E/M4DLW2hA28yHAeytY1KAKKF0Ll/0zhpSxwBqh Aa9VB3A+wtXFnz/U/OJk3Gd1s6+0df7HpyCVnfSktU8QzSIThhmuWWm5o37vFqY8ghZH oVvg== X-Received: by 10.49.85.199 with SMTP id j7mr21460032qez.45.1373390884189; Tue, 09 Jul 2013 10:28:04 -0700 (PDT) Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id 2sm20462530qap.7.2013.07.09.10.28.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 10:28:03 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Meta-issues: On the deprecation of the fragmentation function From: RJ Atkinson In-Reply-To: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> Date: Tue, 9 Jul 2013 13:28:02 -0400 Content-Transfer-Encoding: 7bit Message-Id: <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:28:09 -0000 > On Jul 9, 2013, at 17:02, RJ Atkinson wrote: >> The IPv6 concept of adding a special link-specific >> fragmentation/reassembly protocol layer has never been >> practical. My comment (above) was in the context of the kinds of low-bandwidth links with smaller MTU sizes that I was discussing, of course. :-) On 09 Jul 2013, at 12:38 , Carsten Bormann wrote: > For 6LoWPAN, we did (we had to). And it works well enough. I am happy to accept your word that it works well enough for 6LoWPAN (i.e. IEEE 802.15.4). Of course, it helps that IEEE 802.15.4 links support up to 250 Kbps, which is visibly higher capacity than a number of RF links that are deployed with IPv4 today. However, I also have experience indicating that link-specific fragmentation/reassembly does NOT work as well as simply inserting an IPv6 Fragmentation Header -- at least for some other low-speed, smaller MTU, RF link layers that work adequately with IPv4 today. Various obvious things, such as header compression, already are commonly used on such low-bandwidth RF links. > But for one problem: adaptation layer fragmentation is > *transparent*, so there is no way for an application > to do the equivalent of PMTUD to avoid/minimize adaptation > layer fragmentation. Good point. Yours, Ran From dougb@dougbarton.us Tue Jul 9 10:31:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A0421F9F69 for ; Tue, 9 Jul 2013 10:31:39 -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 mdXOhTgLTCfY for ; Tue, 9 Jul 2013 10:31:39 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id CACBB21F9F33 for ; Tue, 9 Jul 2013 10:31:36 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id 5E34922B0F for ; Tue, 9 Jul 2013 17:31:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1373391096; bh=JD55JAstYFYSvbBTwItzMOkNt3HBxG3nfVSQe54QPYE=; h=Date:From:To:Subject:References:In-Reply-To; b=VDO/fa0cjZI8GvjD/+gFRtSV+bmLzpyIgZzo1KKfXMDIQQ3UyeL3XnhGS1man/8Dl fG2tHYoDteFlYgGWyT54kvYpyrlgkCNTNxpgvqdaT/uXaByDTAupHWHUd72k1hephI bLlfsAkmykKBVTTxQJGdjefZheafjLpbB3zFu8LE= Message-ID: <51DC48F7.2080901@dougbarton.us> Date: Tue, 09 Jul 2013 10:31:35 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Meta-issues: On the deprecation of the fragmentation function References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> In-Reply-To: <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:31:40 -0000 I stated it a while back, but now that folks seem to be coming around I thought it might be worthwhile to restate that I agree that deprecating fragmentation is a bad idea. My part of this elephant is that we need fragmentation/PMTUD/Window Scaling to work reliably as we look toward future networks that are faster, and require larger MTU to be more efficient. Doug From rja.lists@gmail.com Tue Jul 9 11:03:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A3E21F9ED4 for ; Tue, 9 Jul 2013 11:03:10 -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 B556DJ7UzQGD for ; Tue, 9 Jul 2013 11:03:10 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD821F9ED6 for ; Tue, 9 Jul 2013 11:03:09 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so3179395qee.26 for ; Tue, 09 Jul 2013 11:03:08 -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=4O7fenVCcBoWeCIn0oF+fA7CGWTYztOQ9QqSw+hGSLk=; b=xYT3PjlxHgiJAR2pBS925vgQTT8wGPvrz1G8XU0vO3NTB0Zm0WNG5m4re/kvbvFTOd 2RGRd/+nKwHtYwfKw9dMM0YKr2Ptc2cRCVlYvivgQj6VJ3VV9LB79lYsLg/3vHSpKpnM 1LcgYa9sKx7PT7mYMUvfNHJhdIzRxMWDndg3tvvSYA+pC0W0g8cfcAKY/EtKAtvN4cmd 4MU4VD1ixLW4WbjvJgRnQKxdjFf905g/zQ3EVuOo7p67bA8xS0yd5cYta5E9wriJ1NVG gBK8+RjrniqzXYXA/dzeunNLhz61p4suqWFucOzQK2aIR0cD3dMy3ULGtwG7PTOje6dl x1YA== X-Received: by 10.49.85.199 with SMTP id j7mr21592374qez.45.1373392988894; Tue, 09 Jul 2013 11:03:08 -0700 (PDT) Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id 11sm19597956qek.1.2013.07.09.11.03.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 11:03:08 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [6MAN] [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) Date: Tue, 9 Jul 2013 14:03:07 -0400 Message-Id: <1C0DCB6D-18F4-4A16-843C-3822921E5CF7@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:03:10 -0000 All, I support the ideas expressed in this draft. In the early part of this century, while working for an equipment supplier that designed their own packet processing chips, I was involved with the design of a packet processing chipset that could handle (even small IP packets) at line rate on 10 Gbps Ethernet interfaces, including parsing the IPv6 header chain and applying L4 filtering ACLs. Adding that ability to parse IPv6 header chains & perform L4 filtering at line-rate on a 10 GigE interface did NOT increase the ASIC gate count enough to change the die size. So there was no recurring manufacturing cost for that feature. As I recall, this implementation could at least parse 128 bytes into the IPv6 header chain. I'm pretty confident that the implementation did not parse any deeper than 255 bytes, and I am certain that it could not parse more than 255 bytes into the header chain. I have heard from several ISPs that a different manufacturer has for some years now (at least 6 years) deployed backbone routers that can at least parse past 1 IPv6 extension header to apply L4 ACLs/filtering -- also at line rate on interfaces operating at 10 Gbps (possibly higher speed by now). One person at that firm has confirmed this ability to me verbally. I'm not certain precisely what the depth of their parsing ability might be. So there are at least two implementations of ASIC/FPGA-based packet processors that can parse IPv6 header chains at 10 Gbps line-rate (possibly higher). I think long term, this capability will be highly desired (and in at least some operational environments, needed). This capability will tend to help encourage IPv6 deployment, because it will help IPv6 L4 ACL implementations perform at a level comparable to IPv4 L4 ACL implementations. This draft provides a significant help both to implementers and operators by providing a specification for a minimum parse depth (i.e. 128 bytes as per Section 4 of this I-D). I hope that this draft is able to move forward as a BCP. Yours, Ran Atkinson From rbonica@juniper.net Tue Jul 9 11:14:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D254321F9B18 for ; Tue, 9 Jul 2013 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.967 X-Spam-Level: X-Spam-Status: No, score=-100.967 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkTeOh9K4Ep8 for ; Tue, 9 Jul 2013 11:13:58 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 050BD21F9A50 for ; Tue, 9 Jul 2013 11:13:57 -0700 (PDT) Received: from mail130-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE036.bigfish.com (10.243.66.101) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 18:13:57 +0000 Received: from mail130-co1 (localhost [127.0.0.1]) by mail130-co1-R.bigfish.com (Postfix) with ESMTP id 1CEEAD6038B for ; Tue, 9 Jul 2013 18:13:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz9371I542I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail130-co1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail130-co1 (localhost.localdomain [127.0.0.1]) by mail130-co1 (MessageSwitch) id 1373393576700423_18430; Tue, 9 Jul 2013 18:12:56 +0000 (UTC) Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.243]) by mail130-co1.bigfish.com (Postfix) with ESMTP id A7E45DC00E3 for ; Tue, 9 Jul 2013 18:12:56 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.53) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 18:12:54 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 9 Jul 2013 11:12:54 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 11:12:53 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 11:16:38 -0700 Received: from mail205-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 18:12:53 +0000 Received: from mail205-ch1 (localhost [127.0.0.1]) by mail205-ch1-R.bigfish.com (Postfix) with ESMTP id D1272600B0 for ; Tue, 9 Jul 2013 18:12:52 +0000 (UTC) Received: from mail205-ch1 (localhost.localdomain [127.0.0.1]) by mail205-ch1 (MessageSwitch) id 1373393569845838_10076; Tue, 9 Jul 2013 18:12:49 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail205-ch1.bigfish.com (Postfix) with ESMTP id C1C4848007A; Tue, 9 Jul 2013 18:12:49 +0000 (UTC) Received: from BL2PRD0512HT004.namprd05.prod.outlook.com (157.56.242.197) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 18:12:47 +0000 Received: from BL2PRD0512MB646.namprd05.prod.outlook.com ([169.254.9.215]) by BL2PRD0512HT004.namprd05.prod.outlook.com ([10.255.233.37]) with mapi id 14.16.0329.000; Tue, 9 Jul 2013 18:12:38 +0000 From: Ronald Bonica To: Doug Barton , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoLtuD7p8LeE2Fhu/K5qJEnJlci/SAgAAN9ACAAAD+gIAACExQ Date: Tue, 9 Jul 2013 18:12:38 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> In-Reply-To: <51DC48F7.2080901@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%DOUGBARTON.US$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:14:03 -0000 Doug, It might be interesting to revisit what we mean by deprecating IPv6 fragmen= tation.... It means that the IETF will not approve any new protocols that rely upon IP= v6 fragmentation. Nothing more, nothing less. Old protocols will continue to emit IPv6 fragments. In order to achieve bac= kwards compatibility, new IPv6 implementations will MUST continue to suppor= t reassembly of incoming fragments. New IPv6 implementations MAY even suppo= rt transmission of IPv6 fragments, if they want to support legacy applicati= ons that rely on the transmission of IPv6 fragments. Network operators will make up their own minds as to whether they will forw= ard IPv6 fragments. They do this today. The draft offers no guidance, one w= ay or the other. Brian Carpenter recommended some clarifying text regarding what the recomme= ndation to deprecate actually means. You will see this in an updated versio= n of the draft in the next day or so. Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Doug Barton > Sent: Tuesday, July 09, 2013 1:32 PM > To: ipv6@ietf.org > Subject: Re: Meta-issues: On the deprecation of the fragmentation > function >=20 > I stated it a while back, but now that folks seem to be coming around I > thought it might be worthwhile to restate that I agree that deprecating > fragmentation is a bad idea. My part of this elephant is that we need > fragmentation/PMTUD/Window Scaling to work reliably as we look toward > future networks that are faster, and require larger MTU to be more > efficient. >=20 > Doug > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From dougb@dougbarton.us Tue Jul 9 11:41:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE0C21F9C8A for ; Tue, 9 Jul 2013 11:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka1B95gJnEG3 for ; Tue, 9 Jul 2013 11:41:33 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 77EC421F9C2E for ; Tue, 9 Jul 2013 11:41:33 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id 009F222B0F; Tue, 9 Jul 2013 18:41:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1373395286; bh=XUrwqXQNCCROI9rnmJopgxAhRYNgAxdHG0B4xDqXacs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=vSyeNThWUeiB65agHaR1kmFf902Al66MV9jdSb2NXW1WnglTQ7ipj1XZMbSw6F1hF eE/FPi440xBNZLC+EnIw1cphYBZWvQboOQ6hsE/J1tmTWGjeagSnCupm+xFUK76CV0 RvTjlfIhkCRKkwI10J4bM7a8F+uKJGLUtalvPNS4= Message-ID: <51DC5955.4030700@dougbarton.us> Date: Tue, 09 Jul 2013 11:41:25 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ronald Bonica Subject: Re: Meta-issues: On the deprecation of the fragmentation function References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:41:37 -0000 On 07/09/2013 11:12 AM, Ronald Bonica wrote: > Doug, > > It might be interesting to revisit what we mean by deprecating IPv6 fragmentation.... > > It means that the IETF will not approve any new protocols that rely upon IPv6 fragmentation. Nothing more, nothing less. Thanks for clarifying. FWIW, I understand what is being proposed, and I still think it's a bad idea. Doug From Fred.L.Templin@boeing.com Tue Jul 9 12:11:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8C121F9D7C for ; Tue, 9 Jul 2013 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 bPfgN6aAU-ir for ; Tue, 9 Jul 2013 12:11:45 -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 7FFC021F854D for ; Tue, 9 Jul 2013 12:11:45 -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 r69JBj21019838 for ; Tue, 9 Jul 2013 12:11:45 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r69JBiFL019834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 9 Jul 2013 12:11:44 -0700 Received: from XCH-BLV-105.nw.nos.boeing.com (130.247.25.121) by XCH-NWHT-02.nw.nos.boeing.com (130.247.70.248) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 9 Jul 2013 12:11:44 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.26]) with mapi id 14.02.0328.011; Tue, 9 Jul 2013 12:11:43 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: RE: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOfNP2SELxKjdOgEeYPWykcTQhxJlcsv4g Date: Tue, 9 Jul 2013 19:11:42 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B766F@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> In-Reply-To: <51DC5955.4030700@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:11:51 -0000 Hi, Going back to our discussions from last week, here is a draft that captures the proposed uses of fragmentation for tunneling and other purposes. It is called: "Fragmentation Revisited", and it offers an approach to limited use of fragmentation in a way that can begin to remove all barriers to supporting larger MTUs in the Internet, i.e., even with broken PMTUD, even with broken fragmentation/reassembly, and even with tunnels. Think about that for a second. While we currently have burned-in numbers (576, 1280, 1500) that will never go away, the adoption of these techniques will ensure that there will never again need to be another burned-in number even as the Internet naturally grows to support larger packet sizes. We will then be able to say that the MTU of the Internet is "unlimited" or rather limited only by the constituent links, whatever they happen to be. Comments on the list would be welcome. Thanks - Fred fred.l.templin@boeing.com =20 --- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Tuesday, July 09, 2013 11:50 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-generic-6man-tunfrag-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Fragmentation Revisited Author(s) : Fred L. Templin Filename : draft-generic-6man-tunfrag-08.txt Pages : 8 Date : 2013-07-09 Abstract: IP fragmentation has long been subject for scrutiny since the publication of "Fragmentation Considered Harmful" in 1987. This work cast fragmentation in a negative light that has persisted to the present day. However, the tone of the work failed to honor two principles of creative thinking: never say "always" and never say "never". This document discusses uses for fragmentation that apply both to the present day and moving forward into the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag There's also a htmlized version available at: http://tools.ietf.org/html/draft-generic-6man-tunfrag-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-generic-6man-tunfrag-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From brian.e.carpenter@gmail.com Tue Jul 9 13:50:58 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14E321F9CFF for ; Tue, 9 Jul 2013 13:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 d1nA3loLI20h for ; Tue, 9 Jul 2013 13:50:57 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EE3BA21F9CF2 for ; Tue, 9 Jul 2013 13:50:56 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so5565093pdd.20 for ; Tue, 09 Jul 2013 13:50:56 -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=aD7IeQbhzSSrH3iYVUXJxtDCaqrz93YldISMjr9ZwdI=; b=duy0Dm1DvUGPmhp0MAyNxdYMUUuF/zQwVxZXdyRdFLANO6Y6nJskJFHEayqwRnZoSA 0liwcRlEj9sLC0JSGSasxhAkCCQWNkl6nZ7uSi240AzXfOVLIIY9mfojJqs24Y66zRfv 3M+YVhL2GS1pThN17Fu9G3l7bMdiVK5D0zsfN72iDVtyfbdw2mHMZ4J/mSSHxNVJSVd+ MVV5eWzsDzNi+Bgih3yihYDT1C24/r62Z3kVgnXcSh69uK6CDm3knHkvqLwR23ylLnm0 2xtHx6VMTvhcP0KlI7XJbmkgHPeOCRyJMo54OTsR3psCXcXP0Ayo0JQngMPMa0Kz5jpR oVng== X-Received: by 10.66.26.46 with SMTP id i14mr30262464pag.25.1373403056718; Tue, 09 Jul 2013 13:50:56 -0700 (PDT) Received: from [192.168.178.23] (211.192.69.111.dynamic.snap.net.nz. [111.69.192.211]) by mx.google.com with ESMTPSA id wi6sm29971425pbc.22.2013.07.09.13.50.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 13:50:56 -0700 (PDT) Message-ID: <51DC77B1.9020206@gmail.com> Date: Wed, 10 Jul 2013 08:50:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Meta-issues: On the deprecation of the fragmentation function References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> In-Reply-To: <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:50:58 -0000 On 10/07/2013 05:28, RJ Atkinson wrote: ... >> But for one problem: adaptation layer fragmentation is >> *transparent*, so there is no way for an application >> to do the equivalent of PMTUD to avoid/minimize adaptation >> layer fragmentation. > > Good point. And you can't get round it. The decision to raise the minimum link MTU from 576 to 1280 was not a change in principle; it was just raising the level at which transparent adaptation layers were presumed to be acceptable. The big change in principle was the abolition of on-path fragmentation. Brian From albert.e.manfredi@boeing.com Tue Jul 9 14:21:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0747311E8169 for ; Tue, 9 Jul 2013 14:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NoVHJ9yVYAtG for ; Tue, 9 Jul 2013 14:21:17 -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 CF9B821F9D3A for ; Tue, 9 Jul 2013 14:21:11 -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 r69LL2XB016437 for ; Tue, 9 Jul 2013 14:21:02 -0700 Received: from XCH-PHX-408.sw.nos.boeing.com (xch-phx-408.sw.nos.boeing.com [137.136.239.50]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r69LL1Dq016421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 9 Jul 2013 14:21:01 -0700 Received: from XCH-BLV-213.nw.nos.boeing.com (137.136.239.117) by XCH-PHX-408.sw.nos.boeing.com (137.136.239.50) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 9 Jul 2013 14:21:01 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.45]) by XCH-BLV-213.nw.nos.boeing.com ([169.254.13.32]) with mapi id 14.02.0328.011; Tue, 9 Jul 2013 14:21:01 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVaZnTlKlB4FkOxCA1WCzV5ipldAU2AgAAN9ACAADiygP//kGpg Date: Tue, 9 Jul 2013 21:21:00 +0000 Message-ID: <021E64FECA7E5A4699562F4E667164810B4641B0@XCH-PHX-503.sw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> In-Reply-To: <51DC77B1.9020206@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 21:21:25 -0000 > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of B= rian > E Carpenter > On 10/07/2013 05:28, RJ Atkinson wrote: > ... > >> But for one problem: adaptation layer fragmentation is > >> *transparent*, so there is no way for an application > >> to do the equivalent of PMTUD to avoid/minimize adaptation > >> layer fragmentation. > > > > Good point. >=20 > And you can't get round it. The decision to raise the minimum link > MTU from 576 to 1280 was not a change in principle; it was just > raising the level at which transparent adaptation layers were > presumed to be acceptable. The big change in principle was the > abolition of on-path fragmentation. I'm not sure I follow this. First is, the change of MTU was not one of 576 to 1280. It was one of 64 to= 1280. That 576 figure is the smallest maximum RECONSTITUTED packet size th= at IPv4 is supposed to support. Individual fragments need not be larger tha= n 64 bytes. If that same principle had been applied to IPv6, maybe we would= n't be having these discussions at all. The other point is, I don't see how transparent adaptation layers are an is= sue at all? I don't think anyone is saying that it's impossible to transmit= IPv6 over ATM cells? Or are they? Bert From cabo@tzi.org Tue Jul 9 14:53:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC2B11E8185 for ; Tue, 9 Jul 2013 14:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 1wQVNgRmuuvz for ; Tue, 9 Jul 2013 14:53:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D66D421F9B95 for ; Tue, 9 Jul 2013 14:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r69LrPIn013338; Tue, 9 Jul 2013 23:53:25 +0200 (CEST) Received: from [192.168.217.105] (p54894660.dip0.t-ipconnect.de [84.137.70.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9BF513783; Tue, 9 Jul 2013 23:53:25 +0200 (CEST) Subject: Re: Meta-issues: On the deprecation of the fragmentation function Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51DC77B1.9020206@gmail.com> Date: Tue, 9 Jul 2013 23:53:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33A183DF-7689-479C-A7EA-06698A8B3B9F@tzi.org> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) Cc: "ipv6@ietf.org List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 21:53:35 -0000 On Jul 9, 2013, at 22:50, Brian E Carpenter = wrote: > On 10/07/2013 05:28, RJ Atkinson wrote: > ... >>> But for one problem: adaptation layer fragmentation is >>> *transparent*, so there is no way for an application >>> to do the equivalent of PMTUD to avoid/minimize adaptation >>> layer fragmentation. >>=20 >> Good point. >=20 > And you can't get round it. (I don't know if you mean that the way I read it, but:) Yes, I'm trying to do ALFI because I think we do need a way to get = around this lack of information. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Jul 9 15:08:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F80B11E817A for ; Tue, 9 Jul 2013 15:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 pfgznuQLepM8 for ; Tue, 9 Jul 2013 15:08:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE8E11E8175 for ; Tue, 9 Jul 2013 15:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r69M86IM008938; Wed, 10 Jul 2013 00:08:06 +0200 (CEST) Received: from [192.168.217.105] (p54894660.dip0.t-ipconnect.de [84.137.70.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 386C53789; Wed, 10 Jul 2013 00:08:06 +0200 (CEST) Subject: Re: Meta-issues: On the deprecation of the fragmentation function Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <021E64FECA7E5A4699562F4E667164810B4641B0@XCH-PHX-503.sw.nos.boeing.com> Date: Wed, 10 Jul 2013 00:08:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <021E64FECA7E5A4699562F4E667164810B4641B0@XCH-PHX-503.sw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.1508) Cc: "ipv6@ietf.org List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 22:08:23 -0000 > First is, the change of MTU was not one of 576 to 1280. I think he was talking about changing the minMTU of Steve Deering's = Simple IP from 576 first into the mistaken 1500 and then into 1280 in = the process of turning it into IPv6. http://tools.ietf.org/html/draft-deering-sip-00 (BTW, is that process documented anywhere? RFC1710 doesn't seem to = mention the MTU.) > The other point is, I don't see how transparent adaptation layers are = an issue at all? I don't think anyone is saying that it's impossible to = transmit IPv6 over ATM cells? Or are they? The problem comes up where the transparency is a leaky abstraction = (http://en.wikipedia.org/wiki/Leaky_abstraction). For ATM, the abstraction was not very leaky as the performance impact of = sending an MTU-size packet was negligible (at least for the more recent = cases of ATM). For the constrained networks Ran and I are interested in, the = performance impact of adaptation layer fragmentation can be significant, = and application layer protocols that get to choose their packet sizes = can benefit quite a bit if they know this fragmentation is taking place = and what packet sizes are the thresholds. Please read the short ALFI draft for more background. http://tools.ietf.org/html/draft-bormann-intarea-alfi-03 http://www.ietf.org/proceedings/85/slides/slides-85-intarea-1.pdf Gr=FC=DFe, Carsten From Fred.L.Templin@boeing.com Tue Jul 9 15:27:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223C411E8182 for ; Tue, 9 Jul 2013 15:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 4DmPelk2Fw4x for ; Tue, 9 Jul 2013 15:27:22 -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 72BAF11E817A for ; Tue, 9 Jul 2013 15:27:12 -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 r69MRBTO027084 for ; Tue, 9 Jul 2013 15:27:11 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r69MR8rv027053 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 9 Jul 2013 15:27:10 -0700 Received: from XCH-BLV-104.nw.nos.boeing.com (130.247.25.120) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 9 Jul 2013 15:27:08 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-104.nw.nos.boeing.com ([169.254.4.39]) with mapi id 14.02.0328.011; Tue, 9 Jul 2013 15:27:07 -0700 From: "Templin, Fred L" To: Carsten Bormann , "Manfredi, Albert E" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfPDdEVtgyhVSFES4anVAs4ggI5lc6Y2w Date: Tue, 9 Jul 2013 22:27:05 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B78BE@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <021E64FECA7E5A4699562F4E667164810B4641B0@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 22:27:35 -0000 Hi, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Carsten Bormann > Sent: Tuesday, July 09, 2013 3:08 PM > To: Manfredi, Albert E > Cc: ipv6@ietf.org List > Subject: Re: Meta-issues: On the deprecation of the fragmentation > function >=20 > > First is, the change of MTU was not one of 576 to 1280. >=20 > I think he was talking about changing the minMTU of Steve Deering's > Simple IP from 576 first into the mistaken 1500 and then into 1280 in > the process of turning it into IPv6. > http://tools.ietf.org/html/draft-deering-sip-00 > (BTW, is that process documented anywhere? RFC1710 doesn't seem to > mention the MTU.) >=20 > > The other point is, I don't see how transparent adaptation layers are > an issue at all? I don't think anyone is saying that it's impossible to > transmit IPv6 over ATM cells? Or are they? >=20 > The problem comes up where the transparency is a leaky abstraction > (http://en.wikipedia.org/wiki/Leaky_abstraction). >=20 > For ATM, the abstraction was not very leaky as the performance impact > of sending an MTU-size packet was negligible (at least for the more > recent cases of ATM). >=20 > For the constrained networks Ran and I are interested in, the > performance impact of adaptation layer fragmentation can be > significant, and application layer protocols that get to choose their > packet sizes can benefit quite a bit if they know this fragmentation is > taking place and what packet sizes are the thresholds. I already said in the other thread that aviation and tactical military links are examples of slow RF links where even as much as 1280 is asking a lot. About size issues, the first IPv6 spec (RFC1883) had a 576 minMTU, and that was changed to 1280 during publication of RFC2460 based on Steve Deering's Nov. 1997 proposal on the IPng list. Other sizes of interest: 68 - real IPv4 minMTU 576 - de-facto IPv4 minMTU (the one everyone assumes) 576 - real IPv4 minMRU 576 - old IPv6 minMTU 1280 - current IPv6 minMTU 1500 - current IPv6 minMRU 1500 - de-facto IPv4 minMRU (the one everyone assumes) 1500 - legacy Ethernet MTU 2048 - proposed new IPv6 minMRU Fred fred.l.templin@boeing.com > Please read the short ALFI draft for more background. > http://tools.ietf.org/html/draft-bormann-intarea-alfi-03 > http://www.ietf.org/proceedings/85/slides/slides-85-intarea-1.pdf >=20 > Gr=FC=DFe, Carsten >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rbonica@juniper.net Tue Jul 9 17:33:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A72921F9C72 for ; Tue, 9 Jul 2013 17:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDzctwSRNALQ for ; Tue, 9 Jul 2013 17:33:06 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9678D21F9C6B for ; Tue, 9 Jul 2013 17:33:06 -0700 (PDT) Received: from mail76-co9-R.bigfish.com (10.236.132.242) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 00:33:05 +0000 Received: from mail76-co9 (localhost [127.0.0.1]) by mail76-co9-R.bigfish.com (Postfix) with ESMTP id C5DC26045A for ; Wed, 10 Jul 2013 00:33:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I148cI542I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail76-co9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=rbonica@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail76-co9 (localhost.localdomain [127.0.0.1]) by mail76-co9 (MessageSwitch) id 1373416383853275_3463; Wed, 10 Jul 2013 00:33:03 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.229]) by mail76-co9.bigfish.com (Postfix) with ESMTP id C81B94017A for ; Wed, 10 Jul 2013 00:33:03 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 00:33:03 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 9 Jul 2013 17:33:03 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 17:33:03 -0700 Received: from CO9EHSOBE027.bigfish.com (207.46.163.25) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 17:36:46 -0700 Received: from mail74-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 00:33:01 +0000 Received: from mail74-co9 (localhost [127.0.0.1]) by mail74-co9-R.bigfish.com (Postfix) with ESMTP id CF81226047E for ; Wed, 10 Jul 2013 00:33:01 +0000 (UTC) Received: from mail74-co9 (localhost.localdomain [127.0.0.1]) by mail74-co9 (MessageSwitch) id 137341638020848_26126; Wed, 10 Jul 2013 00:33:00 +0000 (UTC) Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.239]) by mail74-co9.bigfish.com (Postfix) with ESMTP id EC34A4E007F; Wed, 10 Jul 2013 00:32:59 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 00:33:00 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.145]) by BY2PRD0512HT004.namprd05.prod.outlook.com ([10.255.243.37]) with mapi id 14.16.0329.000; Wed, 10 Jul 2013 00:32:58 +0000 From: Ronald Bonica To: Doug Barton Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoLtuD7p8LeE2Fhu/K5qJEnJlci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUA== Date: Wed, 10 Jul 2013 00:32:58 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> In-Reply-To: <51DC5955.4030700@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%DOUGBARTON.US$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 00:33:13 -0000 Doug, Let's see if we can find some common ground.=20 Assume that the IETF is considering a new protocol that doesn't run over TC= P. In order to deal with MTU issues, the new protocol must do one of the fo= llowing: a) implement PLMTUD or PMTUD b) restrict itself to sending PDUs so small that when they are encapsulated= in an IPv6 header, the resulting packet will not exceed 1280 bytes c) rely on IPv6 fragmentation Is there ever a reason why c) is better than a) or b). For that matter, is = c) ever an acceptable solution? Ron > -----Original Message----- > From: Doug Barton [mailto:dougb@dougbarton.us] > Sent: Tuesday, July 09, 2013 2:41 PM > To: Ronald Bonica > Cc: ipv6@ietf.org > Subject: Re: Meta-issues: On the deprecation of the fragmentation > function >=20 > On 07/09/2013 11:12 AM, Ronald Bonica wrote: > > Doug, > > > > It might be interesting to revisit what we mean by deprecating IPv6 > fragmentation.... > > > > It means that the IETF will not approve any new protocols that rely > upon IPv6 fragmentation. Nothing more, nothing less. >=20 > Thanks for clarifying. FWIW, I understand what is being proposed, and I > still think it's a bad idea. >=20 > Doug >=20 >=20 From rja.lists@gmail.com Tue Jul 9 17:42:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FB921F9D35 for ; Tue, 9 Jul 2013 17:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-QCJnO1FfR5 for ; Tue, 9 Jul 2013 17:42:24 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B22C311E80ED for ; Tue, 9 Jul 2013 17:42:24 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e11so3300015qcx.24 for ; Tue, 09 Jul 2013 17:42:24 -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=sr1KFLaqcT9Pfkt/vfOZm4k3fiPiyV2hTt1pPl90INQ=; b=AOo1rpfLCCKI5WcxFyw+ydQw8asYSwFcICEGGOyLtetptITmSK7cxIP5+Kh7kS71Oa olR+IpvknQ+vevMl3DB7aDDSs15Btj9xW+MLugfcnOLJuPDSfDGt5a9BymOjwv3Rjerc YJwqrjulmy5/m8zvE/wUFh8vh3mkfN8sXr1DIJn2VWgYYCygwB31vYMkFO7c1tEMsdK9 2hRCbFLC3FIlxg+m4fauqrOvOBQEndcCL5s70U28azXpWHSnDBFYioxNU1MbnHTNtAIl B8wnuZOVwN6wLeseVtS3HPJYOsAH+RqcIztwTQpvUOS7e0v2R05HCn54T0x/xdm7C4K1 NFVA== X-Received: by 10.224.128.2 with SMTP id i2mr26300463qas.11.1373416944145; Tue, 09 Jul 2013 17:42:24 -0700 (PDT) Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id r2sm21615626qeh.7.2013.07.09.17.42.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 17:42:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Meta-issues: On the deprecation of the fragmentation function From: RJ Atkinson In-Reply-To: <51DC77B1.9020206@gmail.com> Date: Tue, 9 Jul 2013 20:42:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 00:42:25 -0000 On July 9th, Carsten Bormann wrote, in part: >>> But for one problem: adaptation layer fragmentation is >>> *transparent*, so there is no way for an application >>> to do the equivalent of PMTUD to avoid/minimize adaptation >>> layer fragmentation. >> On 10/07/2013 05:28, RJ Atkinson wrote: >> Good point. On 09 Jul 2013, at 16:50 , Brian E Carpenter wrote: > And you can't get round it. The decision to raise the minimum link > MTU from 576 to 1280 was not a change in principle; For IPv6, the specification of any minimum MTU might well=20 have been the fundamental mistake here. Specifying a minimum MTU above 576 definitely was a mistake=20 in practical terms of IPv6 deployability -- and some of us=20 objected to the change at the time (giving examples of=20 links that would be broken -- which have come true since). As you know already, IPv4 simply does not have any Minimum Link MTU. So it was probably over-specification=20 for IPv6 to specify any minimum link MTU. For IPv4, RFC-791 says 576 actually was the size of buffer space that hosts had to have available for fragment reassembly. =20 RFC-1122 agrees with RFC-791 and gives it the name EMTU_R=20 ("Effective MTU to receive"). =20 RFC-1122 further defines EMTU_S ("Effective MTU to send") and says:=20 "... the IP layer SHOULD use EMTU_S <=3D 576 whenever the destination address is not a a connected network, and otherwise use the connected network's MTU." A bit later on, RFC-1122 also says: "Since nearly all networks in the Internet currently support an MTU of 576 or greater, we strongly recommend the use of 576 for datagrams sent to non-local networks." Again, this doesn't make 576 a minimum link MTU for IPv4. > The big change in principle was the abolition of on-path = fragmentation. Well, at the moment, on-path fragmentation is not actually prohibited, as near as several implementers (including me) can tell, although it=20 absolutely is never required to be supported by routers. =20 Everyone agrees that on-path fragmentation by routers is generally=20 undesirable. =20 Everyone also agrees that a router, for example a backbone high-speed = router,=20 must not be forced to fragment anything -- for practical performance = reasons=20 that are widely understood. =20 However, the IPv6 specs don't prohibit a router from choosing to = fragment=20 a packet in the way described in my earlier note in those circumstances. = =20 Such fragmentation is generally undetectable at present, except to the=20= router that performs the fragmentation in order to transmit the IPv6 = packet=20 over a link having a smaller MTU. =20 This difference between "not required" and "prohibited" is critical=20 for IPv6 deployment over low-rate links having a smaller MTU size,=20 as I outlined in my previous note within this thread. If a goal of this WG is to encourage deployment of IPv6 and transition from IPv4 to IPv6, then it would be best not to change the current = status of fragmentation in IPv6 -- and it would be helpful to change the = minimum Link MTU to a value lower than 1280 (or deprecate the Minimum Link MTU specification entirely, although that seems quite unlikely here now). I'd really like to see IPv6 get universally deployed. These particular changes are significant barriers to that happening and create perverse incentives either to stay with IPv6 forever or to build & deploy IPv6::IPv4 translational gateways (ugh). Cheers, Ran From Fred.L.Templin@boeing.com Wed Jul 10 07:59:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D325F21F9A81 for ; Wed, 10 Jul 2013 07:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 5gn0H1uN-kbo for ; Wed, 10 Jul 2013 07:59:13 -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 04FB011E8132 for ; Wed, 10 Jul 2013 07:58:48 -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 r6AEwieS030101 for ; Wed, 10 Jul 2013 07:58:45 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6AEwiEf030094 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 10 Jul 2013 07:58:44 -0700 Received: from XCH-BLV-405.nw.nos.boeing.com (130.247.25.158) by XCH-NWHT-06.nw.nos.boeing.com (130.247.25.110) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 10 Jul 2013 07:58:45 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-405.nw.nos.boeing.com ([169.254.5.96]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 07:58:45 -0700 From: "Templin, Fred L" To: Ronald Bonica , Doug Barton Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoEVtgyhVSFES4anVAs4ggI5lci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA834A Date: Wed, 10 Jul 2013 14:58:44 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:59:24 -0000 Hi Ron, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, July 09, 2013 5:33 PM > To: Doug Barton > Cc: ipv6@ietf.org > Subject: RE: Meta-issues: On the deprecation of the fragmentation > function >=20 > Doug, >=20 > Let's see if we can find some common ground. >=20 > Assume that the IETF is considering a new protocol that doesn't run > over TCP. In order to deal with MTU issues, the new protocol must do > one of the following: >=20 > a) implement PLMTUD or PMTUD > b) restrict itself to sending PDUs so small that when they are > encapsulated in an IPv6 header, the resulting packet will not exceed > 1280 bytes > c) rely on IPv6 fragmentation >=20 > Is there ever a reason why c) is better than a) or b). For that matter, > is c) ever an acceptable solution? Fragmentation at a tunnel ingress router is unavoidable. Proof: - a tunnel configures a 1280 MTU - When its packets are encapsulated they emerge as (1280 + HLEN) (the length of the encapsulating headers) - the tunnel crosses a 1280 link somewhere in the path to the egress - the packet is dropped with a PTB signal sent back - the ingress now has two choices: 1) start fragmenting, 2) quit. Thanks - Fred fred.l.templin@boeing.com=20 > Ron >=20 > > -----Original Message----- > > From: Doug Barton [mailto:dougb@dougbarton.us] > > Sent: Tuesday, July 09, 2013 2:41 PM > > To: Ronald Bonica > > Cc: ipv6@ietf.org > > Subject: Re: Meta-issues: On the deprecation of the fragmentation > > function > > > > On 07/09/2013 11:12 AM, Ronald Bonica wrote: > > > Doug, > > > > > > It might be interesting to revisit what we mean by deprecating IPv6 > > fragmentation.... > > > > > > It means that the IETF will not approve any new protocols that rely > > upon IPv6 fragmentation. Nothing more, nothing less. > > > > Thanks for clarifying. FWIW, I understand what is being proposed, and > I > > still think it's a bad idea. > > > > Doug > > > > >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Wed Jul 10 08:24:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2EF21F9D4B for ; Wed, 10 Jul 2013 08:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 7pn--6qN1ufV for ; Wed, 10 Jul 2013 08:24:01 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id E829821F9D55 for ; Wed, 10 Jul 2013 08:23:58 -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 r6AFNuci008217 for ; Wed, 10 Jul 2013 08:23:57 -0700 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6AFNuti008214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Jul 2013 08:23:56 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.81]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 08:23:58 -0700 From: "Templin, Fred L" To: RJ Atkinson , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfQZWEVtgyhVSFES4anVAs4ggI5leAgIw Date: Wed, 10 Jul 2013 15:23:57 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B82FB@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 15:24:11 -0000 Hi Ran, Cutting a bunch of stuff that basically repeats what I already said: > Well, at the moment, on-path fragmentation is not actually prohibited, > as near as several implementers (including me) can tell, although it > absolutely is never required to be supported by routers. Routers that configure RFC2473 tunnels require fragmentation in order to meet the IPv6 minMTU. This is not fragmentation of the original packet before encapsulation but rather fragmentation of the tunneled packet after encapsulation. =20 > Everyone agrees that on-path fragmentation by routers is generally > undesirable. Again, never say "always" and never say "never". Undesirable or not, fragmentation at tunnel routers is unavoidable in some circumstances. > Everyone also agrees that a router, for example a backbone high-speed > router, > must not be forced to fragment anything -- for practical performance > reasons > that are widely understood. As long as there is an IPv6 minMTU, tunnels will need to support some form of fragmentation. And, because PMTUD doesn't work very well, there needs to be an IPv6 minMTU below which the host is guaranteed that its packets will be delivered.=20 > This difference between "not required" and "prohibited" is critical > for IPv6 deployment over low-rate links having a smaller MTU size, > as I outlined in my previous note within this thread. You seem to have not seen the previous thread where I already showed the need to accommodate low-end links (6lowpan, aviation, tactical military, etc.). > If a goal of this WG is to encourage deployment of IPv6 and transition > from IPv4 to IPv6, then it would be best not to change the current > status > of fragmentation in IPv6 -- and it would be helpful to change the > minimum > Link MTU to a value lower than 1280 (or deprecate the Minimum Link MTU > specification entirely, although that seems quite unlikely here now). I don't think changing the minMTU to something smaller than 1280 now is necessary or even desirable. And, since PMTUD doesn't work very well, there needs to be *some* minMTU below which the host can be absolutely assured that its packets will get through. > I'd really like to see IPv6 get universally deployed. These particular > changes are significant barriers to that happening and create perverse > incentives either to stay with IPv6 forever or to build & deploy > IPv6::IPv4 translational gateways (ugh). I want IPv6 too. But, I want it to go forward with no limits on migration to larger packets. In other words, no more magic numbers except 2^16 for IPv4 and 2^32 for IPv6. Thanks - Fred fred.l.templin@boeing.com From rbonica@juniper.net Wed Jul 10 08:50:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F397C11E8123 for ; Wed, 10 Jul 2013 08:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lN8wbzfbs-I for ; Wed, 10 Jul 2013 08:50:01 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 08E0411E811D for ; Wed, 10 Jul 2013 08:50:00 -0700 (PDT) Received: from mail157-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE002.bigfish.com (10.236.130.65) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 15:50:00 +0000 Received: from mail157-co9 (localhost [127.0.0.1]) by mail157-co9-R.bigfish.com (Postfix) with ESMTP id 582223C0118 for ; Wed, 10 Jul 2013 15:50:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I148cI542I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail157-co9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail157-co9 (localhost.localdomain [127.0.0.1]) by mail157-co9 (MessageSwitch) id 1373471397663197_22304; Wed, 10 Jul 2013 15:49:57 +0000 (UTC) Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.236]) by mail157-co9.bigfish.com (Postfix) with ESMTP id 9C7E0120088 for ; Wed, 10 Jul 2013 15:49:57 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 15:49:56 +0000 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; Wed, 10 Jul 2013 08:49:56 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 10 Jul 2013 08:49:55 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 10 Jul 2013 08:53:37 -0700 Received: from mail201-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 15:49:54 +0000 Received: from mail201-co1 (localhost [127.0.0.1]) by mail201-co1-R.bigfish.com (Postfix) with ESMTP id 561F9A80521 for ; Wed, 10 Jul 2013 15:49:54 +0000 (UTC) Received: from mail201-co1 (localhost.localdomain [127.0.0.1]) by mail201-co1 (MessageSwitch) id 1373471392796276_15756; Wed, 10 Jul 2013 15:49:52 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.228]) by mail201-co1.bigfish.com (Postfix) with ESMTP id BFB4244004A; Wed, 10 Jul 2013 15:49:52 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 15:49:51 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.145]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0329.000; Wed, 10 Jul 2013 15:49:50 +0000 From: Ronald Bonica To: "Templin, Fred L" , Doug Barton Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoLtuD7p8LeE2Fhu/K5qJEnJlci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA9WwAgAALYhA= Date: Wed, 10 Jul 2013 15:49:50 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BOEING.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%DOUGBARTON.US$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 15:50:07 -0000 Fred, There are alternatives.... Probably, the best alternative is for the tunnel ingress router to tunnel i= ngress router to discover the PMTU to the egress. When the tunnel ingress r= outer receives a packet that is so large that it cannot be forwarded throug= h the tunnel, it discards the packet and sends an ICMP PTB to the packet's = originator. The packet's originator then modifies its sending behavior base= d upon its new estimate of the PMTU associated with the destination. So, for the purposes of MTU management, the tunnel is just another link. Ron =20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Wednesday, July 10, 2013 10:59 AM > To: Ronald Bonica; Doug Barton > Cc: ipv6@ietf.org > Subject: RE: Meta-issues: On the deprecation of the fragmentation > function >=20 > Hi Ron, >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > Of Ronald Bonica > > Sent: Tuesday, July 09, 2013 5:33 PM > > To: Doug Barton > > Cc: ipv6@ietf.org > > Subject: RE: Meta-issues: On the deprecation of the fragmentation > > function > > > > Doug, > > > > Let's see if we can find some common ground. > > > > Assume that the IETF is considering a new protocol that doesn't run > > over TCP. In order to deal with MTU issues, the new protocol must do > > one of the following: > > > > a) implement PLMTUD or PMTUD > > b) restrict itself to sending PDUs so small that when they are > > encapsulated in an IPv6 header, the resulting packet will not exceed > > 1280 bytes > > c) rely on IPv6 fragmentation > > > > Is there ever a reason why c) is better than a) or b). For that > > matter, is c) ever an acceptable solution? >=20 > Fragmentation at a tunnel ingress router is unavoidable. Proof: >=20 > - a tunnel configures a 1280 MTU > - When its packets are encapsulated they emerge as (1280 + HLEN) > (the length of the encapsulating headers) > - the tunnel crosses a 1280 link somewhere in the path to the egress > - the packet is dropped with a PTB signal sent back > - the ingress now has two choices: 1) start fragmenting, 2) quit. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Ron > > > > > -----Original Message----- > > > From: Doug Barton [mailto:dougb@dougbarton.us] > > > Sent: Tuesday, July 09, 2013 2:41 PM > > > To: Ronald Bonica > > > Cc: ipv6@ietf.org > > > Subject: Re: Meta-issues: On the deprecation of the fragmentation > > > function > > > > > > On 07/09/2013 11:12 AM, Ronald Bonica wrote: > > > > Doug, > > > > > > > > It might be interesting to revisit what we mean by deprecating > > > > IPv6 > > > fragmentation.... > > > > > > > > It means that the IETF will not approve any new protocols that > > > > rely > > > upon IPv6 fragmentation. Nothing more, nothing less. > > > > > > Thanks for clarifying. FWIW, I understand what is being proposed, > > > and > > I > > > still think it's a bad idea. > > > > > > Doug > > > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 From Fred.L.Templin@boeing.com Wed Jul 10 09:00:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A298611E8169 for ; Wed, 10 Jul 2013 08:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 UE-oxmzzjKoL for ; Wed, 10 Jul 2013 08:59:47 -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 02EF311E8135 for ; Wed, 10 Jul 2013 08:59:32 -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 r6AFxVtx028313 for ; Wed, 10 Jul 2013 10:59:32 -0500 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6AFxUwO028286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 10 Jul 2013 10:59:30 -0500 Received: from XCH-BLV-103.nw.nos.boeing.com (130.247.25.118) by XCH-NWHT-06.nw.nos.boeing.com (130.247.25.110) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 10 Jul 2013 08:59:29 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-103.nw.nos.boeing.com ([169.254.3.252]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 08:59:29 -0700 From: "Templin, Fred L" To: Ronald Bonica , Doug Barton Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoEVtgyhVSFES4anVAs4ggI5lci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA9WwAgAALYhCAAAM8MA== Date: Wed, 10 Jul 2013 15:59:29 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B8373@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:00:05 -0000 Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Wednesday, July 10, 2013 8:50 AM > To: Templin, Fred L; Doug Barton > Cc: ipv6@ietf.org > Subject: RE: Meta-issues: On the deprecation of the fragmentation > function >=20 > Fred, >=20 > There are alternatives.... >=20 > Probably, the best alternative is for the tunnel ingress router to > tunnel ingress router to discover the PMTU to the egress. When the > tunnel ingress router receives a packet that is so large that it cannot > be forwarded through the tunnel, it discards the packet and sends an > ICMP PTB to the packet's originator. The packet's originator then > modifies its sending behavior based upon its new estimate of the PMTU > associated with the destination. Sure, the tunnel ingress can probe the path to the egress; such a probing method is already covered by SEAL. But, if the path MTU will not accommodate a packet that after encapsulation is as large as (1280 + HLEN) there is no alternative for the ingress other than to start fragmenting since the ingress is not allowed to send a PTB message reporting a size smaller than 1280.=20 > So, for the purposes of MTU management, the tunnel is just another > link. True, but I want that link to have an unbounded MTU. In other words, encapsulate and send everything regardless of its size even if a little bit of fragmentation is necessary (but try to tune out the fragmentation if possible). You should really have a look at my new draft: http://tools.ietf.org/html/draft-generic-6man-tunfrag-08 Thanks - Fred fred.l.templin@boeing.com =20 > Ron >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Wednesday, July 10, 2013 10:59 AM > > To: Ronald Bonica; Doug Barton > > Cc: ipv6@ietf.org > > Subject: RE: Meta-issues: On the deprecation of the fragmentation > > function > > > > Hi Ron, > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > > > Of Ronald Bonica > > > Sent: Tuesday, July 09, 2013 5:33 PM > > > To: Doug Barton > > > Cc: ipv6@ietf.org > > > Subject: RE: Meta-issues: On the deprecation of the fragmentation > > > function > > > > > > Doug, > > > > > > Let's see if we can find some common ground. > > > > > > Assume that the IETF is considering a new protocol that doesn't run > > > over TCP. In order to deal with MTU issues, the new protocol must > do > > > one of the following: > > > > > > a) implement PLMTUD or PMTUD > > > b) restrict itself to sending PDUs so small that when they are > > > encapsulated in an IPv6 header, the resulting packet will not > exceed > > > 1280 bytes > > > c) rely on IPv6 fragmentation > > > > > > Is there ever a reason why c) is better than a) or b). For that > > > matter, is c) ever an acceptable solution? > > > > Fragmentation at a tunnel ingress router is unavoidable. Proof: > > > > - a tunnel configures a 1280 MTU > > - When its packets are encapsulated they emerge as (1280 + HLEN) > > (the length of the encapsulating headers) > > - the tunnel crosses a 1280 link somewhere in the path to the > egress > > - the packet is dropped with a PTB signal sent back > > - the ingress now has two choices: 1) start fragmenting, 2) quit. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Ron > > > > > > > -----Original Message----- > > > > From: Doug Barton [mailto:dougb@dougbarton.us] > > > > Sent: Tuesday, July 09, 2013 2:41 PM > > > > To: Ronald Bonica > > > > Cc: ipv6@ietf.org > > > > Subject: Re: Meta-issues: On the deprecation of the fragmentation > > > > function > > > > > > > > On 07/09/2013 11:12 AM, Ronald Bonica wrote: > > > > > Doug, > > > > > > > > > > It might be interesting to revisit what we mean by deprecating > > > > > IPv6 > > > > fragmentation.... > > > > > > > > > > It means that the IETF will not approve any new protocols that > > > > > rely > > > > upon IPv6 fragmentation. Nothing more, nothing less. > > > > > > > > Thanks for clarifying. FWIW, I understand what is being proposed, > > > > and > > > I > > > > still think it's a bad idea. > > > > > > > > Doug > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > - > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > ------------------------------------------------------------------- > - > > >=20 >=20 From rbonica@juniper.net Wed Jul 10 10:12:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFA321F9A3D for ; Wed, 10 Jul 2013 10:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tEC80-2F-u6 for ; Wed, 10 Jul 2013 10:12:09 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3166B21F9EFE for ; Wed, 10 Jul 2013 10:12:09 -0700 (PDT) Received: from mail77-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 17:12:08 +0000 Received: from mail77-tx2 (localhost [127.0.0.1]) by mail77-tx2-R.bigfish.com (Postfix) with ESMTP id 747B24201C3 for ; Wed, 10 Jul 2013 17:12:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail77-tx2: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail77-tx2 (localhost.localdomain [127.0.0.1]) by mail77-tx2 (MessageSwitch) id 1373476326993623_19442; Wed, 10 Jul 2013 17:12:06 +0000 (UTC) Received: from TX2EHSMHS011.bigfish.com (unknown [10.9.14.254]) by mail77-tx2.bigfish.com (Postfix) with ESMTP id EB5A360263 for ; Wed, 10 Jul 2013 17:12:06 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.51) by TX2EHSMHS011.bigfish.com (10.9.99.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 17:12:02 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Jul 2013 10:12:01 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 10 Jul 2013 10:12:00 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 10 Jul 2013 10:15:43 -0700 Received: from mail36-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 17:11:59 +0000 Received: from mail36-va3 (localhost [127.0.0.1]) by mail36-va3-R.bigfish.com (Postfix) with ESMTP id B670640C4A for ; Wed, 10 Jul 2013 17:11:59 +0000 (UTC) Received: from mail36-va3 (localhost.localdomain [127.0.0.1]) by mail36-va3 (MessageSwitch) id 1373476317688769_23389; Wed, 10 Jul 2013 17:11:57 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.226]) by mail36-va3.bigfish.com (Postfix) with ESMTP id 99C733E006C; Wed, 10 Jul 2013 17:11:57 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 17:11:57 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.145]) by BY2PRD0512HT002.namprd05.prod.outlook.com ([10.255.243.35]) with mapi id 14.16.0329.000; Wed, 10 Jul 2013 17:11:51 +0000 From: Ronald Bonica To: "Templin, Fred L" , Doug Barton Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoLtuD7p8LeE2Fhu/K5qJEnJlci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA9WwAgAALYhCAAAWYgIAACt+Q Date: Wed, 10 Jul 2013 17:11:51 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509FBBD4B@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B8373@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180B8373@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BOEING.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%DOUGBARTON.US$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 17:12:16 -0000 >=20 > Sure, the tunnel ingress can probe the path to the egress; such a > probing method is already covered by SEAL. Most GRE implementations do this, too. But, if the path MTU will > not accommodate a packet that after encapsulation is as large as > (1280 + HLEN) there is no alternative for the ingress other than to > start fragmenting since the ingress is not allowed to send a PTB > message reporting a size smaller than 1280. I understand that you want to solve for the use-case in which a tunnel inte= rior link has MTU < (1280 + HLEN). But before solving for that use-case, we= need to do a cost/benefit analysis. We understand the cost of solving for this use-case. The task of reassembly= is moved to the egress router. So, we need to make sure that the egress ro= uter is large enough to handle the task of reassembly and we need to make s= ure that its resources cannot be monopolized by a DoS attack. We also have = to maintain our fragmentation capability. Note that some of the cost is absorbed by the owner of the egress router. H= owever, a portion of the cost is absorbed by the entire community, as they = deal with the operation complexity associated with fragmentation. Now let's try to understand the benefit. Is there an installed base of IPv6= -capable links with MTU < (1280 + HLEN) that carry traffic between tunnel e= ndpoints? Is there a reason why someone might want to design a network this= way? If we were to solve for this use-case, who would be the beneficiary? Possib= ly the party deploying the MTU-challenged link? Or, asked another way, woul= d cost be assigned to the beneficiary? Ron From Fred.L.Templin@boeing.com Wed Jul 10 10:24:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A021F9E0C for ; Wed, 10 Jul 2013 10:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 xkDuZ2nZSu1X for ; Wed, 10 Jul 2013 10:24:10 -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 189DF21F9EB0 for ; Wed, 10 Jul 2013 10:24:09 -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 r6AHOIC2003439 for ; Wed, 10 Jul 2013 10:24:18 -0700 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6AHOIGl003436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Jul 2013 10:24:18 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-511.sw.nos.boeing.com ([169.254.11.108]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 10:23:36 -0700 From: "Templin, Fred L" To: Ronald Bonica , Doug Barton Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoEVtgyhVSFES4anVAs4ggI5lci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA9WwAgAALYhCAAAWYgIAACt+QgAAKDoA= Date: Wed, 10 Jul 2013 17:23:35 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B84A7@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B8373@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBBD4B@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509FBBD4B@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 17:24:16 -0000 Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Wednesday, July 10, 2013 10:12 AM > To: Templin, Fred L; Doug Barton > Cc: ipv6@ietf.org > Subject: RE: Meta-issues: On the deprecation of the fragmentation > function >=20 >=20 > > > > Sure, the tunnel ingress can probe the path to the egress; such a > > probing method is already covered by SEAL. >=20 > Most GRE implementations do this, too. >=20 > But, if the path MTU will > > not accommodate a packet that after encapsulation is as large as > > (1280 + HLEN) there is no alternative for the ingress other than to > > start fragmenting since the ingress is not allowed to send a PTB > > message reporting a size smaller than 1280. >=20 > I understand that you want to solve for the use-case in which a tunnel > interior link has MTU < (1280 + HLEN). Yes; for example, a 1280 MTU tunnel crossing another 1280 MTU tunnel. > But before solving for that use- > case, we need to do a cost/benefit analysis. >=20 > We understand the cost of solving for this use-case. The task of > reassembly is moved to the egress router. So, we need to make sure that > the egress router is large enough to handle the task of reassembly and > we need to make sure that its resources cannot be monopolized by a DoS > attack. We also have to maintain our fragmentation capability. I understand that. But a couple of points: 1) the egress will never be asked to reassemble more than (1500 + HLEN) 2) the ingress will feel the pain too and will be motivated to tune out the fragmentation =20 > Note that some of the cost is absorbed by the owner of the egress > router. However, a portion of the cost is absorbed by the entire > community, as they deal with the operation complexity associated with > fragmentation. The community can help to get rid of fragmentation. All they have to do is configure a larger MTU on links that connect routers to other routers. The MTU should be (1500 + HLEN) or larger. > Now let's try to understand the benefit. Is there an installed base of > IPv6-capable links with MTU < (1280 + HLEN) that carry traffic between > tunnel endpoints? Is there a reason why someone might want to design a > network this way? Tunnels within tunnels, as one example. They are a common use case in operational practice today. > If we were to solve for this use-case, who would be the beneficiary? The entire Internet would benefit, since all barriers to larger MTUs would be removed. > Possibly the party deploying the MTU-challenged link? Or, asked another > way, would cost be assigned to the beneficiary? Not sure I understood that. Everyone benefits, but the tunnel endpoints doing the fragmentation have to do what is necessary to maintain the tunnel in any event. Thanks - Fred fred.l.templin@boeing.com > Ron >=20 >=20 >=20 >=20 From jhw@apple.com Wed Jul 10 11:23:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557FE21F9FA1 for ; Wed, 10 Jul 2013 11:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPiQ1KQnW-1S for ; Wed, 10 Jul 2013 11:22:56 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id C247F21F9EC2 for ; Wed, 10 Jul 2013 11:22:56 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPQ0074YGDWJQ40@mail-out.apple.com> for ipv6@ietf.org; Wed, 10 Jul 2013 11:22:50 -0700 (PDT) X-AuditID: 11807153-b7fed6d0000060fa-89-51dda67a29d3 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 16.B1.24826.A76ADD15; Wed, 10 Jul 2013 11:22:50 -0700 (PDT) Received: from [17.114.6.207] by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MPQ00ECOGE1W510@sesame.apple.com> for ipv6@ietf.org; Wed, 10 Jul 2013 11:22:49 -0700 (PDT) Subject: Re: Meta-issues: On the deprecation of the fragmentation function From: james woodyatt In-reply-to: <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Wed, 10 Jul 2013 11:22:49 -0700 Message-id: References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> To: "ipv6@ietf.org" X-Mailer: Apple Mail (2.1784.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FDcoFu17G6gwflZHBYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxolP8xgLVrJXnHg8nb2B8T1rFyMnh4SAicT3GU/YIWwxiQv3 1rN1MXJxCAn0MUlcXL0ByvnLKPFi8ztGkCpmAS2J9TuPM3UxcnDwChhIvD/kBBIWFvCSOL1y DzOIzSagIvHt8l0mEJtTIFni/7pWMJtFQFXiz+HlzBBjtCWevLvACjHGRmLpAhWIVVtYJFoO rAGrFxFQlpjRfY4N4jh5ic6G16wTGPlnIbliFsIVs5BMXcDIvIpRoCg1J7HSWC+xoCAnVS85 P3cTIzi8CoN3MP5ZZnWIUYCDUYmHtyH+bqAQa2JZcWXuIUYJDmYlEd6TU4BCvCmJlVWpRfnx RaU5qcWHGKU5WJTEeS31bgcKCaQnlqRmp6YWpBbBZJk4OKUaGKNPWmkGP+nRj3R4ELq5OfeZ xPn805L9fQkr9xTMSxb40lQpfPGwieiFvHaLevf+b3KstellS85bxwhm7b6k8i1U/aOD3kqT kG2iZusq/xd4GOnzL/h8Te1iuGKkxh2r+OMSLSw1n7qkN8WrbP7ld79h6bpPX2X8ZvJNTD+S n3pafvW3iqTXSizFGYmGWsxFxYkA+nH9HisCAAA= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:23:04 -0000 On Jul 10, 2013, at 08:49 , Ronald Bonica wrote: > [...] > Probably, the best alternative is for the tunnel ingress router to tunnel ingress router to discover the PMTU to the egress. When the tunnel ingress router receives a packet that is so large that it cannot be forwarded through the tunnel, it discards the packet and sends an ICMP PTB to the packet's originator. The packet's originator then modifies its sending behavior based upon its new estimate of the PMTU associated with the destination. > [...] ICMPv6 packet too big errors are unreliable on the real-world Internet. I hate to sound like a broken record, but I will: I look forward to reviewing a proposal to update to Generic Packet Tunneling in IPv6 [RFC 2473] for implementing tunnel path MTU discovery at the encapsulation layer [c.f. RFC 4821]. -- james woodyatt core os networking From rbonica@juniper.net Wed Jul 10 12:22:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ECC21F9CE0 for ; Wed, 10 Jul 2013 12:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.753 X-Spam-Level: X-Spam-Status: No, score=-100.753 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sibgcd-FOzaT for ; Wed, 10 Jul 2013 12:22:00 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3A10C21F9B1E for ; Wed, 10 Jul 2013 12:22:00 -0700 (PDT) Received: from mail113-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE038.bigfish.com (10.174.4.101) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 19:21:51 +0000 Received: from mail113-db8 (localhost [127.0.0.1]) by mail113-db8-R.bigfish.com (Postfix) with ESMTP id 787A61C00DA for ; Wed, 10 Jul 2013 19:21:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz98dI9371I542I1432I1415Idb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail113-db8: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail113-db8 (localhost.localdomain [127.0.0.1]) by mail113-db8 (MessageSwitch) id 13734841105554_14224; Wed, 10 Jul 2013 19:21:50 +0000 (UTC) Received: from DB8EHSMHS014.bigfish.com (unknown [10.174.8.252]) by mail113-db8.bigfish.com (Postfix) with ESMTP id F12EF2600A8 for ; Wed, 10 Jul 2013 19:21:49 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.53) by DB8EHSMHS014.bigfish.com (10.174.4.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 10 Jul 2013 19:21:49 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Jul 2013 12:21:42 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 10 Jul 2013 12:21:42 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.208) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 10 Jul 2013 12:25:24 -0700 Received: from mail105-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 19:21:40 +0000 Received: from mail105-am1 (localhost [127.0.0.1]) by mail105-am1-R.bigfish.com (Postfix) with ESMTP id 31D27260124 for ; Wed, 10 Jul 2013 19:21:40 +0000 (UTC) Received: from mail105-am1 (localhost.localdomain [127.0.0.1]) by mail105-am1 (MessageSwitch) id 1373484098833379_28337; Wed, 10 Jul 2013 19:21:38 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.227]) by mail105-am1.bigfish.com (Postfix) with ESMTP id BDA72380255; Wed, 10 Jul 2013 19:21:38 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 10 Jul 2013 19:21:38 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.145]) by BY2PRD0512HT004.namprd05.prod.outlook.com ([10.255.243.37]) with mapi id 14.16.0329.000; Wed, 10 Jul 2013 19:21:31 +0000 From: Ronald Bonica To: james woodyatt , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoLtuD7p8LeE2Fhu/K5qJEnJlci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA9WwAgAALYhCAAC2kgIAAD8OA Date: Wed, 10 Jul 2013 19:21:30 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509FBBF5E@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%APPLE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:22:06 -0000 Hi James, If ICMPv6 PTB messages are unreliable, fragmentation breaks just as badly a= s PMTUD. At the risk of going off-topic, please take a look at draft-bonica-intarea-= gre-mtu-02. Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > james woodyatt > Sent: Wednesday, July 10, 2013 2:23 PM > To: ipv6@ietf.org > Subject: Re: Meta-issues: On the deprecation of the fragmentation > function >=20 > On Jul 10, 2013, at 08:49 , Ronald Bonica wrote: > > [...] > > Probably, the best alternative is for the tunnel ingress router to > tunnel ingress router to discover the PMTU to the egress. When the > tunnel ingress router receives a packet that is so large that it cannot > be forwarded through the tunnel, it discards the packet and sends an > ICMP PTB to the packet's originator. The packet's originator then > modifies its sending behavior based upon its new estimate of the PMTU > associated with the destination. > > [...] >=20 > ICMPv6 packet too big errors are unreliable on the real-world Internet. >=20 > I hate to sound like a broken record, but I will: I look forward to > reviewing a proposal to update to Generic Packet Tunneling in IPv6 [RFC > 2473] for implementing tunnel path MTU discovery at the encapsulation > layer [c.f. RFC 4821]. >=20 >=20 > -- > james woodyatt > core os networking >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From Fred.L.Templin@boeing.com Wed Jul 10 12:39:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1B21F9EBD for ; Wed, 10 Jul 2013 12:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 Qn8R+YQ0+snK for ; Wed, 10 Jul 2013 12:39:30 -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 B5B2D21F9EB7 for ; Wed, 10 Jul 2013 12:39:30 -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 r6AJdTBE016894 for ; Wed, 10 Jul 2013 14:39:29 -0500 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6AJdSCv016872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Jul 2013 14:39:29 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.89]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 12:39:28 -0700 From: "Templin, Fred L" To: james woodyatt , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfZp7EVtgyhVSFES4anVAs4ggI5leTEDg Date: Wed, 10 Jul 2013 19:39:27 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B86A9@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:39:36 -0000 Hi James, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > james woodyatt > Sent: Wednesday, July 10, 2013 11:23 AM > To: ipv6@ietf.org > Subject: Re: Meta-issues: On the deprecation of the fragmentation > function >=20 > On Jul 10, 2013, at 08:49 , Ronald Bonica wrote: > > [...] > > Probably, the best alternative is for the tunnel ingress router to > tunnel ingress router to discover the PMTU to the egress. When the > tunnel ingress router receives a packet that is so large that it cannot > be forwarded through the tunnel, it discards the packet and sends an > ICMP PTB to the packet's originator. The packet's originator then > modifies its sending behavior based upon its new estimate of the PMTU > associated with the destination. > > [...] >=20 > ICMPv6 packet too big errors are unreliable on the real-world Internet. >=20 > I hate to sound like a broken record, but I will: I look forward to > reviewing a proposal to update to Generic Packet Tunneling in IPv6 [RFC > 2473] for implementing tunnel path MTU discovery at the encapsulation > layer [c.f. RFC 4821]. Wrap your RFC2473 tunnel in SEAL and you are good to go (see draft-templin-intarea-seal). A quick read of Section 4 of my new draft should be all you need to understand what I'm talking about: http://tools.ietf.org/html/draft-generic-6man-tunfrag-08 Note however that all the tunnel needs is a limited application of RFC4821 to ensure that the *required* packet sizes are accommodated. For larger packets, assume that the hosts sending large packets are using RFC4821 themselves (so the tunnel doesn't have to). All the tunnel needs to do is "take care of the smalls, and let the bigs take care of themselves". Thanks - Fred fred.l.templin@boeing.com > -- > james woodyatt > core os networking >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Wed Jul 10 12:55:58 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA5621F9D8D for ; Wed, 10 Jul 2013 12:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 t5uM7Fel5XDW for ; Wed, 10 Jul 2013 12:55:53 -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 9B7B221F99BF for ; Wed, 10 Jul 2013 12:55:53 -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 r6AJtmQP010698 for ; Wed, 10 Jul 2013 14:55:48 -0500 Received: from XCH-PHX-412.sw.nos.boeing.com (xch-phx-412.sw.nos.boeing.com [10.57.37.44]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6AJtkJN010670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Jul 2013 14:55:47 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-412.sw.nos.boeing.com ([169.254.12.62]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 12:55:46 -0700 From: "Templin, Fred L" To: Ronald Bonica , james woodyatt , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoEVtgyhVSFES4anVAs4ggI5lci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA9WwAgAALYhCAAC2kgIAAD8OAgAAJwvA= Date: Wed, 10 Jul 2013 19:55:46 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B8722@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBBF5E@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509FBBF5E@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:55:58 -0000 Hi Ron, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Wednesday, July 10, 2013 12:22 PM > To: james woodyatt; ipv6@ietf.org > Subject: RE: Meta-issues: On the deprecation of the fragmentation > function >=20 > Hi James, >=20 > If ICMPv6 PTB messages are unreliable, fragmentation breaks just as > badly as PMTUD. I'm trying to understand that, but maybe you are talking about IP fragmentation? SEAL fragmentation is a different thing, and can be used in place of IP fragmentation. Thanks - Fred fred.l.templin@boeing.com > At the risk of going off-topic, please take a look at draft-bonica- > intarea-gre-mtu-02. >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of > > james woodyatt > > Sent: Wednesday, July 10, 2013 2:23 PM > > To: ipv6@ietf.org > > Subject: Re: Meta-issues: On the deprecation of the fragmentation > > function > > > > On Jul 10, 2013, at 08:49 , Ronald Bonica > wrote: > > > [...] > > > Probably, the best alternative is for the tunnel ingress router to > > tunnel ingress router to discover the PMTU to the egress. When the > > tunnel ingress router receives a packet that is so large that it > cannot > > be forwarded through the tunnel, it discards the packet and sends an > > ICMP PTB to the packet's originator. The packet's originator then > > modifies its sending behavior based upon its new estimate of the PMTU > > associated with the destination. > > > [...] > > > > ICMPv6 packet too big errors are unreliable on the real-world > Internet. > > > > I hate to sound like a broken record, but I will: I look forward to > > reviewing a proposal to update to Generic Packet Tunneling in IPv6 > [RFC > > 2473] for implementing tunnel path MTU discovery at the encapsulation > > layer [c.f. RFC 4821]. > > > > > > -- > > james woodyatt > > core os networking > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Wed Jul 10 13:07:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7721F9E91 for ; Wed, 10 Jul 2013 13:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 tYNCLbpv+pFQ for ; Wed, 10 Jul 2013 13:07:34 -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 704C221F9A51 for ; Wed, 10 Jul 2013 13:07:34 -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 r6AK7XBZ021884 for ; Wed, 10 Jul 2013 13:07:33 -0700 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6AK7X8h021874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 10 Jul 2013 13:07:33 -0700 Received: from XCH-BLV-102.nw.nos.boeing.com (130.247.25.117) by XCH-NWHT-10.nw.nos.boeing.com (130.247.25.113) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 10 Jul 2013 13:07:32 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.19]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 13:07:32 -0700 From: "Templin, Fred L" To: james woodyatt , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfZp7EVtgyhVSFES4anVAs4ggI5leTEDggAAJ9YA= Date: Wed, 10 Jul 2013 20:07:31 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B875D@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B86A9@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180B86A9@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:07:43 -0000 Hi, > A quick read of Section > 4 of my new draft should be all you need to understand > what I'm talking about: >=20 > http://tools.ietf.org/html/draft-generic-6man-tunfrag-08 Here is the text I'm talking about so I won't have to keep repeating myself: Thanks - Fred fred.l.templin@boeing.com --- 4. IPv6 Tunnels IPv6 tunnels are used for many purposes, including transition, security, mobility, routing control, etc. While it is assumed that transition mechanisms will eventually give way to native IPv6, it is clear that the use of tunnels for other purposes will continue and even expand. A long term strategy for dealing with tunnel MTUs is therefore required. Tunnels may cross links (perhaps even other tunnels) that configue only the IPv6 minMTU of 1280 bytes while the tunnel ingress must be able to send packets that are at least 1280 bytes in length so that the IPv6 minMTU is extended to the source. However, these tunneled packets become (1280 + HLEN) bytes on the wire (where HLEN is the length of the encapsulating headers), meaning that they would be vulerable to loss at a link within the tunnel that configures a smaller MTU. Therefore, the only way to satisfy the IPv6 minMTU is through network layer fragmentation and reassembly between the tunnel ingress and egress, where the ingress fragments its tunneled packets that are larger than (1280 - HLEN) bytes. Unfortunately, fragmentation and reassembly are a pain point for in- the-network routers - especially for those that are nearer the core of the network. It is therefore highly desirable for the tunnel ingress to discover whether this fragmentation and reassembly can be avoided. This can only be done by allowing the ingress to probe the path to the egress by sending whole 1500 byte probe packets to discover whether the probes can be delivered to the egress without fragmentation. These 1500 byte probes appear as (1500 + HLEN) bytes on the wire, therefore the path must support an MTU of at least this size in order for the probe to succeed. The tunnel fragmentation and reassembly strategy is therefore as follows: 1. When the tunnel ingress receives a packet that is no larger than (1280-HLEN) bytes, it encapsulates the packet and sends it to the egress without fragmentation. The egress will receive the packet since it is small enough to fit within the IPv6 minMTU of 1280 bytes. 2. When the tunnel egress receives a packet that is larger than 1500 bytes, it encapsulates the packet and sends it to the egress without fragmentation. If the packet is lost in the network due to a size restriction, the ingress may or may not reeceive a PTB message which it can then forward to the original soruce. Whether or not a PTB message is received, however, it is the responsibility of the original source to ensure that its packets larger than 1500 bytes are making it to the final destination by using a path probing technique such as specified by [RFC4821]. 3. When the tunnel ingress receives a packet larger than (1280 - HLEN) but no larger than 1500 bytes, and it is not yet known whether packets of this size can reach the egress without fragmentation, the ingress encapsulates the packet and uses network layer fragmentation to fragment it into two pieces that are each signifiicantly smaller than (1280 - HLEN) bytes. At the same time, the tunnel ingress sends an unfragmented 1500 byte probe packet toward the egress (subject to rate limiting) which will appear as (1500 + HLEN) bytes on the wire. If the egress receives the probe, it informs the ingress that the probe succeeded. If the probe succeeds, the ingress can suspend the fragmentation process and send packets between (1280-HLEN) and 1500 bytes without using fragmentation. This probing process exactly parallels [RFC4821]. In this method, the tunnel egress must configure a slightly larger MRU than the minMRU specified for IPv6 in order to accommodate the HLEN bytes of tunnel encapsulation during reassembly. 2KB is recommended as the minMRU for this reason. These procedures give way to the ability for the tunnel ingress to configure an unlimited MTU (theoretical limit is 2^16 bytes for IPv4 and 2^32 bytes for IPv6). They will therefore naturally lead to the Internet migrating to larger packet sizes with no dependence on traditional path MTU discovery. Operators will also soon discover that configuring larger MTUs on links between routers (e.g., 2KB or larger) will dampen the fragmentation and reassembly requirements until fragmentation and reassembly usage is gradually tuned out of the network. These procedures are not supported by the existing IPv6 fragmentation procedures, however they are exactly those specified in the Subnetwork Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal]. Widespread adoption of SEAL will therefore naturally lead to an Internet which no longer places MTU restrictions on tunnels and therefore supports natural migration to unbounded packet sizes. --- From jhw@apple.com Wed Jul 10 14:29:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D120721F9DB2 for ; Wed, 10 Jul 2013 14:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-OUmHPGoZNv for ; Wed, 10 Jul 2013 14:29:17 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9F24721F9D49 for ; Wed, 10 Jul 2013 14:29:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPQ005Y2OZNGAJ0@mail-out.apple.com> for ipv6@ietf.org; Wed, 10 Jul 2013 14:29:10 -0700 (PDT) X-AuditID: 1180715a-b7f306d000004235-9e-51ddd226e59a Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 27.6C.16949.622DDD15; Wed, 10 Jul 2013 14:29:10 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MPQ00429P0M5I90@aniseed.apple.com> for ipv6@ietf.org; Wed, 10 Jul 2013 14:29:10 -0700 (PDT) Subject: Re: Meta-issues: On the deprecation of the fragmentation function From: james woodyatt In-reply-to: <2CF4CB03E2AA464BA0982EC92A02CE2509FBBF5E@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Wed, 10 Jul 2013 14:29:10 -0700 Message-id: References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBBF5E@BY2PRD0512MB653.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1784.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAsrqt26W6gwc3PqhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv5Z3awF7fwVGz+wNjC28XQxcnJICJhIXJ1+gwnCFpO4cG89 WxcjF4eQQD+TxJXedVDOdCaJSZfOMYNUMQtoSazfeRyog4ODV8BA4v0hJ5CwsICXxOmVe8BK 2ARUJL5dvgs2lFMgWWLNjiUsIDaLgKrEqX2LGEFamQWUJf5eMIeYqC3x5N0FVhCbV8BGYsWt e0wQa/exSpzd/hdsjoiAusTjVdPYIA6Vl+hseM06gVFgFpKLZiFcNAvJ2AWMzKsYBYpScxIr zfQSCwpyUvWS83M3MYKDrjBqB2PDcqtDjAIcjEo8vA3xdwOFWBPLiitzDzFKcDArifCenAIU 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzsu5BiglkJ5YkpqdmlqQWgSTZeLglGpgnOyxwuD9BMa/ 5o1ikz8G7jw5ue3Kg63u2k+uP+j7ryZ/df9euQherkl2YcvEt8a9esUf+lJhe1lL1GIfhZ/3 IhZ5rfVnPfZuucU96QWzjxf+dLivJqlWkpzXf4fnSFeLk/iuL40nXsRm7ihZP/ceK0t/ngET R8C2OMuFc5NlYq5cM2cvDTocpcRSnJFoqMVcVJwIALlVtj02AgAA Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 21:29:23 -0000 On Jul 10, 2013, at 12:21 , Ronald Bonica wrote: > > If ICMPv6 PTB messages are unreliable, fragmentation breaks just as badly as PMTUD. > At the risk of going off-topic, please take a look at draft-bonica-intarea-gre-mtu-02. I did. I won't comment about that here, because I too don't want to drift off topic. Extending my remarks: Mr. Templin is right to point out that tunnels over networks where ICMPv6 Packet Too Big errors are not reliably delivered from the egress to the ingress, and also where such errors are not delivered from destination hosts back to the egress, have no choice but to assume the PMTU from the ingress to the egress is 1280 octets, and they must fragment packets that would exceed that length when encapsulated in an IPv6 header chain. If they cannot fragment, than paths through the tunnel do not meet the minimum MTU requirement. I agree with him that SEAL addresses this problem, by using a different mechanism to fragment that the RFC 2460 extension header we are proposing to deprecate, but RFC 2473 doesn't do that, and there is a procedural issue I am trying to surface here: if we're going to deprecate the fragmentation header, while at the same time recognizing that the Internet is unable to deliver ICMPv6 Packet Too Big errors reliably, then we are blowing a big hole in the standards by not promoting SEAL or something like it as a STANDARD replacement for GRE and RFC 2473 encapsulation. All I'm saying is that if we're going to start deprecating fragment headers, then let's make sure we are deprecating all of the things that rely on them, and providing a standard replacement for each of them in turn. [Insert here shopped version of classic Hyperbole And A Half Cartoon, saying "DEPRECATE ALL THE THINGS!"] -- james woodyatt core os networking From rbonica@juniper.net Thu Jul 11 06:50:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AF511E8172 for ; Thu, 11 Jul 2013 06:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.092 X-Spam-Level: X-Spam-Status: No, score=-101.092 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju1HNmETefmX for ; Thu, 11 Jul 2013 06:50:23 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6A14711E8175 for ; Thu, 11 Jul 2013 06:50:23 -0700 (PDT) Received: from mail147-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Jul 2013 13:50:22 +0000 Received: from mail147-co1 (localhost [127.0.0.1]) by mail147-co1-R.bigfish.com (Postfix) with ESMTP id BF0C79402FE for ; Thu, 11 Jul 2013 13:50:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz98dI9371I542I1432I1415Idb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail147-co1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rbonica@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail147-co1 (localhost.localdomain [127.0.0.1]) by mail147-co1 (MessageSwitch) id 1373550620759136_30893; Thu, 11 Jul 2013 13:50:20 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.228]) by mail147-co1.bigfish.com (Postfix) with ESMTP id ADBC0D8006C for ; Thu, 11 Jul 2013 13:50:20 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.52) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 11 Jul 2013 13:50:19 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Jul 2013 06:50:18 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 11 Jul 2013 06:50:18 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 11 Jul 2013 06:53:58 -0700 Received: from mail12-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Jul 2013 13:50:17 +0000 Received: from mail12-co1 (localhost [127.0.0.1]) by mail12-co1-R.bigfish.com (Postfix) with ESMTP id 86490401D3 for ; Thu, 11 Jul 2013 13:50:17 +0000 (UTC) Received: from mail12-co1 (localhost.localdomain [127.0.0.1]) by mail12-co1 (MessageSwitch) id 1373550615444199_14276; Thu, 11 Jul 2013 13:50:15 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.240]) by mail12-co1.bigfish.com (Postfix) with ESMTP id 668998015B; Thu, 11 Jul 2013 13:50:15 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 11 Jul 2013 13:50:11 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.145]) by BY2PRD0512HT002.namprd05.prod.outlook.com ([10.255.243.35]) with mapi id 14.16.0329.000; Thu, 11 Jul 2013 13:50:08 +0000 From: Ronald Bonica To: "Templin, Fred L" , james woodyatt , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoLtuD7p8LeE2Fhu/K5qJEnJlci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA9WwAgAALYhCAAC2kgIAAD8OAgAAKNQCAADgwEA== Date: Thu, 11 Jul 2013 13:50:07 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509FBC675@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBBF5E@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B8722@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180B8722@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BOEING.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%APPLE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:50:29 -0000 Yes, I am talking about IPv6 fragmentation. Ron > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Wednesday, July 10, 2013 3:56 PM > To: Ronald Bonica; james woodyatt; ipv6@ietf.org > Subject: RE: Meta-issues: On the deprecation of the fragmentation > function >=20 > Hi Ron, >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > Of Ronald Bonica > > Sent: Wednesday, July 10, 2013 12:22 PM > > To: james woodyatt; ipv6@ietf.org > > Subject: RE: Meta-issues: On the deprecation of the fragmentation > > function > > > > Hi James, > > > > If ICMPv6 PTB messages are unreliable, fragmentation breaks just as > > badly as PMTUD. >=20 > I'm trying to understand that, but maybe you are talking about IP > fragmentation? SEAL fragmentation is a different thing, and can be used > in place of IP fragmentation. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > At the risk of going off-topic, please take a look at draft-bonica- > > intarea-gre-mtu-02. > > > > Ron > > > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > > Of > > > james woodyatt > > > Sent: Wednesday, July 10, 2013 2:23 PM > > > To: ipv6@ietf.org > > > Subject: Re: Meta-issues: On the deprecation of the fragmentation > > > function > > > > > > On Jul 10, 2013, at 08:49 , Ronald Bonica > > wrote: > > > > [...] > > > > Probably, the best alternative is for the tunnel ingress router > to > > > tunnel ingress router to discover the PMTU to the egress. When the > > > tunnel ingress router receives a packet that is so large that it > > cannot > > > be forwarded through the tunnel, it discards the packet and sends > an > > > ICMP PTB to the packet's originator. The packet's originator then > > > modifies its sending behavior based upon its new estimate of the > > > PMTU associated with the destination. > > > > [...] > > > > > > ICMPv6 packet too big errors are unreliable on the real-world > > Internet. > > > > > > I hate to sound like a broken record, but I will: I look forward to > > > reviewing a proposal to update to Generic Packet Tunneling in IPv6 > > [RFC > > > 2473] for implementing tunnel path MTU discovery at the > > > encapsulation layer [c.f. RFC 4821]. > > > > > > > > > -- > > > james woodyatt > > > core os networking > > > > > > ------------------------------------------------------------------- > - > > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > ------------------------------------------------------------------- > - > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 From Fred.L.Templin@boeing.com Thu Jul 11 09:41:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315C521F9AC4 for ; Thu, 11 Jul 2013 09:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 vRTetfDnMeR2 for ; Thu, 11 Jul 2013 09:41:51 -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 C5DE021F9943 for ; Thu, 11 Jul 2013 09:41:51 -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 r6BGfp5p017077 for ; Thu, 11 Jul 2013 09:41:51 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6BGfnhE017059 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Jul 2013 09:41:49 -0700 Received: from XCH-BLV-404.nw.nos.boeing.com (130.247.25.157) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 11 Jul 2013 09:41:49 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.225]) with mapi id 14.02.0328.011; Thu, 11 Jul 2013 09:41:49 -0700 From: "Templin, Fred L" To: Ronald Bonica , james woodyatt , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOfLVoEVtgyhVSFES4anVAs4ggI5lci/SAgAAN9ACAAAD+gIAACExQgAALN4CAAF6xUIAA9WwAgAALYhCAAC2kgIAAD8OAgAAKNQCAADgwEIABI5lw Date: Thu, 11 Jul 2013 16:41:47 +0000 Message-ID: <2134F8430051B64F815C691A62D983180BA667@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBBF5E@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B8722@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBC675@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509FBC675@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:41:57 -0000 Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Thursday, July 11, 2013 6:50 AM > To: Templin, Fred L; james woodyatt; ipv6@ietf.org > Subject: RE: Meta-issues: On the deprecation of the fragmentation > function >=20 > Yes, I am talking about IPv6 fragmentation. OK, but if you want to deprecate that you need to replace it with something else like SEAL. Thanks - Fred fred.l.templin@boeing.com > Ron >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Wednesday, July 10, 2013 3:56 PM > > To: Ronald Bonica; james woodyatt; ipv6@ietf.org > > Subject: RE: Meta-issues: On the deprecation of the fragmentation > > function > > > > Hi Ron, > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > > > Of Ronald Bonica > > > Sent: Wednesday, July 10, 2013 12:22 PM > > > To: james woodyatt; ipv6@ietf.org > > > Subject: RE: Meta-issues: On the deprecation of the fragmentation > > > function > > > > > > Hi James, > > > > > > If ICMPv6 PTB messages are unreliable, fragmentation breaks just as > > > badly as PMTUD. > > > > I'm trying to understand that, but maybe you are talking about IP > > fragmentation? SEAL fragmentation is a different thing, and can be > used > > in place of IP fragmentation. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > At the risk of going off-topic, please take a look at draft-bonica- > > > intarea-gre-mtu-02. > > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf > > > Of > > > > james woodyatt > > > > Sent: Wednesday, July 10, 2013 2:23 PM > > > > To: ipv6@ietf.org > > > > Subject: Re: Meta-issues: On the deprecation of the fragmentation > > > > function > > > > > > > > On Jul 10, 2013, at 08:49 , Ronald Bonica > > > wrote: > > > > > [...] > > > > > Probably, the best alternative is for the tunnel ingress router > > to > > > > tunnel ingress router to discover the PMTU to the egress. When > the > > > > tunnel ingress router receives a packet that is so large that it > > > cannot > > > > be forwarded through the tunnel, it discards the packet and sends > > an > > > > ICMP PTB to the packet's originator. The packet's originator then > > > > modifies its sending behavior based upon its new estimate of the > > > > PMTU associated with the destination. > > > > > [...] > > > > > > > > ICMPv6 packet too big errors are unreliable on the real-world > > > Internet. > > > > > > > > I hate to sound like a broken record, but I will: I look forward > to > > > > reviewing a proposal to update to Generic Packet Tunneling in > IPv6 > > > [RFC > > > > 2473] for implementing tunnel path MTU discovery at the > > > > encapsulation layer [c.f. RFC 4821]. > > > > > > > > > > > > -- > > > > james woodyatt > > > > core os networking > > > > > > > > ----------------------------------------------------------------- > -- > > - > > > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > ----------------------------------------------------------------- > -- > > - > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > - > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > ------------------------------------------------------------------- > - > > >=20 >=20 From rbonica@juniper.net Thu Jul 11 10:42:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4523E11E8111 for ; Thu, 11 Jul 2013 10:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.597 X-Spam-Level: X-Spam-Status: No, score=-100.597 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1MHkveJkv0H for ; Thu, 11 Jul 2013 10:42:43 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2D12721F9FFD for ; Thu, 11 Jul 2013 10:42:43 -0700 (PDT) Received: from mail13-db9-R.bigfish.com (10.174.16.244) by DB9EHSOBE011.bigfish.com (10.174.14.74) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Jul 2013 17:42:40 +0000 Received: from mail13-db9 (localhost [127.0.0.1]) by mail13-db9-R.bigfish.com (Postfix) with ESMTP id E84E4400B4 for ; Thu, 11 Jul 2013 17:42:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz9371I936eI542I1432I1418I1528Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail13-db9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail13-db9 (localhost.localdomain [127.0.0.1]) by mail13-db9 (MessageSwitch) id 1373564557710104_13079; Thu, 11 Jul 2013 17:42:37 +0000 (UTC) Received: from DB9EHSMHS022.bigfish.com (unknown [10.174.16.236]) by mail13-db9.bigfish.com (Postfix) with ESMTP id 9C8C02A0049 for ; Thu, 11 Jul 2013 17:42:37 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by DB9EHSMHS022.bigfish.com (10.174.14.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 11 Jul 2013 17:42:35 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Jul 2013 10:42:34 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 11 Jul 2013 10:42:34 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.253) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 11 Jul 2013 10:46:14 -0700 Received: from mail210-db9-R.bigfish.com (10.174.16.235) by DB9EHSOBE004.bigfish.com (10.174.14.67) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Jul 2013 17:42:32 +0000 Received: from mail210-db9 (localhost [127.0.0.1]) by mail210-db9-R.bigfish.com (Postfix) with ESMTP id 4CF732A00C0 for ; Thu, 11 Jul 2013 17:42:32 +0000 (UTC) Received: from mail210-db9 (localhost.localdomain [127.0.0.1]) by mail210-db9 (MessageSwitch) id 1373564550199719_20359; Thu, 11 Jul 2013 17:42:30 +0000 (UTC) Received: from DB9EHSMHS001.bigfish.com (unknown [10.174.16.236]) by mail210-db9.bigfish.com (Postfix) with ESMTP id 232A1220244 for ; Thu, 11 Jul 2013 17:42:30 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by DB9EHSMHS001.bigfish.com (10.174.14.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 11 Jul 2013 17:42:29 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.145]) by BY2PRD0512HT002.namprd05.prod.outlook.com ([10.255.243.35]) with mapi id 14.16.0329.000; Thu, 11 Jul 2013 17:42:20 +0000 From: Ronald Bonica To: "ipv6@ietf.org" Subject: FW: New Version Notification for draft-bonica-6man-frag-deprecate-02.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-02.txt Thread-Index: AQHOfl0SQoCeD9DdPEOwn4CylN0odplfvcmg Date: Thu, 11 Jul 2013 17:42:20 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509FBCAE9@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:42:49 -0000 Rm9sa3MsDQoNClRoYW5rcyB0byBhbGwgb2YgeW91IGZvciB5b3VyIG1hbnkgY29tbWVudHMgb24g ZHJhZnQtYm9uaWNhLTZtYW4tZnJhZy1kZXByZWNhdGUuIEkgaGF2ZSBwb3N0ZWQgYSBuZXcgdmVy c2lvbiBhZGRyZXNzaW5nIG1hbnksIGJ1dCBub3QgYWxsIG9mIHRoZSBjb21tZW50cy4NCg0KSXQg aXMgY2xlYXIgdGhhdCB0aGlzIGRvY3VtZW50IHdvbid0IGJlIGFkb3B0ZWQgYXMgYSBXRyBpdGVt IGF0IElFVEYgODcuIEhvd2V2ZXIsIEkgdGhpbmsgdGhhdCBjb250aW51ZWQgYW5hbHlzaXMgaXMg d29ydGh3aGlsZSwgZXZlbiBpZiB0aGUgZG9jdW1lbnQgaXMgbmV2ZXIgYWRvcHRlZC4gQ3VycmVu dGx5LCB3ZSBoYXZlIGEgcHJvYmxlbSB3aXRoIGZyYWdtZW50YXRpb24uIElmIHdlIGhhc2ggdGhl IGlkZWEgYXJvdW5kIGZvciBhIHdoaWxlLCB3ZSBhcmUgbGlrZWx5IHRvIGFycml2ZSBhdCBzb21l IHNvbHV0aW9uLCBpZiBub3QgdGhlIG9uZSBwcm9wb3NlZCBieSB0aGlzIGRvY3VtZW50Lg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAx MSwgMjAxMyAxOjM1IFBNDQo+IFRvOiBIYWdlbiBQYXVsIFBmZWlmZXI7IFJvbmFsZCBCb25pY2E7 IFdhcnJlbiBLdW1hcmk7IFJhbmR5IEJ1c2gNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1ib25pY2EtNm1hbi1mcmFnLWRlcHJlY2F0ZS0NCj4gMDIudHh0DQo+ IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJvbmljYS02bWFuLWZyYWctZGVw cmVjYXRlLTAyLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJvbiBC b25pY2EgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5h bWU6CSBkcmFmdC1ib25pY2EtNm1hbi1mcmFnLWRlcHJlY2F0ZQ0KPiBSZXZpc2lvbjoJIDAyDQo+ IFRpdGxlOgkJIElQdjYgRnJhZ21lbnQgSGVhZGVyIERlcHJlY2F0ZWQNCj4gQ3JlYXRpb24gZGF0 ZToJIDIwMTMtMDctMTENCj4gR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJl ciBvZiBwYWdlczogMTENCj4gVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1ib25pY2EtNm1hbi0NCj4gZnJhZy1kZXByZWNhdGUtMDIudHh0 DQo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1ib25pY2EtNm1hbi0NCj4gZnJhZy1kZXByZWNhdGUNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib25pY2EtNm1hbi1mcmFnLQ0KPiBkZXByZWNh dGUtMDINCj4gRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1ib25pY2EtNm1hbi0NCj4gZnJhZy1kZXByZWNhdGUtMDINCj4gDQo+IEFic3RyYWN0 Og0KPiAgICBUaGlzIG1lbW8gZGVwcmVjYXRlcyBJUHY2IGZyYWdtZW50YXRpb24gYW5kIHRoZSBJ UHY2IGZyYWdtZW50DQo+IGhlYWRlci4NCj4gICAgSXQgcHJvdmlkZXMgcmVhc29ucyBmb3IgZGVw cmVjYXRpb24gYW5kIHVwZGF0ZXMgUkZDIDI0NjAuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVGhl IElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IA0KDQo= From brian.e.carpenter@gmail.com Thu Jul 11 13:31:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF22521F9AF8 for ; Thu, 11 Jul 2013 13:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.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 Aq6jdHa1wSme for ; Thu, 11 Jul 2013 13:31:12 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id AEAA821F9AC1 for ; Thu, 11 Jul 2013 13:31:12 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp12so8163988pab.7 for ; Thu, 11 Jul 2013 13:31:12 -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=3f9KcrLN2nbf6I1BouR74PguewG9RONAgWazmG6T/4E=; b=t1iO5pwDwTU/I9bxSoI0in3zx+7eZ+p7z2QmAuTwfvjj7/liSLXHMvA8UYYZXoBQUU 8+tZF4/vqTlOmH92Lk0dtDa5qv/0y1DCUFvB1Isgo5tnMni8DSkaFJzd3F8je/THF5Ij 4kDU8/rN5ZOmJ/E9JcAR9QXkPmxZqbkxwW/lri8tvXc4h/S393AIJocvgf9Cj7cqhjEJ AR7lKDamANmEI16NkrhMEfDrC34JUW0uiNzonwt0V2V4Orr/bscJCAWBeuIsi84vSF0E 5GiwcQhe1CVodDeYnxJKAQVLTj1q73hwoFTP1UsfQz/ZCOkCx+4G//eVtQl3ztjKgH3u 2ZiA== X-Received: by 10.66.253.100 with SMTP id zz4mr31027107pac.48.1373574672432; Thu, 11 Jul 2013 13:31:12 -0700 (PDT) Received: from [192.168.178.23] (124.199.69.111.dynamic.snap.net.nz. [111.69.199.124]) by mx.google.com with ESMTPSA id 4sm41348975pbw.32.2013.07.11.13.31.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 13:31:11 -0700 (PDT) Message-ID: <51DF1616.5090304@gmail.com> Date: Fri, 12 Jul 2013 08:31:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-02.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509FBCAE9@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509FBCAE9@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:31:14 -0000 As Ron says, there are open issues and I agree that they need to be understood. Also, I think people need to accept that the word "deprecate" is a very useful one. In a sense it means the same thing as SHOULD NOT or NOT RECOMMENDED - don't do this unless you have a very good reason, and be aware of the consequences. Since the consequences in this case can be complete failure to communicate, this is not an issue the IETF can duck. Personally I'm all for the WG adopting the draft sooner rather than later, even though it needs work. Regards Brian On 12/07/2013 05:42, Ronald Bonica wrote: > Folks, > > Thanks to all of you for your many comments on draft-bonica-6man-frag-deprecate. I have posted a new version addressing many, but not all of the comments. > > It is clear that this document won't be adopted as a WG item at IETF 87. However, I think that continued analysis is worthwhile, even if the document is never adopted. Currently, we have a problem with fragmentation. If we hash the idea around for a while, we are likely to arrive at some solution, if not the one proposed by this document. > > Ron > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, July 11, 2013 1:35 PM >> To: Hagen Paul Pfeifer; Ronald Bonica; Warren Kumari; Randy Bush >> Subject: New Version Notification for draft-bonica-6man-frag-deprecate- >> 02.txt >> >> >> A new version of I-D, draft-bonica-6man-frag-deprecate-02.txt >> has been successfully submitted by Ron Bonica and posted to the IETF >> repository. >> >> Filename: draft-bonica-6man-frag-deprecate >> Revision: 02 >> Title: IPv6 Fragment Header Deprecated >> Creation date: 2013-07-11 >> Group: Individual Submission >> Number of pages: 11 >> URL: http://www.ietf.org/internet-drafts/draft-bonica-6man- >> frag-deprecate-02.txt >> Status: http://datatracker.ietf.org/doc/draft-bonica-6man- >> frag-deprecate >> Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag- >> deprecate-02 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-bonica-6man- >> frag-deprecate-02 >> >> Abstract: >> This memo deprecates IPv6 fragmentation and the IPv6 fragment >> header. >> It provides reasons for deprecation and updates RFC 2460. >> >> >> >> >> >> The IETF Secretariat >> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Thu Jul 11 13:35:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F073B11E8138 for ; Thu, 11 Jul 2013 13:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 Trmq5KMHizd9 for ; Thu, 11 Jul 2013 13:35:03 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5021F9B26 for ; Thu, 11 Jul 2013 13:35:03 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so8241343pbb.5 for ; Thu, 11 Jul 2013 13:34:56 -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=obfbiAKuKA32AdOQw7VkwOg1qdWJmwcq5hzOgAbtaQU=; b=H7hiRgaihehtgjX2nfOg/WDCuXbjzMiQHb96HXhD+axSTcm78192Rhr2QgSIIjHjhz 2eUqVexIcyN3M5Yd9jpaFYpjUHeBBTivd+2I0U1M24YlxEMDkYkOklapj1sI/3w4fNC1 5ybhRgwm4HdwZK9rhTWD3ghTTtJNzCJwGBIDh+iIQGJ5K1GpyjfliwQhgKFtI1MCz8wQ ZMuD5G40SieZG2jqKAakINgl37d7fkFvQgcbl952QJgAYpHbxkJRtLgPloqzWQB2GZBk l/SbzwQaTSFfj5r4dtInBo5jTE56rbOjbmfGLX7Orxc7yfJf4uMjNsyWJA9UJiT/7eX2 QYZg== X-Received: by 10.68.106.67 with SMTP id gs3mr38559275pbb.126.1373574896169; Thu, 11 Jul 2013 13:34:56 -0700 (PDT) Received: from [192.168.178.23] (124.199.69.111.dynamic.snap.net.nz. [111.69.199.124]) by mx.google.com with ESMTPSA id i16sm43908513pag.18.2013.07.11.13.34.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 13:34:55 -0700 (PDT) Message-ID: <51DF16F1.6040202@gmail.com> Date: Fri, 12 Jul 2013 08:34:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Meta-issues: On the deprecation of the fragmentation function References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBBF5E@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B8722@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBC675@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180BA667@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180BA667@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:35:04 -0000 On 12/07/2013 04:41, Templin, Fred L wrote: > Hi Ron, > >> -----Original Message----- >> From: Ronald Bonica [mailto:rbonica@juniper.net] >> Sent: Thursday, July 11, 2013 6:50 AM >> To: Templin, Fred L; james woodyatt; ipv6@ietf.org >> Subject: RE: Meta-issues: On the deprecation of the fragmentation >> function >> >> Yes, I am talking about IPv6 fragmentation. > > OK, but if you want to deprecate that you need to replace it > with something else like SEAL. If you mean that 1280 must be provided everywhere regardless of nested tunnels, yes. (Setting aside the NAT64 mess.) Brian From rdroms@cisco.com Mon Jul 15 03:55:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C951B11E80D9 for ; Mon, 15 Jul 2013 03:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRNb58tzKGww for ; Mon, 15 Jul 2013 03:55:42 -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 41A4311E80E1 for ; Mon, 15 Jul 2013 03:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1587; q=dns/txt; s=iport; t=1373885742; x=1375095342; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1qcE67AOgFiuFGQaDkPf/cqALWkAhViXMZ52Ek/7O0U=; b=PnReeMeJWHByPh9T1OMqaQaTCsvwzrS+1g4ByNcrq83ybnWuRyd6mWP1 +CvqijKT/jf5Tu53SFdhhjv6zVCNNSwZKFQemDivqTYjbE56e9j5tV2JN TdgFea3aqbHNeor+IIHPg8XOWFyri0ijOVxJMBCrhf7h9bvPGfB7zmPAA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFANDU41GtJV2c/2dsb2JhbABagwY0T8FQgQ8WdIIjAQEBAwEBAQE3NBsCAQgiFBAnCyUCBBMIiAIGDLUnjzECOIMLbQOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,668,1367971200"; d="scan'208";a="234897892" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 15 Jul 2013 10:55:42 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6FAtfgk009101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Jul 2013 10:55:41 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.239]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 05:55:41 -0500 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Topic: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOfnvAE0hdpuPffU2KL5nISCt1Apll6o6A Date: Mon, 15 Jul 2013 10:55:40 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> In-Reply-To: <23575.1373577247@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <27BACBF94F43E74E83CD46EC13AF5FA5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 Jul 2013 05:09:09 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 10:55:46 -0000 (BCC: 6man mailing list, which is where this document is intended to become= a work item) On Jul 11, 2013, at 10:14 PM 7/11/13, Michael Richardson wrote: >=20 >> The most recent rev of draft-droms-6man-multicast-scopes defines scope >> 0x03 as: >=20 >> 3 Network-Specific scope, greater than Link-Local scope, defined >> automatically from the network topology >=20 >> To be confirmed: will this definition suffice for MPL? >=20 > I think it is sufficient, because we understand what it means. > I am concerned about the word "Network"... which could mean anything to a= nyone. >=20 > I'd think that the right word would be "subnet", because the intent is th= at > it is for the entire /64 or whatever it is that one is using. I think th= at > is the term that is used in RFC4291. "subnet" implies that this multicast scope must derive from the address ass= ignment topology. The first (and only) use case is derived from the /64 pr= efix; do we want to have that limitation for all uses of scope 0x03? - Ralph >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From bob.hinden@gmail.com Mon Jul 15 13:10:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6E821E811F for ; Mon, 15 Jul 2013 13:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 DBsIw5TU7o3o for ; Mon, 15 Jul 2013 13:10:23 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2914D21E816B for ; Mon, 15 Jul 2013 13:10:10 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id f6so6594971qej.23 for ; Mon, 15 Jul 2013 13:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SOK4g5ibbNY3hx+1uumQouDyDakbZoCtm3Y4UD9Ttjg=; b=kwJ62bkWav6rHXY6GJ4JviPxMxt/2MiNKSOR38UlrNQk0/pFTI+6ObyQ0/hKDNT6wH 4Fo5788lX2jbdGf0lWNs4RhtJZY6lbCFh3vPrKGAC20rvenMD/9OrL8nLU+o/HKD725C 8Ns5WzHG9Bp22JZt01BRaJhyi4mp9weDW53vb4ERjgdu/mDCTfXb9iI62qGIhEgA0JfM Gg0fpZdtvN/lgdT5u/Wcv3nC4Ab2WxDb27Yf4X/tyZAZoc0Jv40phNP3edABzIEps33Y 428HKuBPjMLIJRZkR2iK5yJJyv8/Ime8e4kV1eqjPSiEwxzOMJw6Ef1IBSyWzb6BYFXc mLCg== X-Received: by 10.224.25.140 with SMTP id z12mr2103001qab.46.1373919009619; Mon, 15 Jul 2013 13:10:09 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id r2sm57436225qeh.7.2013.07.15.13.10.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 13:10:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Fwd: Internet Draft Submission Cut-Off Today From: Bob Hinden Date: Mon, 15 Jul 2013 13:10:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130715170923.16712.32343.idtracker@ietfa.amsl.com> To: IPv6 List X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:10:23 -0000 FYI Begin forwarded message: > From: IETF Secretariat > Subject: Internet Draft Submission Cut-Off Today > Date: July 15, 2013 10:09:23 AM PDT > To: IETF Announcement List > Cc: ietf@ietf.org >=20 > This is a reminder that the Internet Draft Submission cut-off is = today, Monday, July 15, 2013.=20 >=20 > All submissions are due by UTC 24:00. >=20 > All drafts can be uploaded using the ID submission tool located here: > https://datatracker.ietf.org/submit/ >=20 > The Internet-Draft cutoff dates as well as other significant dates for = IETF 87 can be found at:=20 > https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87 >=20 > Thank you for your understanding and cooperation. If you have any = questions or concerns, then please send a message to = internet-drafts@ietf.org. From internet-drafts@ietf.org Mon Jul 15 14:07:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C740821E80C9; Mon, 15 Jul 2013 14:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY+NvaqU2y-4; Mon, 15 Jul 2013 14:07:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDAD11E819A; Mon, 15 Jul 2013 14:07:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-oversized-header-chain-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715210730.19211.14492.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:07:30 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:07:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Implications of Oversized IPv6 Header Chains Author(s) : Fernando Gont Vishwas Manral Ronald P. Bonica Filename : draft-ietf-6man-oversized-header-chain-03.txt Pages : 12 Date : 2013-07-15 Abstract: The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-oversized-header-chain-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Fred.L.Templin@boeing.com Mon Jul 15 14:40:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F5921E80C8 for ; Mon, 15 Jul 2013 14:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 8aFqTzY0d39S for ; Mon, 15 Jul 2013 14:40:38 -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 30E4A21E80BD for ; Mon, 15 Jul 2013 14:40:34 -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 r6FLeXXc014225 for ; Mon, 15 Jul 2013 16:40:33 -0500 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6FLeVKq013729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 15 Jul 2013 16:40:32 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.234]) with mapi id 14.02.0328.011; Mon, 15 Jul 2013 14:40:31 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: FW: I-D Action: draft-generic-6man-tunfrag-09.txt Thread-Topic: I-D Action: draft-generic-6man-tunfrag-09.txt Thread-Index: AQHOgZrq9mIcG8iIOkiChC7BKxIW6JlmRCMg Date: Mon, 15 Jul 2013 21:40:30 +0000 Message-ID: <2134F8430051B64F815C691A62D983180CA8C9@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:40:44 -0000 FYI, below is a minor update of the "Fragmentation Revisited" draft. Bob and Ole - can we have this as a 6man working group item? Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, July 15, 2013 1:36 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-generic-6man-tunfrag-09.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Fragmentation Revisited Author(s) : Fred L. Templin Filename : draft-generic-6man-tunfrag-09.txt Pages : 8 Date : 2013-07-15 Abstract: IP fragmentation has long been subject for scrutiny since the publication of "Fragmentation Considered Harmful" in 1987. This work cast fragmentation in a negative light that has persisted to the present day. However, the tone of the work failed to honor two principles of creative thinking: never say "always" and never say "never". This document discusses uses for fragmentation that apply both to the present day and moving forward into the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag There's also a htmlized version available at: http://tools.ietf.org/html/draft-generic-6man-tunfrag-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-generic-6man-tunfrag-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From acooper@cdt.org Mon Jul 15 15:26:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC34D21F9CA8 for ; Mon, 15 Jul 2013 15:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 USRcjLvTI8L4 for ; Mon, 15 Jul 2013 15:26:47 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6566021E818F for ; Mon, 15 Jul 2013 15:26:34 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ipv6@ietf.org; Mon, 15 Jul 2013 18:26:32 -0400 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: New Version Notification for draft-cooper-6man-ipv6-address-generation-privacy-00.txt Date: Mon, 15 Jul 2013 18:26:32 -0400 References: <20130715222021.14616.94640.idtracker@ietfa.amsl.com> To: ipv6@ietf.org Message-Id: <7160AAF0-F4A0-4B22-A278-19E0454220D8@cdt.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:26:56 -0000 FYI Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-cooper-6man-ipv6-address-generation-privacy-00.txt > Date: July 15, 2013 6:20:21 PM EDT > To: Fernando Gont , Alissa Cooper = , Dave Thaler >=20 >=20 > A new version of I-D, = draft-cooper-6man-ipv6-address-generation-privacy-00.txt > has been successfully submitted by Alissa Cooper and posted to the > IETF repository. >=20 > Filename: draft-cooper-6man-ipv6-address-generation-privacy > Revision: 00 > Title: Privacy Considerations for IPv6 Address = Generation Mechanisms > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 15 > URL: = http://www.ietf.org/internet-drafts/draft-cooper-6man-ipv6-address-generat= ion-privacy-00.txt > Status: = http://datatracker.ietf.org/doc/draft-cooper-6man-ipv6-address-generation-= privacy > Htmlized: = http://tools.ietf.org/html/draft-cooper-6man-ipv6-address-generation-priva= cy-00 >=20 >=20 > Abstract: > This document discusses privacy and security considerations for > several IPv6 address generation mechanisms, both standardized and > non-standardized. It evaluates how different mechanisms mitigate > different threats and the trade-offs that implementors, developers, > and users face in choosing different addresses or address generation > mechanisms. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 From Fred.L.Templin@boeing.com Mon Jul 15 15:51:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E029811E815E for ; Mon, 15 Jul 2013 15:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 L8MRoQkxs+hO for ; Mon, 15 Jul 2013 15:51:06 -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 2436F11E81D5 for ; Mon, 15 Jul 2013 15:51:05 -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 r6FMpkjF024756 for ; Mon, 15 Jul 2013 15:51:46 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6FMpkHw024753 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 15 Jul 2013 15:51:46 -0700 Received: from XCH-BLV-106.nw.nos.boeing.com (130.247.25.122) by XCH-NWHT-05.nw.nos.boeing.com (130.247.25.109) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 15 Jul 2013 15:51:04 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-106.nw.nos.boeing.com ([169.254.6.180]) with mapi id 14.02.0328.011; Mon, 15 Jul 2013 15:51:03 -0700 From: "Templin, Fred L" To: Ronald Bonica , "ipv6@ietf.org" Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-02.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-02.txt Thread-Index: AQHOfl0SQoCeD9DdPEOwn4CylN0odplfvcmggAagRPA= Date: Mon, 15 Jul 2013 22:51:03 +0000 Message-ID: <2134F8430051B64F815C691A62D983180CAB15@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509FBCAE9@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509FBCAE9@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:51:14 -0000 Hi Ron, I notice that Section 3.5 of the document currently reads: "3.5 Tunneling - TBD" You are welcome to cite the "Fragmentation Revisited" draft in that section rather than leave it as blank. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Thursday, July 11, 2013 10:42 AM > To: ipv6@ietf.org > Subject: FW: New Version Notification for draft-bonica-6man-frag- > deprecate-02.txt >=20 > Folks, >=20 > Thanks to all of you for your many comments on draft-bonica-6man-frag- > deprecate. I have posted a new version addressing many, but not all of > the comments. >=20 > It is clear that this document won't be adopted as a WG item at IETF > 87. However, I think that continued analysis is worthwhile, even if the > document is never adopted. Currently, we have a problem with > fragmentation. If we hash the idea around for a while, we are likely to > arrive at some solution, if not the one proposed by this document. >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, July 11, 2013 1:35 PM > > To: Hagen Paul Pfeifer; Ronald Bonica; Warren Kumari; Randy Bush > > Subject: New Version Notification for draft-bonica-6man-frag- > deprecate- > > 02.txt > > > > > > A new version of I-D, draft-bonica-6man-frag-deprecate-02.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Filename: draft-bonica-6man-frag-deprecate > > Revision: 02 > > Title: IPv6 Fragment Header Deprecated > > Creation date: 2013-07-11 > > Group: Individual Submission > > Number of pages: 11 > > URL: http://www.ietf.org/internet-drafts/draft-bonica- > 6man- > > frag-deprecate-02.txt > > Status: http://datatracker.ietf.org/doc/draft-bonica-6man- > > frag-deprecate > > Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag- > > deprecate-02 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bonica-6man- > > frag-deprecate-02 > > > > Abstract: > > This memo deprecates IPv6 fragmentation and the IPv6 fragment > > header. > > It provides reasons for deprecation and updates RFC 2460. > > > > > > > > > > > > The IETF Secretariat > > > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Mon Jul 15 16:08:27 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AD011E8275; Mon, 15 Jul 2013 16:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 4OQi05o7Tc2X; Mon, 15 Jul 2013 16:08:22 -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 6396911E8258; Mon, 15 Jul 2013 16:08:14 -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 r6FN87Lc027095; Mon, 15 Jul 2013 16:08:07 -0700 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6FN87Gh027092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Jul 2013 16:08:07 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.168]) with mapi id 14.02.0328.011; Mon, 15 Jul 2013 16:08:07 -0700 From: "Templin, Fred L" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: RE: I-D Action: draft-ietf-6man-oversized-header-chain-03.txt Thread-Topic: I-D Action: draft-ietf-6man-oversized-header-chain-03.txt Thread-Index: AQHOgZ98Bws/w54D3kC1yb95YCdnj5lmW/Bw Date: Mon, 15 Jul 2013 23:08:07 +0000 Message-ID: <2134F8430051B64F815C691A62D983180CAB8A@XCH-BLV-504.nw.nos.boeing.com> References: <20130715210730.19211.14492.idtracker@ietfa.amsl.com> In-Reply-To: <20130715210730.19211.14492.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:08:27 -0000 Hi, if you are concerned about a chain of extension headers not fitting within the first fragment you might want to take a look at SEAL where it is physically impossible to create fragments smaller than 256 bytes. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, July 15, 2013 2:08 PM > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-oversized-header-chain-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance Working Group of the > IETF. >=20 > Title : Implications of Oversized IPv6 Header Chains > Author(s) : Fernando Gont > Vishwas Manral > Ronald P. Bonica > Filename : draft-ietf-6man-oversized-header-chain-03.txt > Pages : 12 > Date : 2013-07-15 >=20 > Abstract: > The IPv6 specification allows IPv6 header chains of an arbitrary > size. The specification also allows options which can in turn > extend > each of the headers. In those scenarios in which the IPv6 header > chain or options are unusually long and packets are fragmented, or > scenarios in which the fragment size is very small, the first > fragment of a packet may fail to include the entire IPv6 header > chain. This document discusses the interoperability and security > problems of such traffic, and updates RFC 2460 such that the first > fragment of a packet is required to contain the entire IPv6 header > chain. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-oversized-header- > chain-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ietf@rozanak.com Mon Jul 15 16:57:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19A421E81B9; Mon, 15 Jul 2013 16:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC4eMs0DownJ; Mon, 15 Jul 2013 16:57:42 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D01F421E811C; Mon, 15 Jul 2013 16:57:41 -0700 (PDT) Received: from kopoli (g225042008.adsl.alicedsl.de [92.225.42.8]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MexqT-1UoEa81PjN-00OUou; Mon, 15 Jul 2013 19:57:40 -0400 From: "Hosnieh Rafiee" To: Subject: I-D action draft-rafiee-6man-ssas Date: Tue, 16 Jul 2013 01:57:35 +0200 Message-ID: <015501ce81b7$16cb3ee0$4461bca0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6BtlsrAy4FK2Y/Rq2lGeggdXEzYw== Content-Language: en-us X-Provags-ID: V02:K0:sgBCG/8tEPscanhdHMcqiGN/DQOvkeabSRiy8YKxw2s 2uplTEzNXxrdxRYQtI3YPjCdNAIUGFiaajiAWnui8zSfyAkHfe RGFxtKFnW9VxX6gZ86I4Z/IR1y6908snoaF6sO3oalmLBNJYqO 7DcVJ1UpLGxW1PIryKI7NHurQSN7Jeq5R3hvUqxlMoplYPZfGu qeEApQijrNQot9rwjjqk8ymH9yqONcEm1/ZbjHPbTqzEo6zsRk bPKGdDbk5jy/HRcl4FSk+M51sLSnteKwS6lrevLysAiRK17M+N PMVQSWWdf1kCXyaRNTSf/01+Xa5Wnn1TN8faffV0KTzYYi4pD4 MAWbyqWQ/1F76ROWkmwI= Cc: saag@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:57:47 -0000 New version of SSAS is available online.=20 - Changes to RPKI introduced in last version - Introduce new algorithm along with the improvement to the previous = algorithm (to improve the security and usability of IID generation) Any comments? :-) Thanks, Hosnieh Filename: draft-rafiee-6man-ssas Revision: 05 Title: A Simple Secure Addressing Scheme for IPv6 AutoConfiguration = (SSAS) Creation date: 2013-07-15 Group: Individual Submission Number of pages: 19 URL: = http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-05.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-05 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-rafiee-6man-ssas-05 Abstract: The default method for IPv6 address generation uses an Organizationally Unique Identifier (OUI) assigned by the IEEE Standards Association and an Extension Identifier assigned to the hardware manufacturer [1] (section 2.5.1 RFC-4291) [RFC4291]. This fact thus means that a node will always have the same Interface ID (IID) whenever it connects to a new network. Because the node's IP address does not change, the node will be vulnerable to privacy related attacks. Currently this problem is addressed by the use of two mechanisms that do not make use of the MAC address, or other unique values that can be used for ID generation, for randomizing the IID; Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy Extension [RFC4941]. The problem with the former approach is the computational cost involved for the IID generation and in the verification process. The problem with the latter approach is that it lacks necessary security mechanisms and provides the node with only partial protection against privacy related attacks. This document proposes the use of a new algorithm for use in the generation of the IID while, at the same time, securing the node against some types of attack, like IP spoofing. These attacks are prevented by the addition of a signature to messages sent over the network and by finding a binding with the nodes' IP address and its public key. The use of theResource Public Key Infrastructure (RPKI), introduced in this document, is based on the centralized version explained in RFC 6494 and RFC 6495. = =20 The IETF Secretariat From samita.chakrabarti@ericsson.com Mon Jul 15 19:16:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5103F11E818E; Mon, 15 Jul 2013 19:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H48Jd8ymFX-9; Mon, 15 Jul 2013 19:15:53 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5186811E817B; Mon, 15 Jul 2013 19:15:53 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-f9-51e4acd7fbeb Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1D.92.13034.7DCA4E15; Tue, 16 Jul 2013 04:15:52 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Mon, 15 Jul 2013 22:15:51 -0400 From: Samita Chakrabarti To: "6man@ietf.org" <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Thread-Topic: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Thread-Index: Ac6BxnHoPpTQzrivR8KlRMSgd1HBBw== Date: Tue, 16 Jul 2013 02:15:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01BF0D3E7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiO6NNU8CDRrOKVg0TxGwWLniLpPF 1vf72CyOTLnLatE/dSeTxeS2FWwWM6a8Y3Rg97h8xdtjyu+NrB4Hj31k9Ng56y67x5IlP5k8 pi3KDGCL4rJJSc3JLEst0rdL4MrY37qCuaAxu2Lh7v8sDYyn4roYOTkkBEwkbhx/zgphi0lc uLeerYuRi0NI4CijxNn3t5khnOWMEk3/N7OAVLEJWEl09O5hB7FFBJwk5l9/yg5SxCwwiUni +6+DTCAJYaDEoxU/mCCK3CUWvJ/JBmHrSTQ+OckIYrMIqEpsb9wJtppXwFfi5/InYDYj0Bnf T60B62UWEJe49WQ+E8R5AhJL9pxnhrBFJV4+/gd1trLEkif7WSDq8yUOfD7JDjFTUOLkzCcs ExiFZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqRwSZG YPQdk2DT3cG456XlIUZpDhYlcd5VemcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTB6fFpY /SvogOEcgwmvtggdL5S0MfO9eST406LL3zMtGMIC7+34KeTHvYaNrb/64JuGCRmuGhNCp7sU 3OC3Z+yxb86WWe3ooLX4s9r9ajc7hh/3+yOX/wycH2a46sb8MtWQa41eQfsUpeIMJnSbLVm7 68/ZvuCCwtA+pcd/3Vec2niVu36m9zwlluKMREMt5qLiRACye52sjAIAAA== Cc: "Erik Nordmark \(nordmark@acm.org\)" , "pthubert@cisco.com" , "Bob Hinden \(bob.hinden@gmail.com\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 02:16:09 -0000 --_000_ECA43DA70480A3498E43C3471FB2E1F01BF0D3E7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All: We submitted a revision of efficient-nd (02) version to incorporate the co= mments after last IETF . * Added a new field for Transaction ID in the Address registration = message * Updated the local mobility and NCE handling sections to address t= he effect of TID field in multi-router/transit link scenario * Added more text for ND-Proxy behavior * Added implications for RPL * Separated the use cases in the Appendix Some more editorial work will be performed in the next revision in addition= to any technical changes. Thanks, -Samita, Erik and Pascal Filename: draft-chakrabarti-nordmark-6man-efficient-nd Revision: 02 Title: Efficiency aware IPv6 Neighbor Discovery Optimi= zations Creation date: 2013-07-15 Group: Individual Submission Number of pages: 31 URL: http://www.ietf.org/internet-drafts/draft-chakrabarti-nord= mark-6man-efficient-nd-02.txt Status: http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark= -6man-efficient-nd Htmlized: http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man= -efficient-nd-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-chakrabarti-nordm= ark-6man-efficient-nd-02 Abstract: IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for neighbor's address resolution, unreachability detection, address autoconfiguration, router advertisement and solicitation. With the progress of Internet adoption on various industries including home, wireless, M2M and cellular networks there is a desire for optimizing the legacy IPv6 Neighbor Discovery protocol. This document describes a method of optimization by reducing multicast messages and introducing an IPv6 address Registration mechanism. Efficient IPv6 Neighbor Discovery protocol is useful for energy-efficient and low- power IPv6 networks and as well as Data Center and Home Networks. The solution is capable of handling existing legacy IPv6 nodes in the network with local mobility. --_000_ECA43DA70480A3498E43C3471FB2E1F01BF0D3E7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

 

Hello All:

 

We submitted a revision of efficient-nd (02) version=   to incorporate the comments  after last IETF .

·         Added a new field for Transaction ID in the = Address registration message

·         Updated the local mobility and NCE handling = sections to address the effect of TID field in multi-router/transit link sc= enario

·         Added more text for ND-Proxy behavior <= /o:p>

·         Added implications for RPL

·         Separated the use cases in the Appendix=

 

Some more edito= rial work will be performed in the next revision in addition to any technic= al changes.

 

Thanks,

-Samita, Erik a= nd Pascal

 

 

Filename:       &= nbsp;    draft-chakrabarti-nordmark-6man-efficient-nd

Revision:       &= nbsp;      02

Title:       &nbs= p;            &= nbsp; Efficiency aware IPv6 Neighbor Discovery Optimizations

Creation date:   2013-07-15

Group:       &nbs= p;          Individual Submiss= ion

Number of pages: 31

URL:        =      http://www.ietf.org/internet-drafts/draft-chakrabarti-nordmark-6man-efficie= nt-nd-02.txt

Status:       &nb= sp;  http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-n= d

Htmlized:        = http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-02<= /a>

Diff:        = ;    http://www.ietf.org/rfcdiff?url2=3Ddraft-chakrabarti-nordmark-6man-efficien= t-nd-02

 

Abstract:

   IPv6 Neighbor Discovery (RFC 4861) prot= ocol has been designed for

   neighbor's address resolution, unreacha= bility detection, address

   autoconfiguration, router advertisement= and solicitation.  With the

   progress of Internet adoption on variou= s industries including home,

   wireless, M2M and cellular networks the= re is a desire for optimizing

   the legacy IPv6 Neighbor Discovery prot= ocol.  This document describes

   a method of optimization by reducing mu= lticast messages and

   introducing an IPv6 address Registratio= n mechanism.  Efficient IPv6

   Neighbor Discovery protocol is useful f= or energy-efficient and low-

   power IPv6 networks and as well as Data= Center and Home Networks.

   The solution is capable of handling exi= sting legacy IPv6 nodes in the

   network with local mobility.=

 

 

--_000_ECA43DA70480A3498E43C3471FB2E1F01BF0D3E7eusaamb103erics_-- From fgont@si6networks.com Tue Jul 16 06:08:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA6311E810E; Tue, 16 Jul 2013 06:08: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 vQb5CatGxbwc; Tue, 16 Jul 2013 06:08:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 77DF611E8107; Tue, 16 Jul 2013 06:08:03 -0700 (PDT) Received: from 79.109.50.53.dyn.user.ono.com ([79.109.50.53] helo=[192.168.1.32]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uz4z4-0006V5-On; Tue, 16 Jul 2013 15:08:02 +0200 Message-ID: <51E545AE.9040204@si6networks.com> Date: Tue, 16 Jul 2013 15:07:58 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: internet-drafts@ietf.org Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-03.txt References: <20130715210730.19211.14492.idtracker@ietfa.amsl.com> In-Reply-To: <20130715210730.19211.14492.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, i-d-announce@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:08:04 -0000 Folks, FWIW, this version is meant to address the feedback we had received so far. Namely, clarifying what we mean by "entire ipv6 header chain2 in the presence of ESP and a clarification of the motivations for this I-D. My take is that this latest rev is ready to ship. Thanks, Fernando On 07/15/2013 11:07 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : Implications of Oversized IPv6 Header Chains > Author(s) : Fernando Gont > Vishwas Manral > Ronald P. Bonica > Filename : draft-ietf-6man-oversized-header-chain-03.txt > Pages : 12 > Date : 2013-07-15 > > Abstract: > The IPv6 specification allows IPv6 header chains of an arbitrary > size. The specification also allows options which can in turn extend > each of the headers. In those scenarios in which the IPv6 header > chain or options are unusually long and packets are fragmented, or > scenarios in which the fragment size is very small, the first > fragment of a packet may fail to include the entire IPv6 header > chain. This document discusses the interoperability and security > problems of such traffic, and updates RFC 2460 such that the first > fragment of a packet is required to contain the entire IPv6 header > chain. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-oversized-header-chain-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From mcr@sandelman.ca Wed Jul 17 11:34:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F6021F9A1C; Wed, 17 Jul 2013 11:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RgAB9d6YFud; Wed, 17 Jul 2013 11:34:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 9AED921F99C3; Wed, 17 Jul 2013 11:34:33 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 685012017C; Wed, 17 Jul 2013 15:39:31 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AD2AC63A7C; Wed, 17 Jul 2013 14:32:56 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 996CB63732; Wed, 17 Jul 2013 14:32:56 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks , ipv6@ietf.org Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:34:44 -0000 --=-=-= Ralph Droms wrote: > This draft is on the 6man agenda for Berlin. I expect the discussion > will be taken up there. > In my opinion, the multicast scope should not be tied, thought the > words in the description of the scope, to the address assignment > architecture. Do you have a specific use case that you are thinking of? How can it be tied to the subnet, and yet not be related to the address assignment architecture? Can you suggest another definition? -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUebjVYqHRg3pndX9AQIgdwQAxptNIsfjPm3iKNiuwiGadPVrhzDsDS7a 1kHQLxIpsk3tjl9aQ5b965AuceXeZtrQqV5y42TtFWp3TWu18dWwMMWEfkwE75ir s2YmL2WQSLQ6QE1/lZZ3YexVnGDnON4kRtgXpnbG/nQNeBJc384gIx54Z4xh1rgM sx+JBLPNRBE= =jUDQ -----END PGP SIGNATURE----- --=-=-=-- From bob.hinden@gmail.com Wed Jul 17 18:09:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650FC21F9808 for ; Wed, 17 Jul 2013 18:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CaHVi3bhX7D for ; Wed, 17 Jul 2013 18:09:50 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 287AF21F991F for ; Wed, 17 Jul 2013 18:09:50 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so1443889qab.7 for ; Wed, 17 Jul 2013 18:09:49 -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 :cc:to:mime-version:x-mailer; bh=wdf3RK4jc8ldE9C7x1j1auLhTDItVsH9hMtNiImklt8=; b=0UkfGht7izlnIRwvP22eyDKK6txLPs39ZkE44whBTTx3Xo/W1KUTEhUlbVeTqGkZmU a1xZjQO25EVk05q98LcFquWqYHDIbEuSp0cATG6O/lroq3Q5acUQgqZxw0dpiY5Ol/4D yjwpZ58GqQmlLNMmD0GgxbCxHU+xEJJol9Fr3J5AwaEq+xHK74WB3A/rvY/pzzPcZ9pN JJhS0u78HUjDFlLSw58LDv7KffaU9nBdZD9egjc6t9hXC2A7qBNctia71vA5OHoeLWgL SWx2JJi6vc7CYe406adTVITrgMwqVwhppuEIyLFMmNC9ug1o6no6f8/S/GLIJYUyw1Bc JV0w== X-Received: by 10.224.124.66 with SMTP id t2mr11461363qar.108.1374109789680; Wed, 17 Jul 2013 18:09:49 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id s8sm13771301qag.8.2013.07.17.18.09.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 18:09:48 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Draft Agenda for 6MAN for IETF87 Date: Wed, 17 Jul 2013 18:09:45 -0700 Message-Id: <65A879E7-8713-4D7C-A16A-17F307EE9977@gmail.com> To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 01:09:51 -0000 The draft agenda for 6MAN is available at: http://www.ietf.org/proceedings/87/agenda/agenda-87-6man We were able to accommodate most requests, but two were included in the = "If time permits section", and one rejected. There may be some changes = in times or ordering between now and the 6MAN session. Please send us corrections. Presenters should send your slides to the chairs no later than Noon on = Sunday July 28. The session will be covered by Meetecho and the slides = must be uploaded in advance of the session. We need a jabber scribe and minute taker. Please volunteer. See you all in Berlin Thanks, Bob & Ole= From bob.hinden@gmail.com Thu Jul 18 15:11:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D392621E808C for ; Thu, 18 Jul 2013 15:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4GNZcv9KtHz for ; Thu, 18 Jul 2013 15:11:06 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD8721F9E94 for ; Thu, 18 Jul 2013 15:11:06 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so2003255qcx.12 for ; Thu, 18 Jul 2013 15:11:03 -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 :cc:to:mime-version:x-mailer; bh=Rya2GSVQutgW1sSw5PWqKuyPIDTu34NX9gnD8OPVmMM=; b=XIY6K1hhexWhzq4b+h55/YkcyA7v7huXznHG1jMWALjEmPOO1rmNB5C5ciLBjVT5Vs hkTwI2syjTknnRjOVp0aXskFdsJOJ9/1H7HtRVlq7r0M+UEb85rnqeXWVoQ7DnwEyVK3 wYjhP8IARZ8p6AIibLa5Qi0VePmNFuJxp7tWH5AaHaAqs5JdkntKpqa7/uur5tkuxOR6 5waNCCe8uQ9PSK8l5MJBZlQb7nIM67fTyxyfLyLSQYru+qJqnAqNf1a8MNC4UjR0fOOT NU9D3momTzvKxYKfoqggRsdvLr/WiN7M90YJZch+Wp8AVRcyiqef0aB0K97E1LjE2Qss csWQ== X-Received: by 10.224.28.197 with SMTP id n5mr16037594qac.64.1374185463524; Thu, 18 Jul 2013 15:11:03 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id m2sm19300216qat.2.2013.07.18.15.11.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 15:11:02 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Thu, 18 Jul 2013 15:11:00 -0700 Message-Id: To: IPv6 IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 22:11:07 -0000 All, This message starts a two week 6MAN Working Group on advancing: Title : Significance of IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ug-01.txt Pages : 11 Date : 2013-05-24 http://tools.ietf.org/html/draft-ietf-6man-ug-01 as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the author. This last call will = end on 1 August 2013. The chairs would also like to solicit a few people to do a detailed = review of this document. Please contact the chairs directly. Regards, Bob Hinden & Ole Tr=F8an From bob.hinden@gmail.com Thu Jul 18 15:14:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D65D21E8110 for ; Thu, 18 Jul 2013 15:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UguQgPPhlIOc for ; Thu, 18 Jul 2013 15:14:24 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9C11921E8109 for ; Thu, 18 Jul 2013 15:14:24 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so2103559qeb.15 for ; Thu, 18 Jul 2013 15:14:24 -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 :cc:to:mime-version:x-mailer; bh=J6/xCSFTr7lS5SqDCiIsEW3uZ9L4BE8QuXUyTAos16I=; b=skVspnQGeSSh96dWM8nkrhaNL5TjKIIHkuQwgMTGkGQQCGslr+s70mEG55MZiYCFMD 1HIdryNRMEhbrwWXu2DKFUuRBp4F/a/rJ8SdfyR/nov1qQkYSCkhw8l0z8GKExsX/1vZ r/16ws4bvn3RupDZnK+bklyZM4NXMfkxFceXa3Ed8S5hB7mWMgL+YGF5FflWNGzThNGP wLx6bC5Pm1dS8Qw45IBIfVurC4I77HkXEIOyOgJL9AyoZSmkx8ZhZONaZmVtpi6Vgm95 TtHzDW+1fc+lHzRF+i/SZL1wKLkXdcNqB6DD8zRJHnuqa5v/cwi+ip0sOzNOO9MMRnQI 1ZZA== X-Received: by 10.49.83.197 with SMTP id s5mr14866046qey.22.1374185664083; Thu, 18 Jul 2013 15:14:24 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id b4sm19292483qas.3.2013.07.18.15.14.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 15:14:23 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Thu, 18 Jul 2013 15:14:21 -0700 Message-Id: To: IPv6 IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 22:14:25 -0000 All, This message starts a two week 6MAN Working Group on advancing: Title : Transmission of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ext-transmit-01.txt Pages : 9 Date : 2013-05-29 http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the author. This last call will = end on 1 August 2013. The chairs would also like to solicit a few people to do a detailed = review of this document. Please contact the chairs directly. Regards, Bob Hinden & Ole Tr=F8an From bob.hinden@gmail.com Thu Jul 18 16:31:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A352A21E8153 for ; Thu, 18 Jul 2013 16:31: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 vHMbiZY0tel3 for ; Thu, 18 Jul 2013 16:31:11 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1683E21E814D for ; Thu, 18 Jul 2013 16:31:11 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so2134511qeb.17 for ; Thu, 18 Jul 2013 16:31:10 -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 :cc:to:mime-version:x-mailer; bh=7IP8uH/Ad1LeRflm2JRYE2syE+FCkDRhChSKiJciKzc=; b=of9J5Kurpbwh2/KkcpSer+FVdU2ApBqHDf6Kpe7eiQ/k7J2TjSRIL1a4uggidpin/F ZemvJflDHMTKUcFDnsZjRbT89josHxt/Yc7VoWwBomQJ2RLicyxwALQYEImt+gHDfjIH OnwsY5tmFc5Ei6XFLTFWswwF9IFSjwqwHZmIgbVzh5woroA+0zAVVQlJ5hSUn+65WK7p snnmSU7RWqTxzu5mTBNVYdxWbiCyrWiKrtp7CwU/v3t/8/DeuWyOGJKrqF3VSdbUgnKa XUBEhJQeiM2aAJvcIVeq5R3pPk6ijDqR2L90wSIhn796NK4J/MaJWXqgV+FHf+3vUDFU gu3Q== X-Received: by 10.224.137.130 with SMTP id w2mr8856817qat.71.1374190270590; Thu, 18 Jul 2013 16:31:10 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id ng3sm16466879qeb.0.2013.07.18.16.31.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 16:31:10 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: RESEND: 6MAN WG Last Call: Date: Thu, 18 Jul 2013 16:31:08 -0700 Message-Id: <111B8370-7FB5-420B-8250-F0D09FBB5BEF@gmail.com> To: IPv6 IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 23:31:11 -0000 Wrong file name in the Subject line. Bob ------------- All, This message starts a two week 6MAN Working Group on advancing: Title : Transmission of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ext-transmit-01.txt Pages : 9 Date : 2013-05-29 http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the author. This last call will = end on 1 August 2013. The chairs would also like to solicit a few people to do a detailed = review of this document. Please contact the chairs directly. Regards, Bob Hinden & Ole Tr=F8an From alexandru.petrescu@gmail.com Fri Jul 19 02:24:52 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3469B11E80E2 for ; Fri, 19 Jul 2013 02:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Lva9KylLcF4r for ; Fri, 19 Jul 2013 02:24:47 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6965911E80F0 for ; Fri, 19 Jul 2013 02:24:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r6J9OhMD000717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 19 Jul 2013 11:24:43 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6J9OgVt001879 for ; Fri, 19 Jul 2013 11:24:42 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6J9OaHE021407 for ; Fri, 19 Jul 2013 11:24:42 +0200 Message-ID: <51E905D4.6090507@gmail.com> Date: Fri, 19 Jul 2013 11:24:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: New Version Notification for draft-sarikaya-6man-rfc4191bis-00.txt References: <20130708170331.21564.5258.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:24:52 -0000 Hello, This draft proposes, among other things, that Routers send prefix/nexthop couples in the RA, towards a multi-interfaced Host. This would allow the Host to install specific routes, and subsequently to select the nexthop based on the destination prefix. A similar mechanism is proposed in vehicular communications, where two nearby vehicles exchange their prefix/nexthop using RA (Router-to-Router communications, not Router-to-Host). Some of these RA-based prefix exchanges are considered at some SDO, and why not at IETF as well. Although Router-to-Router is not the same as Router-to-Host, one legitimately wonders whether this is not the same concept. Given this perspective of industry interest, I wonder the following: - what particular industry has interest in the mechanism of draft-sarikaya-6man-rfc4191bis-00.txt? - where to discuss this is most appropriate: in an IPv6-specific group? in a vehicular-specific group? in a multi-interfaced specific group? Maybe a cross-group review would be valuable? Yours, Alex Le 08/07/2013 19:06, Behcet Sarikaya a écrit : > A new version of I-D, draft-sarikaya-6man- > > rfc4191bis-00.txt has been successfully submitted by Behcet Sarikaya > and posted to the IETF repository. > > Filename: draft-sarikaya-6man-rfc4191bis Revision: 00 > Title: IPv6 RA Options for Next Hop Routes Creation date: > 2013-07-08 Group: Individual Submission Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-sarikaya-6man-rfc4191bis-00.txt > > > Status: http://datatracker.ietf.org/doc/draft-sarikaya-6man-rfc4191bis > Htmlized: > http://tools.ietf.org/html/draft-sarikaya-6man-rfc4191bis-00 > > > Abstract: This proposes an update on RFC 4191 in order to define new > Router Advertisement options for configuring next hop routes on the > mobile or fixed nodes. Using these options, an operator can easily > configure nodes with multiple interfaces (or otherwise multi-homed) > to enable them to select the routes to a destination. Each option is > defined together with definitions of host and router behaviors. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alper.yegin@yegin.org Fri Jul 19 06:35:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C294D11E8226 for ; Fri, 19 Jul 2013 06:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.035, 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 J-OPDFgxbl9J for ; Fri, 19 Jul 2013 06:34:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 043BA21F8B04 for ; Fri, 19 Jul 2013 06:34:58 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0McV4q-1UiVQM31YO-00IUvo; Fri, 19 Jul 2013 09:34:56 -0400 From: Alper Yegin Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_5BBEF02E-392A-4644-900D-54929ABA0587" Subject: korhonen-6man-prefix-properties-02 Date: Fri, 19 Jul 2013 16:34:53 +0300 In-Reply-To: <51E905D4.6090507@gmail.com> To: ipv6@ietf.org References: <20130708170331.21564.5258.idtracker@ietfa.amsl.com> <51E905D4.6090507@gmail.com> Message-Id: <38D3E493-1E5E-4A01-89B1-41ACD16A7826@yegin.org> X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:MglEVCdCE8L4k6q4h/lHZ9tvFi/BA/UbvlW6Agkf91k RZ4eeQKwEsr/4BYFsQoPwHA4nzoAjQoJ9i+4dDCB3QwcSbVJPj MQ/tkgIhy9qPP8aa1u3zVw2EzVGDRwPF3ozQu3x7HLAsqgIq2y G4a0SQPa73suBfZtWQPhApdNWwI8BQwLab+ZlGXzC0kZ0NvTL7 4VHnK2V9IZV/X9UrJbo7t/MIc5jGqe/4cfHB3/Y7f9FDZV1ebF a3LWNaFYbVxmpzUg0zXvA+/r55COEvTnb0VmicIW3xyJ/6TJSn wn8XlQ3pRAqYfWn++KbZP+8mWa6EFq3wD8g7N1NwXHUWFvQ22g hbaxpCIteD8YSm61yc8G/rkLBWwHDfX3PUvxzw51luH3jwEufF lyjK1iiIsv7qw== X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:35:02 -0000 --Apple-Mail=_5BBEF02E-392A-4644-900D-54929ABA0587 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Having read this I-D, One question: When an end host receives a router advertisement message with a PIOMT and the prefix class suboption, it can use the suboption information as an additional hint for selecting the prefix for a desired purpose and use case. The prefix class has only local administrative meaning i.e., they are local to the access network and may overlap both semantically and registry wise across different administrative domains. How is the class information delivered to the nodes? I know this is = outside the scope of this protocol specification, but having some = understanding on that would help us better judge the applicability. And, one comment: The overall problem statement and the solution make sense. In fact, we = have a complementary draft which exposes the IP address properties to = the applications and allow them to make a proper selection. = http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-00 Regards, Alper --Apple-Mail=_5BBEF02E-392A-4644-900D-54929ABA0587 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Having read this I-D,

One question:

   When an end host receives a
   router advertisement message with a PIOMT and the prefix class
   suboption, it can use the suboption information as an additional hint
   for selecting the prefix for a desired purpose and use case.  The
   prefix class has only local administrative meaning i.e., they are
   local to the access network and may overlap both semantically and
   registry wise across different administrative domains.

How is the class information delivered to the nodes? I know this is outside the scope of this protocol specification, but having some understanding on that would help us better judge the applicability.

And, one comment:

The overall problem statement and the solution make sense. In fact, we have a complementary draft which exposes the IP address properties to the applications and allow them to make a proper selection. http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-00

Regards,

Alper




--Apple-Mail=_5BBEF02E-392A-4644-900D-54929ABA0587-- From jouni.nospam@gmail.com Fri Jul 19 07:56:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9058A21E80EC for ; Fri, 19 Jul 2013 07:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 R6DyEu5Ya6ev for ; Fri, 19 Jul 2013 07:56:53 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id E032711E82AC for ; Fri, 19 Jul 2013 07:56:44 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so3536400lbh.35 for ; Fri, 19 Jul 2013 07:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=CJBCykGhdR7H5WKiIgNgTO0KhOGvpytyfapHn/ECBh0=; b=yC8pke6/h+LcnQHUN5Mp7Sh3/WIPyOnUTJYlrLMylShRD/mPLOF58NoeUvhnkM6FEo MdqZVwAT8zPgpplu8aGvUyUnrFXVFCdx517NqbSSMuUYac8AmMW8uuYoSsXUQwDtn5rH L6ltCh9Zt0VATOOoihRtDl6HhWcvjw57qSQOijBYJ24iU7pIZFU7a52o3xMqt81T57l0 tX7GEmv6dcZvWWHFavucwMViAzLb5ZgAlSKPoLPRA787SmhqEvQp1F6XSGcHAC/hHjt6 zf7Qhy3VGsIlnEao5MSDJB98GSLVPKl/L4u39po8dsS8DsCjGFCMPSIChAyNlzo2Yvm/ zNpQ== X-Received: by 10.112.200.9 with SMTP id jo9mr7629585lbc.54.1374245802635; Fri, 19 Jul 2013 07:56:42 -0700 (PDT) Received: from 87-93-18-125.bb.dnainternet.fi (87-93-18-125.bb.dnainternet.fi. [87.93.18.125]) by mx.google.com with ESMTPSA id x5sm6253705lbx.8.2013.07.19.07.56.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 07:56:40 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: korhonen-6man-prefix-properties-02 From: Jouni Korhonen In-Reply-To: <38D3E493-1E5E-4A01-89B1-41ACD16A7826@yegin.org> Date: Fri, 19 Jul 2013 17:56:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <43C94E5E-B255-436C-89F3-2AB0CF731DC2@gmail.com> References: <20130708170331.21564.5258.idtracker@ietfa.amsl.com> <51E905D4.6090507@gmail.com> <38D3E493-1E5E-4A01-89B1-41ACD16A7826@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1508) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:56:55 -0000 Alper, Thanks for the review..=20 On Jul 19, 2013, at 4:34 PM, Alper Yegin wrote: > Having read this I-D, >=20 > One question: >=20 > When an end host receives a > router advertisement message with a PIOMT and the prefix class > suboption, it can use the suboption information as an additional = hint > for selecting the prefix for a desired purpose and use case. The > prefix class has only local administrative meaning i.e., they are > local to the access network and may overlap both semantically and > registry wise across different administrative domains. >=20 >=20 > How is the class information delivered to the nodes? I know this is = outside the scope of this protocol specification, but having some = understanding on that would help us better judge the applicability. Since the class information is intended to be administrative domain specific a good proponent for information delivery is a connection manager type of application or some service daemon (something provided e.g. by an enterprise network administrator) that application can query. I all cases the applications need to be aware of classes. (note that we do not have standardized means for identifying administrative domain boundaries/provisioning domains yes - Mif works on that part..) > And, one comment: >=20 > The overall problem statement and the solution make sense. In fact, we = have a complementary draft which exposes the IP address properties to = the applications and allow them to make a proper selection. = http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-00 Great, good to know. - JOuni >=20 > Regards, >=20 > Alper >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shwethab@cisco.com Mon Jul 22 02:14:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3920921F9E28; Mon, 22 Jul 2013 02:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHZxV+b-CJb3; Mon, 22 Jul 2013 02:14:11 -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 495E111E80F6; Mon, 22 Jul 2013 02:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8995; q=dns/txt; s=iport; t=1374483723; x=1375693323; h=from:to:cc:subject:date:message-id:mime-version; bh=BILvsgVZFcHpy9kA52TLapM8ijaRRJ8fIOtr82C4oow=; b=CvA5OA4yfdF0G/XmWfG6WKrFfX+WhDG54YBtQVsR/fmbDyR3Fx8rByJn nme1GSvUY7xN4z8NwiCVOOsiKZCUBPlut82wm7X0cL4rg3J2+iXZQHSGt +prAnxhrIP3F2rIpLaCfwa7lP+gO6uBdsQ5OT4jipMj/jSMR5m6iq7nMd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAJ/07FGtJXG8/2dsb2JhbABagkJENVCFa6hUiTeGXYFcgQ4WdIImAQR5EgEqHTkUEwQBDQUIAYgHDLZRj2UxgxduA5kGkCSBNYFdgio X-IronPort-AV: E=Sophos;i="4.89,718,1367971200"; d="scan'208,217";a="234712404" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2013 09:01:35 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6M91ZnY030245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 09:01:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 04:01:34 -0500 From: "Shwetha Bhandari (shwethab)" To: "6man@ietf.org" <6man@ietf.org>, homenet Subject: New draft - draft-lepape-6man-prefix-metadata-00 Thread-Topic: New draft - draft-lepape-6man-prefix-metadata-00 Thread-Index: AQHOhroQkJk7kCFKG0uq75eC/FgqFg== Date: Mon, 22 Jul 2013 09:01:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.142.104.90] Content-Type: multipart/alternative; boundary="_000_D760207426D56242BAF68F47647CF1071C97D1D8xmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 22 Jul 2013 02:19:43 -0700 Cc: "'ian.farrer@telekom.de'" , "draft-bhandari-dhc-class-based-prefix@tools.ietf.org" , "draft-korhonen-6man-prefix-properties@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 09:14:18 -0000 --_000_D760207426D56242BAF68F47647CF1071C97D1D8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, A new draft draft-lepape-6man-prefix-metadata-00 describing a method for application= s to learn and influence source address selection by associating IPv6 prefi= xes with meta-data when configured by the network is submitted. Motivation = to do this and details of a prototype that has been developed are included.= Related drafts that define DHCPv6 and ND options to realize conveying of m= eta-data associated with a prefix are draft-bhandari-dhc-class-based-prefix= and draft-korho= nen-6man-prefix-properties. Motivation for doing this work is relevant to homenet hence= adding homenet wg. Appreciate review of the draft and comments. Thanks, Shwetha On 7/15/13 8:52 PM, "internet-drafts@ietf.org" > wrote: A new version of I-D, draft-lepape-6man-prefix-metadata-00.txt has been successfully submitted by Maico Le Pape and posted to the IETF repository. Filename: draft-lepape-6man-prefix-metadata Revision: 00 Title: IPv6 Prefix Meta-data and Usage Creation date: 2013-07-15 Group: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-lepape-6man-pref= ix-metadata-00.txt Status: http://datatracker.ietf.org/doc/draft-lepape-6man-prefix-m= etadata Htmlized: http://tools.ietf.org/html/draft-lepape-6man-prefix-metada= ta-00 Abstract: This document presents a method for applications to influence the IPv6 source selection algorithm used by the IP stack in a host. To do so, IPv6 prefixes are associated with meta-data when configured by the network. This meta-data allows the network to describe the purpose and properties of the prefix enabling applications to make intelligent decision when selecting a prefix. The IETF Secretariat --_000_D760207426D56242BAF68F47647CF1071C97D1D8xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <7A8B8A9C7C61624EB6744EDD8509241E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello,

A new draft draft-lepape-6man-prefix-metadata-00  describing a method for applications to learn and influence source address selection b= y associating IPv6 prefixes with meta-data when configured by the network is submitted. Motivation to do this and details= of a prototype that has been developed are included. Related drafts that d= efine DHCPv6 and ND options to realize conveying of meta-data associated with a prefix are draft-bhandari-dhc-class-based-prefix and draft-korhonen-6man-prefix-properties. Motivation for doing this work is re= levant to homenet hence adding homenet wg.

Appreciate review of the draft and comments.

Thanks,
Shwetha




A new version of I-D, draft-lepape-6man-prefix-metadata-00.txt
has been successfully submitted by Maico Le Pape and posted to the
IETF repository.

Filename:     draft-lepape-6man-prefix-metadata
Revision:     00
Title:         IPv6 Prefix Met= a-data and Usage
Creation date:     2013-07-15
Group:         Individual Subm= ission
Number of pages: 16


Abstract:
   This document presents a method for applications to influ= ence the
   IPv6 source selection algorithm used by the IP stack in a= host.  To
   do so, IPv6 prefixes are associated with meta-data when c= onfigured by
   the network.  This meta-data allows the network= to describe the
   purpose and properties of the prefix enabling application= s to make
   intelligent decision when selecting a prefix.


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


The IETF Secretariat

--_000_D760207426D56242BAF68F47647CF1071C97D1D8xmbrcdx04ciscoc_-- From leo.liubing@huawei.com Mon Jul 22 02:58:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F0421E80A1 for ; Mon, 22 Jul 2013 02:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeaEcmopaenR for ; Mon, 22 Jul 2013 02:58:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB34E21E8050 for ; Mon, 22 Jul 2013 02:56:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR04374; Mon, 22 Jul 2013 09:56:14 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 10:55:55 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 10:56:02 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 17:55:57 +0800 From: "Liubing (Leo)" To: Bob Hinden , IPv6 IPv6 List Subject: RE: RESEND: 6MAN WG Last Call: Thread-Topic: RESEND: 6MAN WG Last Call: Thread-Index: AQHOhA7qBWMjg6j/BUe1uETvTgwcgJlweu2A Date: Mon, 22 Jul 2013 09:55:56 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D752668@nkgeml506-mbx.china.huawei.com> References: <111B8370-7FB5-420B-8250-F0D09FBB5BEF@gmail.com> In-Reply-To: <111B8370-7FB5-420B-8250-F0D09FBB5BEF@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 09:58:34 -0000 Hi, WG I support advancing this draft. B.R. Bing > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Bob Hinden > Sent: Friday, July 19, 2013 7:31 AM > To: IPv6 IPv6 List > Cc: Bob Hinden > Subject: RESEND: 6MAN WG Last Call: >=20 > Wrong file name in the Subject line. >=20 > Bob >=20 > ------------- >=20 > All, >=20 > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Transmission of IPv6 Extension Headers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ext-transmit-01.txt > Pages : 9 > Date : 2013-05-29 >=20 > http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 >=20 > as a Proposed Standard. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. Edit= orial > suggestions can be sent to the author. This last call will end on 1 Augu= st > 2013. >=20 > The chairs would also like to solicit a few people to do a detailed revie= w of > this document. Please contact the chairs directly. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From leo.liubing@huawei.com Mon Jul 22 02:59:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B618521E805F for ; Mon, 22 Jul 2013 02:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuMMRt404WDz for ; Mon, 22 Jul 2013 02:59:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB95411E80E4 for ; Mon, 22 Jul 2013 02:58:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVH33045; Mon, 22 Jul 2013 09:58:16 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 10:57:50 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 10:57:56 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 17:57:53 +0800 From: "Liubing (Leo)" To: Bob Hinden , IPv6 IPv6 List Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOhAO9q5UzRr4G+EOUPFPNDX04pJlwe3KA Date: Mon, 22 Jul 2013 09:57:53 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D752674@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 09:59:57 -0000 Hi, WG Support for advancing. Best regards, Bing > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Bob Hinden > Sent: Friday, July 19, 2013 6:11 AM > To: IPv6 IPv6 List > Cc: Bob Hinden > Subject: 6MAN WG Last Call: >=20 > All, >=20 > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-01.txt > Pages : 11 > Date : 2013-05-24 >=20 > http://tools.ietf.org/html/draft-ietf-6man-ug-01 >=20 > as a Proposed Standard. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. Edit= orial > suggestions can be sent to the author. This last call will end on 1 Augu= st > 2013. >=20 > The chairs would also like to solicit a few people to do a detailed revie= w of > this document. Please contact the chairs directly. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From volz@cisco.com Mon Jul 22 04:41:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20D211E80E8 for ; Mon, 22 Jul 2013 04:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.023, 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 TTYjvMnKHc04 for ; Mon, 22 Jul 2013 04:41:17 -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 98C4111E80C5 for ; Mon, 22 Jul 2013 04:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12629; q=dns/txt; s=iport; t=1374493277; x=1375702877; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B/ui1A73Ad3caG7kUxjcGyLj3seh6RSlygefNOYKJHU=; b=JlYgHc7fF9fiCWWwlmqA/n3/qmOOlbkxvWwDJ/9PWGbqgpPSBvcRLEYe abcQ0eLirtgXIsd+E6VFYc9tZlozl+Dkhb/lMvvfi1SepJ6wLHGwtyejV uglgfmvJa1utlOakGjuVrg5YFMekovJ3H54xYlWkhRUGS/tBO3WRWUBD+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFACsZ7VGtJV2Z/2dsb2JhbABagwY1uEeIOYEOFnSCJAEBAQQBAQFrCwwEAgEIEQQBASgHJwsUCQgCBA4FiBAMtm2QEgQHBoMKbgOIcI5tgSmQJIMS X-IronPort-AV: E=Sophos;i="4.89,718,1367971200"; d="scan'208,217";a="237787249" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jul 2013 11:41:16 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6MBfFOB014633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 11:41:16 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 06:41:15 -0500 From: "Bernie Volz (volz)" To: Bob Hinden Subject: Re: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOhAO9q5UzRr4G+EOUPFPNDX04pJlwe3KAgAAdRaw= Date: Mon, 22 Jul 2013 11:41:14 +0000 Message-ID: <3A7BCCBD-5F9B-4D96-9FC8-796F75D92EE1@cisco.com> References: , <8AE0F17B87264D4CAC7DE0AA6C406F453D752674@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D752674@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3A7BCCBD5F9B4D969FC8796F75D92EE1ciscocom_" MIME-Version: 1.0 Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 11:41:22 -0000 --_000_3A7BCCBD5F9B4D969FC8796F75D92EE1ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perhaps you've argued this before, but per rfc 4291, u=3D1, g=3D0 is what a= n IID that was formed from a MAC address uses, not u=3D0. The IEEE mac bits= are u=3D0, g=3D0. In the context below, perhaps best to be clear ... Use I= EEE "u" =3D "g" =3D 0? Or IID "u" =3D 1 and "g" =3D 0. (It is also a bit = odd that 2nd sentence talks about IID into MAC and 4th sentence switches th= is to MAC into IID, especially given last sentence.) 3. Usefulness = of the U and G Bits Given that the "u" and "g" bits do not have a reliable meaning in an IID, it is relevant to consider what usefulness they do have. If an IID is known or guessed to have been created according to RFC 4291, it could be transformed back i= nto a MAC address. This can be very helpful during operational fault diagnosis. For that reason, mapping the IEEE "u" and "g" bits into the IID has operational usefulness. However, it should be stressed that "u" =3D "g" =3D 0 does not prove that an IID was formed from a MAC address; on the contrary, it might equally result from another method. With other methods, there is no reverse transformation available. - Bernie (from iPad) On Jul 22, 2013, at 6:01 AM, "Liubing (Leo)" > wrote: Hi, WG Support for advancing. Best regards, Bing -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Bob Hinden Sent: Friday, July 19, 2013 6:11 AM To: IPv6 IPv6 List Cc: Bob Hinden Subject: 6MAN WG Last Call: All, This message starts a two week 6MAN Working Group on advancing: Title : Significance of IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ug-01.txt Pages : 11 Date : 2013-05-24 http://tools.ietf.org/html/draft-ietf-6man-ug-01 as a Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editor= ial suggestions can be sent to the author. This last call will end on 1 August 2013. The chairs would also like to solicit a few people to do a detailed review = of this document. Please contact the chairs directly. Regards, Bob Hinden & Ole Tr=F8an -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_3A7BCCBD5F9B4D969FC8796F75D92EE1ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Perhaps you've argued this = before, but per rfc 4291, u=3D1, g=3D0 is what an IID that was formed from = a MAC address uses, not u=3D0. The IEEE mac bits are u=3D0, g=3D0. In the c= ontext below, perhaps best to be clear ... Use IEEE  "u" =3D "g" =3D 0? Or IID  = "u" =3D 1 and "g" =3D 0. (It is also a bit odd that 2nd sentence tal= ks about IID into MAC and 4th sentence switches this to MAC into IID, espec= ially given last sentence.)


=

3.  Usefulness of the U and G Bits


   Given that the "u" and "g" bits do not have a reliab=
le meaning in an
   IID, it is relevant to consider what usefulness they do have.

   If an IID is known or guessed to have been created according to RFC
   4291, it could be tra=
nsformed back into a MAC address.  This can be
   very helpful during operational fault diagnosis.  For that reason,
   mapping the IEEE "u" and "g" bits into the IID has o=
perational
   usefulness.  However, it should be stressed that "u" =3D "=
;g" =3D 0 does
   not prove that an IID was formed from a MAC address; on the contrary,
   it might equally result from another method.  With other methods,
   there is no reverse transformation available.


- Bernie (from iPad)=

On Jul 22, 2013, at 6:01 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote:

Hi, WG

Support for advancing.

Best regards,
Bing

-----Original Message-----
From: ipv6-bounces@ietf.org [mai= lto:ipv6-bounces@ietf.org] On Behalf Of
Bob Hinden
Sent: Friday, July 19, 2013 6:11 AM<= br>
To: IPv6 IPv6 List
Cc: Bob Hinden
Subject: 6MAN WG Last Call: <draft-ietf-= 6man-ug-01.txt>

All,

This message starts a two week 6MAN Working= Group on advancing:

   Title     =       : Significance of IPv6 Interface Identi= fiers
   Author(s)    &n= bsp;  : Brian Carpenter
       &= nbsp;           &nbs= p;     Sheng Jiang
   Filename    &nb= sp;   : draft-ietf-6man-ug-01.txt
   Pages     =       : 11
   Date     &= nbsp;      : 2013-05-24

       <= a href=3D"http://tools.ietf.org/html/draft-ietf-6man-ug-01">http://tools.ie= tf.org/html/draft-ietf-6man-ug-01

as a Proposed Standard.  Substantive c= omments and statements of support
for advancing this document should be direc= ted to the mailing list.  Editorial
suggestions can be sent to the author. &nbs= p;This last call will end on 1 August
2013.

The chairs would also like to solicit a few= people to do a detailed review of
this document.  Please contact the cha= irs directly.

Regards,

Bob Hinden & Ole Tr=F8an


-------------------------------------------= -------------------------
IETF IPv6 working group mailing list=
ipv6@ietf.= org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------= -------------------------
--------------------------------------------------------------------<= /span>
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------<= /span>
--_000_3A7BCCBD5F9B4D969FC8796F75D92EE1ciscocom_-- From Fred.L.Templin@boeing.com Mon Jul 22 09:32:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA98A11E80D9 for ; Mon, 22 Jul 2013 09:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVrZ6WG3jMg8 for ; Mon, 22 Jul 2013 09:32:16 -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 2BB3211E80D2 for ; Mon, 22 Jul 2013 09:31:39 -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 r6MGVbM0004311 for ; Mon, 22 Jul 2013 09:31:37 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6MGVb0l004304 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Jul 2013 09:31:37 -0700 Received: from XCH-BLV-308.nw.nos.boeing.com (130.247.25.220) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 22 Jul 2013 09:31:39 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.102]) with mapi id 14.02.0328.011; Mon, 22 Jul 2013 09:31:37 -0700 From: "Templin, Fred L" To: Bob Hinden , IPv6 IPv6 List Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOhAO+I8pISnw60EmvMaWUblvDFplw6Xlw Date: Mon, 22 Jul 2013 16:31:36 +0000 Message-ID: <2134F8430051B64F815C691A62D983180CEF87@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 16:32:23 -0000 Hi, This looks good, but may want to include 1-2 sentences on ISATAP [RFC5214] which is another variant on modified EUI-64. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Bob Hinden > Sent: Thursday, July 18, 2013 3:11 PM > To: IPv6 IPv6 List > Cc: Bob Hinden > Subject: 6MAN WG Last Call: >=20 > All, >=20 > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-01.txt > Pages : 11 > Date : 2013-05-24 >=20 > http://tools.ietf.org/html/draft-ietf-6man-ug-01 >=20 > as a Proposed Standard. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will > end on 1 August 2013. >=20 > The chairs would also like to solicit a few people to do a detailed > review of this document. Please contact the chairs directly. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Mon Jul 22 13:04:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9442911E8137 for ; Mon, 22 Jul 2013 13:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEPw00JLmzkF for ; Mon, 22 Jul 2013 13:04:32 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E5CA211E8128 for ; Mon, 22 Jul 2013 13:04:31 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w11so7141811pde.23 for ; Mon, 22 Jul 2013 13:04: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=VRSMVd3sTVEi7QRqHKg5oFKPZx6nxnkeKhdIvEJRx/E=; b=caQv6m3QWhZZD5Zqsqax9PcdZ8i6ytBl75HHgC1ayXz43ZR8E2sDmCC84KfPvnLJyE GheOhFtxRDE9AIkrk8mtB+teeiKhyj66+X/+H4a2d18zmDE3Tf9eCbZTkw4T5ADSq5SO g7SgB7Uy/NdscyEPrGtayOmvT//hmbJbPmnaxPTQ1J2fc0Lf5FHGBZFJQ4+YF1e0Lf+l p9h4mVsYv6TtNxV4ZDhGN/nt7FgxdrWmLQrmDRGhXeBaB4tSXDPEO+7ZsUqjbWcF5jJL QWwuxBlpIVfDS/mI9Z8XMSuoXtuAcvt0BEK93+DUSqA8S5tGussl3hD/3Y9ce8seUW4b cgxg== X-Received: by 10.66.252.234 with SMTP id zv10mr33828151pac.186.1374523471688; Mon, 22 Jul 2013 13:04:31 -0700 (PDT) Received: from [192.168.178.23] (147.192.69.111.dynamic.snap.net.nz. [111.69.192.147]) by mx.google.com with ESMTPSA id ht5sm37430314pbb.29.2013.07.22.13.04.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 13:04:30 -0700 (PDT) Message-ID: <51ED904E.4010205@gmail.com> Date: Tue, 23 Jul 2013 08:04:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Bernie Volz (volz)" Subject: Re: 6MAN WG Last Call: References: , <8AE0F17B87264D4CAC7DE0AA6C406F453D752674@nkgeml506-mbx.china.huawei.com> <3A7BCCBD-5F9B-4D96-9FC8-796F75D92EE1@cisco.com> In-Reply-To: <3A7BCCBD-5F9B-4D96-9FC8-796F75D92EE1@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:04:32 -0000 On 22/07/2013 23:41, Bernie Volz (volz) wrote: > Perhaps you've argued this before, but per rfc 4291, u=3D1, g=3D0 is wh= at an IID that was formed from a MAC address uses, not u=3D0. The IEEE ma= c bits are u=3D0, g=3D0. In the context below, perhaps best to be clear .= =2E. Use IEEE "u" =3D "g" =3D 0? Or IID "u" =3D 1 and "g" =3D 0. (It is= also a bit odd that 2nd sentence talks about IID into MAC and 4th senten= ce switches this to MAC into IID, especially given last sentence.) Bernie, you are correct, the phrasing is slightly confused there. We can correct it. Brian >=20 > 3. Usefuln= ess of the U and G Bits >=20 >=20 > Given that the "u" and "g" bits do not have a reliable meaning in an= > IID, it is relevant to consider what usefulness they do have. >=20 > If an IID is known or guessed to have been created according to RFC<= http://tools.ietf.org/html/rfc4291> > 4291, it could be transformed ba= ck into a MAC address. This can be > very helpful during operational fault diagnosis. For that reason, > mapping the IEEE "u" and "g" bits into the IID has operational > usefulness. However, it should be stressed that "u" =3D "g" =3D 0 d= oes > not prove that an IID was formed from a MAC address; on the contrary= , > it might equally result from another method. With other methods, > there is no reverse transformation available. >=20 >=20 >=20 > - Bernie (from iPad) >=20 > On Jul 22, 2013, at 6:01 AM, "Liubing (Leo)" > wrote: >=20 > Hi, WG >=20 > Support for advancing. >=20 > Best regards, > Bing >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-= bounces@ietf.org] On Behalf Of > Bob Hinden > Sent: Friday, July 19, 2013 6:11 AM > To: IPv6 IPv6 List > Cc: Bob Hinden > Subject: 6MAN WG Last Call: >=20 > All, >=20 > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-01.txt > Pages : 11 > Date : 2013-05-24 >=20 > http://tools.ietf.org/html/draft-ietf-6man-ug-01 >=20 > as a Proposed Standard. Substantive comments and statements of support= > for advancing this document should be directed to the mailing list. Ed= itorial > suggestions can be sent to the author. This last call will end on 1 Au= gust > 2013. >=20 > The chairs would also like to solicit a few people to do a detailed rev= iew of > this document. Please contact the chairs directly. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=C3=B8an >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Mon Jul 22 13:10:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4666311E8138 for ; Mon, 22 Jul 2013 13:10: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=[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 GjABf9DYRIfV for ; Mon, 22 Jul 2013 13:10:42 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9857521F99F6 for ; Mon, 22 Jul 2013 13:10:42 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so7430550pbb.36 for ; Mon, 22 Jul 2013 13:10: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=Xp2uzJ2ywfTRpmIe+f+QPHJywLKUKNw7Q28ur/mNdEo=; b=y8AUfGoKhK3yb2+OHQ7Yy6JI7H1C0chxdAuuDga423DkW2V8J2ggWohlG8RM7SAvCu VB0YZ3bnc0CsTpsw+pukdEhs9ZS8xS5vGJB+098afpFGXHxEiYrUaDO9Q1LlwcHsaE5l WrmCIChQwtrcyvajFIYVRomEAtKlNZTcfBZ5DCSVoOGAqxNHU4ht/bv0FXZHRlFF2896 /vYpVgm8SFVRqISd6iBs5E4xZEMyjU0IOE1pzWO9Tkg2wJ9DoJt7ZfRDJ7acDjq9nToq FTXoBFfHPElpNihelWbmceFKd0Bi/p/rUJQfcacCGUHMuH8PUTrsRbZQM4sZS8lSKngh +Tnw== X-Received: by 10.68.171.99 with SMTP id at3mr33130591pbc.64.1374523842439; Mon, 22 Jul 2013 13:10:42 -0700 (PDT) Received: from [192.168.178.23] (147.192.69.111.dynamic.snap.net.nz. [111.69.192.147]) by mx.google.com with ESMTPSA id sz3sm9158857pbc.5.2013.07.22.13.10.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 13:10:41 -0700 (PDT) Message-ID: <51ED91C1.3000701@gmail.com> Date: Tue, 23 Jul 2013 08:10:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: 6MAN WG Last Call: References: <2134F8430051B64F815C691A62D983180CEF87@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180CEF87@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:10:43 -0000 On 23/07/2013 04:31, Templin, Fred L wrote: > Hi, >=20 > This looks good, but may want to include 1-2 sentences on ISATAP > [RFC5214] which is another variant on modified EUI-64. Yes, we can add that for completeness. (In 6over4, RFC2529, we forced u=3Dg=3D0, but that is operationally irrelevant.) Thanks Brian >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf O= f >> Bob Hinden >> Sent: Thursday, July 18, 2013 3:11 PM >> To: IPv6 IPv6 List >> Cc: Bob Hinden >> Subject: 6MAN WG Last Call: >> >> All, >> >> This message starts a two week 6MAN Working Group on advancing: >> >> Title : Significance of IPv6 Interface Identifiers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-ietf-6man-ug-01.txt >> Pages : 11 >> Date : 2013-05-24 >> >> http://tools.ietf.org/html/draft-ietf-6man-ug-01 >> >> as a Proposed Standard. Substantive comments and statements of suppor= t >> for advancing this document should be directed to the mailing list. >> Editorial suggestions can be sent to the author. This last call will >> end on 1 August 2013. >> >> The chairs would also like to solicit a few people to do a detailed >> review of this document. Please contact the chairs directly. >> >> Regards, >> >> Bob Hinden & Ole Tr=C3=B8an >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From randy@psg.com Mon Jul 22 13:22:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B321F95EF for ; Mon, 22 Jul 2013 13:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErIy6D2KWqKB for ; Mon, 22 Jul 2013 13:22:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id 31C3811E8156 for ; Mon, 22 Jul 2013 13:22:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1V1Mc5-0004CN-B1; Mon, 22 Jul 2013 20:21:53 +0000 Date: Mon, 22 Jul 2013 16:21:45 -0400 Message-ID: From: Randy Bush To: Bob Hinden Subject: Re: 6MAN WG Last Call: In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D752674@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D752674@nkgeml506-mbx.china.huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:22:19 -0000 > This message starts a two week 6MAN Working Group on advancing: > > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-01.txt > Pages : 11 > Date : 2013-05-24 > > http://tools.ietf.org/html/draft-ietf-6man-ug-01 > > as a Proposed Standard. i have read it and i think this is about as good as we're gonna get in this cycle randy From brian.e.carpenter@gmail.com Mon Jul 22 13:41:48 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E2A11E8155 for ; Mon, 22 Jul 2013 13:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 OoaPNXrnUJ-b for ; Mon, 22 Jul 2013 13:41:48 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8911E814E for ; Mon, 22 Jul 2013 13:41:48 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w11so7267347pde.37 for ; Mon, 22 Jul 2013 13:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Vd2lS/vA24JzzR/JRXtMvUUtVHr8+TPQDVrUb9oqssk=; b=tz8tShelsWWPfH2JGQOBvsj3J+4mn4QHjyg3sqhz1DB/idHmbrQir27GQpzWDB5zWu H+Rc5OveCLfB8I4ZpW+QxI1lNUFGP+81ArQoj/f4O/zfEyWtS048bZ2otVM8aG7UefC4 4/LkdLUVFsR3i97S7sL43LkrcL3wqwuNtf3tVK7eLGsul5W7VP+d7yT1qJvJCsE9kIO4 OKZOMiTmKDf/x2yGhMwfQtDYqtDV1UtOlFxAA66KC03hMWVVZY1IZAIYcHm6bfaIFckq wo5P2EgPi97VGNgncn7zpDfeMR1fm333TwPRY62U6vtlwKUeRSYOrZu6psnLocg+/htk jb1Q== X-Received: by 10.66.119.74 with SMTP id ks10mr34031084pab.179.1374525707961; Mon, 22 Jul 2013 13:41:47 -0700 (PDT) Received: from [192.168.178.23] (147.192.69.111.dynamic.snap.net.nz. [111.69.192.147]) by mx.google.com with ESMTPSA id qb15sm41006062pab.13.2013.07.22.13.41.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 13:41:46 -0700 (PDT) Message-ID: <51ED990B.8060600@gmail.com> Date: Tue, 23 Jul 2013 08:41:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: 6MAN WG Last Call: References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:41:48 -0000 The draft contains one open issue, in section 7: > OPEN ISSUE: Alternatively, we could decide to close the reserved IID > registry completely ... Absent other opinions, my proposal is that we do not close the registry. The rest of the section sets a high bar for new entries, which is probably sufficient. Regards Brian From markzzzsmith@yahoo.com.au Mon Jul 22 14:12:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B5E11E814D for ; Mon, 22 Jul 2013 14:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIuR2d9b8-v2 for ; Mon, 22 Jul 2013 14:12:17 -0700 (PDT) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) by ietfa.amsl.com (Postfix) with ESMTP id C9C9C11E811B for ; Mon, 22 Jul 2013 14:12:15 -0700 (PDT) Received: from [98.139.212.151] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 21:12:14 -0000 Received: from [98.139.212.229] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 21:12:14 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 21:12:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 264610.64774.bm@omp1038.mail.bf1.yahoo.com Received: (qmail 81867 invoked by uid 60001); 22 Jul 2013 21:12:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1374527534; bh=Ps6TRE4yzDBSz5ROq308EH7x7pzau0FhyRfc8PyHhu4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ec185LtKmUmZfFhIaQqYoJ8qTxx8Gw/wFH79G31oLcb3fCalGFZax4OriFpTetF/KFq07Lw2xu7V6LgSI1qaaDVjy6ybeem56jz6cCQwwx/78VRBnUsh3C7YAebwcnTHRoPMsdVkQbKMwwA1eeUq/vvbSbj/8KX5uxy/Rg3ak2I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NyuaOHmbU1rznR58wIBSb9DjrAaJpXL1logwS232K29DHkXjDemXGrf5WygNH4HyCusw+LcUmdFWriiZAQK+z4uVqmOnbAEammPmCI6EdUo/bYJiEWy9BnN0oaS6sdxxGt/5BtkohyJ6uVEOU3+xQWmlbO55sCvpaWziWRi68xk=; X-YMail-OSG: BsbEKykVM1moSbaifylnKGzhGDOVNH..viBPo_qyskH_CdW CGK7D8oYkQkoF1ESzs.OqTZdsKsZJDSA8MsT4GOUip7erLes8wY2oME8AHAl IYgqceHHSC8X2yCAxqYxAiWva8QFLQkjnHmN9cTx6ASMSktysGD2hR9IuEq2 1NOw3kNZRZZbk38hJAki8Dzn9Ed26wiJQig5GS4_ncGmSYwWrRibPB9RNzdM 9o5OYOEN6wLVIxzdiCKgx_Q15QGFkbJezbTuqXOFFwqr8oz3A97epWJtKbOU mxJBiXVoZFkVK6pY9dXtT.tJPN0qgZ9OMxVgjI9uSr6lLZ66KTW.kzvJTsLz Z3jqOTV2DxkWXqLSVImUJuYrI0obfpouGTxZ6uQV6P5bnA1KjaHUEdEC_Zsh V15ftrYMnwC.Bq_j9NpnE3JY0AtyaYIPpVXhC6SeRyZbidkWBw8QlUinH3pd D_GwaCaAso_ZC34sstBusn2wuNXK8c6J0FJzbP36.PysJY08QZX_4v.A8J1Z xsCaAfDtR8kjVdmxuisUSLNZlfNl6LO3dey_Vm3_ENE.feg_4bXzcTmbobJW .ywY8ulWO.J0qJP3pZpE- Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Mon, 22 Jul 2013 14:12:14 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpGaXJzdGx5LCBJIHN1cHBvcnQgYWR2YW5jaW5nIHRoaXMgZHJhZnQuCgpTb21lIHN1Z2dlc3RlZCBjaGFuZ2VzOgoKIiDCoFRoaXMgaGFzIG5vIGtub3duIGhhcm1mdWwgZWZmZWN0IGFzIGxvbmcgYXMgdGhlCsKgIMKgcmVwbGljYXRlZCBNQUMgYWRkcmVzc2VzIGFuZCBJSURzIGFyZSB1c2VkIG9uIGRpZmZlcmVudCBsYXllciAyCsKgIMKgbGlua3MuIMKgSWYgdGhleSBhcmUgdXNlZCBvbiB0aGUgc2FtZSBsaW5rLCBvZiBjb3Vyc2UgdGhlcmUgd2lsbCBiZSBhCsKgIMKgcHJvYmxlbSwgdG8gYmUgZGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.150.561 References: Message-ID: <1374527534.81451.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Mon, 22 Jul 2013 14:12:14 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: IPv6 IPv6 List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 21:12:22 -0000 Hi,=0A=0AFirstly, I support advancing this draft.=0A=0ASome suggested chang= es:=0A=0A" =A0This has no known harmful effect as long as the=0A=A0 =A0repl= icated MAC addresses and IIDs are used on different layer 2=0A=A0 =A0links.= =A0If they are used on the same link, of course there will be a=0A=A0 =A0p= roblem, to be detected by duplicate address detection [RFC4862], but=0A=A0 = =A0such a problem can usually only be resolved by human intervention."=0A= =0AI think it would be worth pointing out that the link layer is most likel= y to fail to operate with duplicate link layer addresses, before DAD has a = chance to detect duplicate IPv6 addresses.=0A=0A=0A" =A0Also, there is=0A= =A0 =A0evidence from the field that IEEE MAC addresses with "u" =3D 0 are= =0A=A0 =A0sometime incorrectly assigned to multiple MAC interfaces. =A0Firs= tly,=0A=A0 =A0there are recurrent reports of manufacturers assigning the sa= me MAC=0A=A0 =A0address to multiple devices.=A0Secondly, significant re-use= of the=0A=A0 =A0same virtual MAC address is reported in virtual machine en= vironments.=A0"=0A=0AI found this text a bit confusing. The '"u" =3D 0' ter= m read like it was referring to locally unique IEEE MAC addresses ("unique = equals no"), and then the 2nd sentence is referring to globally unique (but= duplicated and therefore not actually globally unique) MAC addresses, u = =3D 1 in an IPv6 IID, the opposite of what the previous sentence was referr= ing to. Then the third sentence seems to be describing to what the first se= ntence was referring to. I think the cause of the confusion might be that I= EEE use the "locally assigned" bit to distinguish locally generated or not = (i.e., "l" =3D 0 for globally unique), where as IPv6 IIDs have renamed it t= o "u" bit when the value is inverted. I'd suggest trying to ensure the IEEE= terminology is used when IEEE addresses are discussed to make it clearer w= hat the properties of the IEEE address are.=0A=0ARegards,=0AMark. From markzzzsmith@yahoo.com.au Mon Jul 22 14:15:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEFF11E8145 for ; Mon, 22 Jul 2013 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d6-jSvdFCGi for ; Mon, 22 Jul 2013 14:14:59 -0700 (PDT) Received: from nm36-vm0.bullet.mail.bf1.yahoo.com (nm36-vm0.bullet.mail.bf1.yahoo.com [72.30.238.136]) by ietfa.amsl.com (Postfix) with ESMTP id 3F66811E813A for ; Mon, 22 Jul 2013 14:14:59 -0700 (PDT) Received: from [98.139.214.32] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 21:14:57 -0000 Received: from [98.139.212.212] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 21:14:57 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 21:14:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 833111.25886.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 14119 invoked by uid 60001); 22 Jul 2013 21:14:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1374527697; bh=6YjBEch0vSNEPlNv5MG7z/8IhFid0HqqCV31zDdIZYo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uni2FWb8Vf4Mez3OkChVUZ/vuC3KF+mH9bIVW6VbjTalsZ7v4OkzYw4MYe5na9+8QDqmpZnhbWcPQqWyxyHY8VVZUGoWB7nAClP3+sG5U8WXax1NBYb8K1JypkMiGi7PFpVtKLr7XASZd9F6jHGz2EF+6CdtJpiEtop6FfuArD0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rjiAp/o/ddVHBpXvxskPXcjgWvtzXhZg4XjYkStBXv5tyL4ShDQq+eq9fcNoX5kKA1wrPUac0c3dorAByRiUb5MKQTkxdFVohRSu1uw6sQbw1PfvTn6EZWfXdQFFaJURx9EER2fxEoFwPzXDhpRLl2C0vz6NswRCpowKTIJPLDs=; X-YMail-OSG: 28dbNZ8VM1nKyrdnpdJ_XBKFsVgAzANSSZfhAEXRsyJCuv_ 5CkwrV2IdahQID4HKp994jUT0HNDbOZZDm9H1NyrJhf4WxmJVn5T5dvxE.OS ieJOLGk_QsY264DxmauAIjxFkTT.oIw.a5fmvzqo8XWKO9BPuKoAfv_xRIvY 5zaeXdnSLCumU5z_s1zzWu2y__6szlc0h9ai70vHfA1IG.FmaAeJ4c1eKB3I SAb2SOsjHI6GDecwOUSrpV3fPA6f98pk7IOGy1T1eC55.AlxsYtRr5AE0aP8 dt9CIBhEQDCKHfIbVwbJFs6XyQHkgoEXDWYu9bCL1TmcBgU2c_rPUrTTXMJZ yNw55Zi35S7WCocRMMNz4q9zZcTZn4qqioDduOYjckyeu0qT.hmtL.N5rm0T 7OgN7HyeJ6DZRWDvQUef8pzGgG1q90eGfNnMmDQJlLSgFTrD.nhQoGU58tql tx_NPnTe8bdCkaMNKLWYauLcjXKlHIVF76KvYWstImtlDuzz8U4mUIpV2GFN 2md_koxl_Z9C_um_QKbFOM6g8BSrdNLvjwpMja806nVuDurW3zUkT7BoqKD7 FmmXUMQoHhaV.New- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Mon, 22 Jul 2013 14:14:57 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiA2bWFuIDxpcHY2QGlldGYub3JnPgo.IENjOiAKPiBTZW50OiBUdWVzZGF5LCAyMyBKdWx5IDIwMTMgNjo0MSBBTQo.IFN1YmplY3Q6IFJlOiA2TUFOIFdHIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtNm1hbi11Zy0wMS50eHQ.Cj4gCj5UIGhlIGRyYWZ0IGNvbnRhaW5zIG9uZSBvcGVuIGlzc3VlLCBpbiBzZWN0aW9uIDc6Cj4gCj4.IMKgIMKgIE8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.150.561 References: <51ED990B.8060600@gmail.com> Message-ID: <1374527697.12627.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Mon, 22 Jul 2013 14:14:57 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: Brian E Carpenter , 6man In-Reply-To: <51ED990B.8060600@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 21:15:05 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: 6man =0A> Cc: =0A> Sent: Tue= sday, 23 July 2013 6:41 AM=0A> Subject: Re: 6MAN WG Last Call: =0A> =0A>T he draft contains one open issue, in section 7:= =0A> =0A>> =A0 =A0 OPEN ISSUE: Alternatively, we could decide to close the = reserved IID=0A>> =A0 =A0 registry completely ...=0A> =0A> Absent other opi= nions, my proposal is that we do not close the registry.=0A> The rest of th= e section sets a high bar for new entries, which is=0A> probably sufficient= .=0A>=A0=0A=0AI also agree with not closing the registry.=0A=0ARegards,=0AM= ark. From brian.e.carpenter@gmail.com Mon Jul 22 15:01:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88D311E8169 for ; Mon, 22 Jul 2013 15:01:05 -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 QaFjL5aDgat8 for ; Mon, 22 Jul 2013 15:01:05 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05011E8167 for ; Mon, 22 Jul 2013 15:01:02 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so7287156pdc.5 for ; Mon, 22 Jul 2013 15:01: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=DUuFhbBYrNctCbmCLZjZ148Yod48jYJPig5aCwz2j4w=; b=tRZnOkbmJ/152CyrtxslKx3DYQZIxQdP1/JVaEaJwWnNUxL5QuIEIlhzAbQS1bupOC l3grdpxOjK5guPYkV4VZKQHsgV2tGtxosN2rZeVfBUghfO1cH/mFE9OrWImcKy4Qp/Sq E/ZvZ9yKbIKIySFlGMVyC64dCdzihZ/PZzuEpeUMK7bjGjtrTD6c67z22KD9GP9gh2N6 uWpAhHUQgzxldob11cf03Rm5eu9fwyKE7SE7HebXtuHnXI3lOKRBHqpI7Fde9iAzvNiX psGeviX4PM8ke5ErOjBLnYPTp3iEqUMbGSZ7FhV8THqnOaKFFEueozfYOChnMn7ZT2rM PZjw== X-Received: by 10.66.144.161 with SMTP id sn1mr17935983pab.30.1374530460058; Mon, 22 Jul 2013 15:01:00 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id y9sm37730025pbb.46.2013.07.22.15.00.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 15:00:59 -0700 (PDT) Message-ID: <51EDAB9B.9010004@gmail.com> Date: Tue, 23 Jul 2013 10:00:59 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: References: <1374527534.81451.YahooMailNeo@web142503.mail.bf1.yahoo.com> In-Reply-To: <1374527534.81451.YahooMailNeo@web142503.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 22:01:06 -0000 On 23/07/2013 09:12, Mark ZZZ Smith wrote: > Hi, > > Firstly, I support advancing this draft. > > Some suggested changes: > > " This has no known harmful effect as long as the > replicated MAC addresses and IIDs are used on different layer 2 > links. If they are used on the same link, of course there will be a > problem, to be detected by duplicate address detection [RFC4862], but > such a problem can usually only be resolved by human intervention." > > I think it would be worth pointing out that the link layer is most likely to fail to operate with duplicate link layer addresses, before DAD has a chance to detect duplicate IPv6 addresses. OK. > > " Also, there is > evidence from the field that IEEE MAC addresses with "u" = 0 are > sometime incorrectly assigned to multiple MAC interfaces. Firstly, > there are recurrent reports of manufacturers assigning the same MAC > address to multiple devices. Secondly, significant re-use of the > same virtual MAC address is reported in virtual machine environments. " > > I found this text a bit confusing. The '"u" = 0' term read like it was referring to locally unique IEEE MAC addresses ("unique equals no"), and then the 2nd sentence is referring to globally unique (but duplicated and therefore not actually globally unique) MAC addresses, u = 1 in an IPv6 IID, the opposite of what the previous sentence was referring to. Then the third sentence seems to be describing to what the first sentence was referring to. I think the cause of the confusion might be that IEEE use the "locally assigned" bit to distinguish locally generated or not (i.e., "l" = 0 for globally unique), where as IPv6 IIDs have renamed it to "u" bit when the value is inverted. I'd suggest trying to ensure the IEEE terminology is used when IEEE addresses are discussed to make it clearer what the properties of the IEEE address are. Yep. I remember complaining when the bit inversion was first proposed that it would lead to years of confusion. Which IEEE standard is the basic reference for their terminology? Brian From jinmei.tatuya@gmail.com Mon Jul 22 17:28:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B9921F9E7C for ; Mon, 22 Jul 2013 17:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 dyohBJOlmeHT for ; Mon, 22 Jul 2013 17:28:40 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id B363321F9DA1 for ; Mon, 22 Jul 2013 17:28:39 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so3310427wiw.2 for ; Mon, 22 Jul 2013 17:28:38 -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:cc :content-type:content-transfer-encoding; bh=TOveKU8+k8hNCzPrWlP16bbzsSD+fL9suWIFaSJod7c=; b=zoQ5YCVtIY7JNxsOL8/LlpL9qIZJYCmkaB95TmrL1HHjnyArP3yaFmsb9pzJXO7qgM 1EBQ47b1hWNSH4N1/kzaKE/swpTurzfAtfy1Xz9swUy4IJ6cI05MIR+4pqBumQe7/RDc BKkSUFzUFoLQorJ0bX/SFfoLfUPeUCARZ8//gy4Zf9B3Az3RRKA9vuxxjEhCnTQa+Ai/ pbiVgN/vX6eQbL9DITzVjmHIrCyWWFmyaX4WYwc/U2jEaMXyviVVdipGYdqOLuKG8Rap TXbIzsfuu3+QU1XUIL6HaWW+jXbZ73gLTekFsvvX1VDcTS2pdioIrbb8gUJzHV8WIzmD HRxA== MIME-Version: 1.0 X-Received: by 10.180.78.9 with SMTP id x9mr3322755wiw.15.1374539318630; Mon, 22 Jul 2013 17:28:38 -0700 (PDT) Received: by 10.194.90.230 with HTTP; Mon, 22 Jul 2013 17:28:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Jul 2013 17:28:38 -0700 Message-ID: Subject: Re: 6MAN WG Last Call: From: JINMEI Tatuya Cc: IPv6 IPv6 List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 00:30:16 -0000 At Thu, 18 Jul 2013 15:11:00 -0700, Bob Hinden wrote: > This message starts a two week 6MAN Working Group on advancing: > > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-01.txt > Pages : 11 > Date : 2013-05-24 > > http://tools.ietf.org/html/draft-ietf-6man-ug-01 > > as a Proposed Standard. I think this draft is generally well written and good to be advanced (although I personally don't have a strong opinion on what's proposed in the draft). I have one comment that may improve the clarity of the document: the latter half of Section 4 is not very understandable to me: There is one case in RFC 4862 that requires additional consideration: "On the other hand, if the duplicate link-local address is not formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned, IP operation on the interface MAY be continued." However, as mentioned above, some methods of IID formation might produce IID values with "u" =3D "g" =3D 0 that are not based on a MAC (hardware) address. With very low probability, such a value might collide with an IID based on a MAC address. There is no algorithm for determining whether this case has arisen, rather than a genuine MAC address collision. Implementers should carefully consider the consequences of continuing IPv6 operation on the interface in this unlikely situation. First, as already noted in this thread, the notation of '"u" =3D "g" =3D 0' is confusing and should better be clarified. I guess the intent is "IID values whose position 6 is 1 and position 7 is 0". But then...I'm still not really sure what this paragraph tries to suggest. Is it talking about something like this? - A node N creates an IID not based on a MAC address but its position 6 is 1 and position 7 is 0. - Node N then creates a link-local address using the IID, and performs DAD, which detects a duplicate. - The other address that collides with N's address might be created from a MAC address (name it "MAC1") - And, it might also be possible that N's MAC address is actually MAC1. (So, even if N's IID was not created on that MAC address, the result would have been the same). - Since we cannot eliminate this possibility, we should be careful before continuing IP(v6) operation (as allowed with MAY by RFC 4862, since this link-local address was "not created based on the MAC address"). If so...I don't see much point in noting that explicitly. The main intent of this part of RFC 4862 was that if a link-local address created based on a MAC address is detected to be a duplicate, that very strongly suggests there's MAC address collision, and it's better to take some specific action (i.e, disabling the IP operation). In all other cases, the IP address duplicate may or may not be because of MAC address collision, and since there's no strong indication of MAC address collision, RFC 4862 leaves it to the implementor (hence the MAY). There's always a possibility that duplicated IP address identified via DAD is actually because of duplicate MAC address, even if the way of creating the IID does not directly suggest so. In that sense it wouldn't be bad to raise consideration on the consequence of continuing the IP operation after a duplicate address is detected. But, that doesn't seem to be very specific to the context of the ug bit discussion. And, recalling the original intent of RFC 4862, explicitly mentioning the obvious sounds a bit awkward to me and even tries to update the sense of the RFC. So, unless that (updating RFC 4862 in addition 4291) is the point of this paragraph(s), my first suggestion is simply remove it. If the intent is to update RFC 4862, I think the draft needs to explicitly say so. And, at least the description should be clearer (at least to me it was very difficult to understand what it tries to say). --- JINMEI, Tatuya On Thu, Jul 18, 2013 at 3:14 PM, Bob Hinden wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Transmission of IPv6 Extension Headers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ext-transmit-01.txt > Pages : 9 > Date : 2013-05-29 > > http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 > > as a Proposed Standard. Substantive comments and statements of support f= or advancing this document should be directed to the mailing list. Editori= al suggestions can be sent to the author. This last call will end on 1 Aug= ust 2013. > > The chairs would also like to solicit a few people to do a detailed revie= w of this document. Please contact the chairs directly. > > Regards, > > Bob Hinden & Ole Tr=F8an > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Mon Jul 22 18:09:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACED21F9ED8 for ; Mon, 22 Jul 2013 18:09:53 -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 8cERgNwN0zl3 for ; Mon, 22 Jul 2013 18:09:52 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B467821F9E88 for ; Mon, 22 Jul 2013 18:09:52 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so7753687pbc.10 for ; Mon, 22 Jul 2013 18:09:52 -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=4RguIz5WU24MwsS62X01Irnnm0aAnkwiubfNHZ6PZ1g=; b=osieoyb147LCv2DA4RG8C2nV7ZbTecR2jxoLRVZdqcCZrqcVsd5jzeLTpErsMr3Own KvYA7vbrY1wVhJWbY0Cm3eBZ/gzSPjdTVurg3jCdD9QErKr+9oLge6NIlirHSRkS15Fc wrawqugDJud2+2+BXpPSE34V/K/H84D19UlfTrahhpi8iwtNTuMZJn0Bjs39Xe+v0aEW F0Ff10COLzlMZc0hrVrgIookMR5f2f3kCgYoLQCHcIHxxHNS/MCVASPZHNRmMjZ3qVvQ BsWHf/TqVok9m/puyOZMdzsHpRk1efbEd1tZBBEjcq2SF/edenWS1bKFlxsWhX81Nqdo cRLA== X-Received: by 10.68.250.5 with SMTP id yy5mr33841041pbc.93.1374541791451; Mon, 22 Jul 2013 18:09:51 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id lk9sm41927704pab.2.2013.07.22.18.09.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 18:09:49 -0700 (PDT) Message-ID: <51EDD7DE.8080901@gmail.com> Date: Tue, 23 Jul 2013 13:09:50 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: JINMEI Tatuya Subject: Re: 6MAN WG Last Call: References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 01:09:54 -0000 On 23/07/2013 12:28, JINMEI Tatuya wrote: > At Thu, 18 Jul 2013 15:11:00 -0700, =2E.. > I think this draft is generally well written and good to be advanced > (although I personally don't have a strong opinion on what's proposed > in the draft). >=20 > I have one comment that may improve the clarity of the document: the > latter half of Section 4 is not very understandable to me: >=20 > There is one case in RFC 4862 that requires additional consideration= : >=20 > "On the other hand, if the duplicate link-local address is not forme= d > from an interface identifier based on the hardware address, which i= s > supposed to be uniquely assigned, IP operation on the interface MAY= > be continued." To be honest, I have great difficulty understanding this sentence, because I can't imagine any case in which continuing operation would be OK. It seems to me that disaster is guaranteed. However, somebody in the WG asked us to discuss this case. > However, as mentioned above, some methods of IID formation might > produce IID values with "u" =3D "g" =3D 0 that are not based on a MA= C > (hardware) address. With very low probability, such a value might > collide with an IID based on a MAC address. There is no algorithm > for determining whether this case has arisen, rather than a genuine > MAC address collision. Implementers should carefully consider the > consequences of continuing IPv6 operation on the interface in this > unlikely situation. >=20 > First, as already noted in this thread, the notation of '"u" =3D "g" =3D= 0' > is confusing and should better be clarified. I guess the intent is > "IID values whose position 6 is 1 and position 7 is 0". But > then...I'm still not really sure what this paragraph tries to > suggest. Is it talking about something like this? >=20 > - A node N creates an IID not based on a MAC address but its position 6= > is 1 and position 7 is 0. > - Node N then creates a link-local address using the IID, and > performs DAD, which detects a duplicate. > - The other address that collides with N's address might be created > from a MAC address (name it "MAC1") > - And, it might also be possible that N's MAC address is actually > MAC1. (So, even if N's IID was not created on that MAC address, the > result would have been the same). > - Since we cannot eliminate this possibility, we should be careful > before continuing IP(v6) operation (as allowed with MAY by RFC 4862, > since this link-local address was "not created based on the MAC > address"). >=20 > If so...I don't see much point in noting that explicitly. That's the intended meaning. As I said, somebody asked us to discuss it. If the WG agrees with you, we can remove it. >=20 > The main intent of this part of RFC 4862 was that if a link-local > address created based on a MAC address is detected to be a duplicate, > that very strongly suggests there's MAC address collision, and it's > better to take some specific action (i.e, disabling the IP operation). > In all other cases, the IP address duplicate may or may not be because > of MAC address collision, and since there's no strong indication of > MAC address collision, RFC 4862 leaves it to the implementor (hence > the MAY). But it doesn't matter. If you have duplicate IIDs, you have unintentionally created a link-local anycast address, whether it's MAC collision or otherwise. Surely there is no way forward? > There's always a possibility that duplicated IP address identified via > DAD is actually because of duplicate MAC address, even if the way of > creating the IID does not directly suggest so. In that sense it > wouldn't be bad to raise consideration on the consequence of > continuing the IP operation after a duplicate address is detected. > But, that doesn't seem to be very specific to the context of the ug > bit discussion. And, recalling the original intent of RFC 4862, > explicitly mentioning the obvious sounds a bit awkward to me and even > tries to update the sense of the RFC. Well yes, I would actually be happier if 4862 said SHOULD NOT instead of MAY, because that requires a good reason to ignore it. But we didn't want to open up 4862. > So, unless that (updating RFC 4862 in addition 4291) is the point of > this paragraph(s), my first suggestion is simply remove it. >=20 > If the intent is to update RFC 4862, I think the draft needs to > explicitly say so. And, at least the description should be clearer > (at least to me it was very difficult to understand what it tries to > say). Sure, if the WG wants to keep this, we will improve the text. Thanks Brian >=20 > --- > JINMEI, Tatuya >=20 > On Thu, Jul 18, 2013 at 3:14 PM, Bob Hinden wrot= e: >> All, >> >> This message starts a two week 6MAN Working Group on advancing: >> >> Title : Transmission of IPv6 Extension Headers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-ietf-6man-ext-transmit-01.txt >> Pages : 9 >> Date : 2013-05-29 >> >> http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 >> >> as a Proposed Standard. Substantive comments and statements of suppor= t for advancing this document should be directed to the mailing list. Ed= itorial suggestions can be sent to the author. This last call will end o= n 1 August 2013. >> >> The chairs would also like to solicit a few people to do a detailed re= view of this document. Please contact the chairs directly. >> >> Regards, >> >> Bob Hinden & Ole Tr=C3=B8an >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From eleven.fuyu@huawei.com Mon Jul 22 19:18:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E40511E81D0 for ; Mon, 22 Jul 2013 19:18:00 -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 jsNfAH690+Pj for ; Mon, 22 Jul 2013 19:17:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8E13A11E819E for ; Mon, 22 Jul 2013 19:17:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVI04370; Tue, 23 Jul 2013 02:17:54 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 03:17:00 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 03:17:52 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.159]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 10:17:47 +0800 From: "Fuyu (Eleven)" To: IPv6 IPv6 List Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOhAO8MGEvOLNDUkeVw85pSE48GJlxjQng Date: Tue, 23 Jul 2013 02:17:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.137] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 02:18:00 -0000 Hi All, I support to move forward this draft. Cheers Yu -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob= Hinden Sent: Friday, July 19, 2013 6:11 AM To: IPv6 IPv6 List Cc: Bob Hinden Subject: 6MAN WG Last Call: All, This message starts a two week 6MAN Working Group on advancing: Title : Significance of IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ug-01.txt Pages : 11 Date : 2013-05-24 http://tools.ietf.org/html/draft-ietf-6man-ug-01 as a Proposed Standard. Substantive comments and statements of support for= advancing this document should be directed to the mailing list. Editorial= suggestions can be sent to the author. This last call will end on 1 Augus= t 2013. The chairs would also like to solicit a few people to do a detailed review = of this document. Please contact the chairs directly. Regards, Bob Hinden & Ole Tr=F8an -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From eleven.fuyu@huawei.com Mon Jul 22 19:21:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F3811E819E for ; Mon, 22 Jul 2013 19:21:34 -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 jE5O4T3uBB-J for ; Mon, 22 Jul 2013 19:21:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4CE11E8183 for ; Mon, 22 Jul 2013 19:21:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR61850; Tue, 23 Jul 2013 02:21:29 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 03:21:19 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 03:21:27 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.159]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 10:21:24 +0800 From: "Fuyu (Eleven)" To: IPv6 IPv6 List Subject: RE: RESEND: 6MAN WG Last Call: Thread-Topic: RESEND: 6MAN WG Last Call: Thread-Index: AQHOhA7szjazLpvtkk+Die/c1T97vplxjZqA Date: Tue, 23 Jul 2013 02:21:23 +0000 Message-ID: References: <111B8370-7FB5-420B-8250-F0D09FBB5BEF@gmail.com> In-Reply-To: <111B8370-7FB5-420B-8250-F0D09FBB5BEF@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.137] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 02:21:34 -0000 Hi WG, Support to move forward. Cheers Yu -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob= Hinden Sent: Friday, July 19, 2013 7:31 AM To: IPv6 IPv6 List Cc: Bob Hinden Subject: RESEND: 6MAN WG Last Call: Wrong file name in the Subject line. Bob ------------- All, This message starts a two week 6MAN Working Group on advancing: Title : Transmission of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ext-transmit-01.txt Pages : 9 Date : 2013-05-29 http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 as a Proposed Standard. Substantive comments and statements of support for= advancing this document should be directed to the mailing list. Editorial= suggestions can be sent to the author. This last call will end on 1 Augus= t 2013. The chairs would also like to solicit a few people to do a detailed review = of this document. Please contact the chairs directly. Regards, Bob Hinden & Ole Tr=F8an -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From markzzzsmith@yahoo.com.au Mon Jul 22 21:11:27 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F52E11E8183 for ; Mon, 22 Jul 2013 21:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kuw+PLMLMVgs for ; Mon, 22 Jul 2013 21:11:22 -0700 (PDT) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with ESMTP id E516011E81DA for ; Mon, 22 Jul 2013 21:11:21 -0700 (PDT) Received: from [98.139.212.148] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jul 2013 04:11:21 -0000 Received: from [98.139.212.219] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jul 2013 04:11:21 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 23 Jul 2013 04:11:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 33353.14705.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 29612 invoked by uid 60001); 23 Jul 2013 04:11:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1374552680; bh=pI/K2qEmssEEsd27XHbiaLpdvArdVkfq+fNm5xyD/hc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JklhNMsjXztGMPVI5Defcbg9KpeJvbMm1YHmQ6SPnnWuyN7+AXALjOu5P06bJdejDbmH8swjDRgwYHLvkODgohnq6roFiszX6PBhdo+8/rxjQAhV3aDFpdrij6aknSAJ3OTUcqaFfJkEHrKDrsp8VB+OHQc5ongdEEG2lhGuQZo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WMNCPBelkcCt58xtwJhpvRN3PwdTxkrTkhup1XCjQT/rlRUAu9ZURhAu4A6PNSjzGfpW2j5L9TqaUvD5H3Vs6b4TqX8EMgB187/7Zu4NSS0p5U//9+WyFqZVEtAhTS/TsbEuzrEPZgxjdQy8aYPKmpPqlquOR8gXj57w1sX+Luo=; X-YMail-OSG: _aHGkBsVM1k_.aLwj_GbnLC5Ee7BXTR.r5IgtL9hxKwKJeL LA2VDQnaJN14KAoesupI_1KemXOm_sxH33m8d2VO2N9tkKJSCRbpxA5avJaJ zqR2I6Msb58EmGf9GVpfI_xbwFdwIoI5l4N9ReqJoGw3u.HyImZJUvcmpWkD ZQE81INCgBwa2G26CzvbhEJi7fJU3ALUtJjSRoLBUGdcnaZui4XphuMr2tC2 UCDlsmZrAvo1HeRJQxhp3S6wn_agHRXnK974f_MrxEkXnDPS.jsaZPOq8ptm MV7JBrbnwWTw86D5AwYBdEF4AsKcQ3eyV49XB7S4vBQ57U2BXvSm3Bf93gaM sPSB8uthzbno7_LuCQsjEirYGjg8tKVYw6kcGpBbLqmnQrtbJ4tsuUpCFzZ2 nX7DWMulbWbjSjr6CWlarcAYg.ENBXO9glTrmPi7MoZUw8anNtOKLLEwMIG. x4Cm.kbeA0G11sIUUkCpRbCAmYWgXYMtNnM02Tz0kHOiCXa4m8u5na.Nd3BO 7U5k3_AFk2Ee6BN.ML0.q_T1ZwH9MorF4sOelD0ZDZqNb0loWi6BCOci2Dh3 zMf7b0skjdsT2BlWrfHIq3k_GqtB61AtGQXGssqK.ZDZ3ZaF553X3tZ8W.wU l.9tC_ZQoZgP1190tmW42IqUPd4Lxdgbuy0E761jSzW26S_68EdHmVFWPpnJ Dug-- Received: from [121.200.231.211] by web142506.mail.bf1.yahoo.com via HTTP; Mon, 22 Jul 2013 21:11:20 PDT X-Rocket-MIMEInfo: 002.001, SGkgQnJpYW4sCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBJUHY2IElQdjYgTGlzdCA8aXB2NkBpZXRmLm9yZz4KPiBTZW50OiBUdWVzZGF5LCAyMyBKdWx5IDIwMTMgODowMCBBTQo.IFN1YmplY3Q6IFJlOiA2TUFOIFdHIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtNm1hbi11Zy0wMS50eHQ.Cj4gCj4gT24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.150.561 References: <1374527534.81451.YahooMailNeo@web142503.mail.bf1.yahoo.com> <51EDAB9B.9010004@gmail.com> Message-ID: <1374552680.28930.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Mon, 22 Jul 2013 21:11:20 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: Brian E Carpenter In-Reply-To: <51EDAB9B.9010004@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 04:11:27 -0000 Hi Brian,=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter = =0A> To: Mark ZZZ Smith =0A> Cc: IPv6 IPv6 List =0A> Sent: Tuesday, 23 July 201= 3 8:00 AM=0A> Subject: Re: 6MAN WG Last Call: = =0A> =0A> On 23/07/2013 09:12, Mark ZZZ Smith wrote:=0A>> Hi,=0A>>=A0=0A= =A0 =0A=A0=0A=0A>> =0A>> "=A0 Also, there is=0A>> =A0 =A0 evidence f= rom the field that IEEE MAC addresses with "u" =3D 0 =0A> are=0A>> =A0 =A0 = sometime incorrectly assigned to multiple MAC interfaces.=A0 Firstly,=0A>> = =A0 =A0 there are recurrent reports of manufacturers assigning the same MAC= =0A>> =A0 =A0 address to multiple devices. Secondly, significant re-use of = the=0A>> =A0 =A0 same virtual MAC address is reported in virtual machine en= vironments. =0A> "=0A>> =0A>> I found this text a bit confusing. The '"u" = =3D 0' term =0A> read like it was referring to locally unique IEEE MAC addr= esses ("unique =0A> equals no"), and then the 2nd sentence is referring to = globally unique (but =0A> duplicated and therefore not actually globally un= ique) MAC addresses, u =3D 1 in =0A> an IPv6 IID, the opposite of what the = previous sentence was referring to. Then =0A> the third sentence seems to b= e describing to what the first sentence was =0A> referring to. I think the = cause of the confusion might be that IEEE use the =0A> "locally assigned" b= it to distinguish locally generated or not (i.e., =0A> "l" =3D 0 for global= ly unique), where as IPv6 IIDs have renamed it to =0A> "u" bit when the val= ue is inverted. I'd suggest trying to ensure =0A> the IEEE terminology is u= sed when IEEE addresses are discussed to make it =0A> clearer what the prop= erties of the IEEE address are.=0A> =0A> Yep. I remember complaining when t= he bit inversion was first proposed=0A> that it would lead to years of conf= usion. Which IEEE standard is the=0A> basic reference for their terminology= ?=0A>=A0=0A=0AI understand the canonical definition of 48-bit universal LAN= MAC addresses is in:=0A=0AIEEE Std 802=AE-2001 -=A0802=AE=A0IEEE Standard = for Local and=A0Metropolitan Area Networks:=A0Overview and Architecture=0A= =0A(http://standards.ieee.org/getieee802/download/802-2001.pdf)=0A=0AFrom p= age 21, it seems what I knew as the "locally assigned" bit is actually the = "Universally or Locally administered (U/L) address bit".=0A=0ARegards,=0AMa= rk.=0A From jinmei@isc.org Mon Jul 22 23:32:52 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3422011E8103 for ; Mon, 22 Jul 2013 23:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.495, 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 jcOa6IMs4wb2 for ; Mon, 22 Jul 2013 23:32:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 371E511E80D1 for ; Mon, 22 Jul 2013 23:32:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B74ADC9427; Tue, 23 Jul 2013 06:32:30 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 23 Jul 2013 06:32:30 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D30DF160239; Tue, 23 Jul 2013 06:35:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QjlZlC-Xos_R; Tue, 23 Jul 2013 06:35:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 88EAF160145; Tue, 23 Jul 2013 06:35:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id I8v3ynufuygd; Tue, 23 Jul 2013 06:35:39 +0000 (UTC) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) by zmx1.isc.org (Postfix) with ESMTPSA id 4E51F160006; Tue, 23 Jul 2013 06:35:39 +0000 (UTC) Date: Mon, 22 Jul 2013 23:32:29 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: In-Reply-To: <51EDD7DE.8080901@gmail.com> References: <51EDD7DE.8080901@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 06:32:52 -0000 At Tue, 23 Jul 2013 13:09:50 +1200, Brian E Carpenter wrote: > > I have one comment that may improve the clarity of the document: the > > latter half of Section 4 is not very understandable to me: > > > > There is one case in RFC 4862 that requires additional consideration: > > > > "On the other hand, if the duplicate link-local address is not formed > > from an interface identifier based on the hardware address, which is > > supposed to be uniquely assigned, IP operation on the interface MAY > > be continued." > > To be honest, I have great difficulty understanding this sentence, > because I can't imagine any case in which continuing operation would > be OK. It seems to me that disaster is guaranteed. However, somebody > in the WG asked us to discuss this case. For example, there may be other, manually assigned address that is unique in the subnet. Or you might assign some once you notice the duplicate. If it's less likely due to MAC address collision, I see it makes some sense (but RFC 4862 does not necessarily recommend it; it just does not prohibit it by saying MAY). (BTW, I noticed the phrase of ", which is supposed to be uniquely assigned," in the above snippet from RFC 4862 may be confusing. I'm not sure how it was inserted, but it's probably a copy-paste error). > > The main intent of this part of RFC 4862 was that if a link-local > > address created based on a MAC address is detected to be a duplicate, > > that very strongly suggests there's MAC address collision, and it's > > better to take some specific action (i.e, disabling the IP operation). > > In all other cases, the IP address duplicate may or may not be because > > of MAC address collision, and since there's no strong indication of > > MAC address collision, RFC 4862 leaves it to the implementor (hence > > the MAY). > > But it doesn't matter. If you have duplicate IIDs, you have > unintentionally created a link-local anycast address, whether it's > MAC collision or otherwise. Surely there is no way forward? See above. Surely there's no way of using that link-local address any more (I believe RFC 4862 is very clear about that). But there can be other reasonable way of recovery from that situation at layer 3 if it's not MAC collision. -- JINMEI, Tatuya From rdroms.ietf@gmail.com Tue Jul 23 01:17:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7659921E804D for ; Tue, 23 Jul 2013 01:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GfoAL6OjxuP for ; Tue, 23 Jul 2013 01:17:36 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 50AD021E8054 for ; Tue, 23 Jul 2013 01:16:43 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ij15so964265vcb.2 for ; Tue, 23 Jul 2013 01:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=twyQawx74J5UX6+BVS0XECKg+LtwqHT5Z820h3YXL1k=; b=IbNyxLqOUyugtUv7NIivCY7yeQXH0l1HPMv3orZwJKMT1HB8JJllDqE3tWesK33QhI TZ9UXBrd51WqvgRh4boul0T0Z378nP5itAaYw+Go2tbuJIBuAdWBnR6SB3KdEY09edWq ND1aAVx4BCtRRh1T1ROjLdhJwuJ86gKZ6IPCUfdsBBxJiI24NxDzrm2uJNHzASjRosFm CkTMBrEWK3hCppKoZLf+YiVbp980M1FnjnzLbSFB1fhGTQvQtczx8M/C7h3SZ78vejUO oeM0LPqYVpVRSW7Cmv7Gwy8MtjtQm8aJwaHuZlOYnQ91RIlHNOFdv95HUs+ZxD0a7wA2 Tq1g== X-Received: by 10.220.98.68 with SMTP id p4mr10633682vcn.28.1374567403302; Tue, 23 Jul 2013 01:16:43 -0700 (PDT) Received: from che-vpn-cluster-2-72.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id ir5sm9707881veb.6.2013.07.23.01.16.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 01:16:42 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: 6MAN WG Last Call: From: Ralph Droms In-Reply-To: Date: Tue, 23 Jul 2013 04:14:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9129C690-16EB-4A84-8CF6-7AB44DB500D1@gmail.com> References: To: Bob Hinden X-Mailer: Apple Mail (2.1508) Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 08:17:41 -0000 I have reviewed the document; in my opinion it is ready to be sent to = the IESG. I suggest that RFC 6775 (6LoWPAN-ND) be mentioned in section 4 along = with draft-ietf-6man-dad-proxy as a way in which "the scope of DAD may = be extended to a set of links." For completeness, RFC 6775 could be = cited along with RFC 4862 in section 1.2. - Ralph On Jul 18, 2013, at 6:11 PM 7/18/13, Bob Hinden = wrote: > All, >=20 > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-01.txt > Pages : 11 > Date : 2013-05-24 >=20 > http://tools.ietf.org/html/draft-ietf-6man-ug-01 >=20 > as a Proposed Standard. Substantive comments and statements of = support for advancing this document should be directed to the mailing = list. Editorial suggestions can be sent to the author. This last call = will end on 1 August 2013. >=20 > The chairs would also like to solicit a few people to do a detailed = review of this document. Please contact the chairs directly. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From gdt@gdt.id.au Tue Jul 23 07:49:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6533311E8265 for ; Tue, 23 Jul 2013 07:49: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 ijmrEKR1sWJM for ; Tue, 23 Jul 2013 07:49:23 -0700 (PDT) Received: from neotokyo.gdt.id.au (neotokyo.adelaide.aarnet.edu.au [IPv6:2001:388:4000:4001:ba27:ebff:fed3:9fa1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF2911E8266 for ; Tue, 23 Jul 2013 07:49:22 -0700 (PDT) Received: from [192.168.255.5] (eth6445.sa.adsl.internode.on.net [150.101.30.44]) by neotokyo.gdt.id.au (Postfix) with ESMTPSA id 6CCC732A005D for ; Wed, 24 Jul 2013 00:19:16 +0930 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Some questions about draft-elkins-6man-ipv6-pdm-dest-option-01 From: Glen Turner In-Reply-To: <65A879E7-8713-4D7C-A16A-17F307EE9977@gmail.com> Date: Wed, 24 Jul 2013 00:19:13 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65A879E7-8713-4D7C-A16A-17F307EE9977@gmail.com> To: IPv6 List X-Mailer: Apple Mail (2.1283) X-Virus-Scanned: clamav-milter 0.97.8 at neotokyo X-Virus-Status: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:49:24 -0000 As I do not attend meetings, perhaps someone at the meeting could ask = the author these questions: 1) > 10 - discard the packet and, regardless of whether or not the > packet's Destination Address was a multicast address, send an ICMP > Parameter Problem, Code 2, message to the packet's Source Address, > pointing to the unrecognized Option Type. > The PDM destination options extension header SHOULD be turned on by > each stack on a host node. Perhaps the Security Considerations section could explain why this = "SHOULD" be enabled feature does not give a way to implement a variation = of the Smurf attack? 2) > As with all other destination options extension headers, the PDM is > for destination nodes only. As specified above, intermediate devices > MUST neither set nor modify this field. Does this "MUST" prevent firewalls stripping the PDM option at the site = network edge? It seems a rather strong requirement that firewalls cannot = do this. Perhaps the intent is that the entire packet be dropped by a = firewall if PDM is undesired by the site's administrators? Maybe the I-D could explain in more detail what an intermediate system = like a firewall is permitted to do with a PDM-containing packet entering = a zone where PDM is not permitted (drop with Admin Prohibit ICMP, etc). 3) > Application Reserved > A 64-bit field reserved for performance and diagnostic metrics to be > used by end nodes. The meaning is agreed upon by the source and > destination nodes. Usual whinge about vendor-defined fields in specifications which are = intended to achieve interoperability. How can we even tell if 64b is = adequate? If justification for the adequacy of 64b remains lacking then = I counter-propose that 0b is adequate. Thank you glen= From brian.e.carpenter@gmail.com Tue Jul 23 13:14:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A4711E811E for ; Tue, 23 Jul 2013 13:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 wDX+DQAK2Mv4 for ; Tue, 23 Jul 2013 13:14:34 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 889A611E82D6 for ; Tue, 23 Jul 2013 13:14:31 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id jh10so926614pab.17 for ; Tue, 23 Jul 2013 13:14:30 -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=kTiwQIxHY9575kmMhaBag2SXpq2lJLXaUyYZWzl/1ws=; b=ptAKuLN/oi5Nt5OkAJwK+z+uOfw28dANbomVEoYqUCgSQ9ss3ReuvKvWb3AemZP8wR gU4cNqwkTw1LUTqcuAPWoXy3Kg/9nZP7oXmNTGTvJGN7dR5mvIqhpEfMLIs2TgGWyqYE /DGSe/yVXORK428PZ4qPFMsR9JcmUzm4eqGpc4yo3lHoau5JjMJptHPUA3j1GysmrX8+ kRCb4z0tNcm4L4p/lesh2wsBaPm3tiYsuvF5iQWMKYRyLXDan6ScC+4T9q0fFemdHSk/ AiX4Ml5TgdIb+0pajXLPWlKqnTkdr08HJUTbVKJ9a3hiO46/XJABNfy7WdGR510csy7j 0whQ== X-Received: by 10.66.162.102 with SMTP id xz6mr40279424pab.0.1374610470285; Tue, 23 Jul 2013 13:14:30 -0700 (PDT) Received: from [192.168.178.23] (93.199.69.111.dynamic.snap.net.nz. [111.69.199.93]) by mx.google.com with ESMTPSA id ep4sm43442155pbd.35.2013.07.23.13.14.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 13:14:28 -0700 (PDT) Message-ID: <51EEE422.5080803@gmail.com> Date: Wed, 24 Jul 2013 08:14:26 +1200 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==?= Subject: Re: 6MAN WG Last Call: References: <51EDD7DE.8080901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 20:14:34 -0000 On 23/07/2013 18:32, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= wrote: > At Tue, 23 Jul 2013 13:09:50 +1200, > Brian E Carpenter wrote: >=20 >>> I have one comment that may improve the clarity of the document: the >>> latter half of Section 4 is not very understandable to me: >>> >>> There is one case in RFC 4862 that requires additional considerati= on: >>> >>> "On the other hand, if the duplicate link-local address is not for= med >>> from an interface identifier based on the hardware address, which= is >>> supposed to be uniquely assigned, IP operation on the interface M= AY >>> be continued." >> To be honest, I have great difficulty understanding this sentence, >> because I can't imagine any case in which continuing operation would >> be OK. It seems to me that disaster is guaranteed. However, somebody >> in the WG asked us to discuss this case. >=20 > For example, there may be other, manually assigned address that is > unique in the subnet. =20 Ah. Now I understand what is intended, but the text needs to say: =2E..IP operation on the interface MAY be continued _using another address that is not a duplicate_. OK, we can clean up the text in the next version. Brian Or you might assign some once you notice the > duplicate. If it's less likely due to MAC address collision, I see it > makes some sense (but RFC 4862 does not necessarily recommend it; it > just does not prohibit it by saying MAY). >=20 > (BTW, I noticed the phrase of ", which is supposed to be uniquely > assigned," in the above snippet from RFC 4862 may be confusing. I'm > not sure how it was inserted, but it's probably a copy-paste error). >=20 >>> The main intent of this part of RFC 4862 was that if a link-local >>> address created based on a MAC address is detected to be a duplicate,= >>> that very strongly suggests there's MAC address collision, and it's >>> better to take some specific action (i.e, disabling the IP operation)= =2E >>> In all other cases, the IP address duplicate may or may not be becaus= e >>> of MAC address collision, and since there's no strong indication of >>> MAC address collision, RFC 4862 leaves it to the implementor (hence >>> the MAY). >> But it doesn't matter. If you have duplicate IIDs, you have >> unintentionally created a link-local anycast address, whether it's >> MAC collision or otherwise. Surely there is no way forward? >=20 > See above. Surely there's no way of using that link-local address any > more (I believe RFC 4862 is very clear about that). But there can be > other reasonable way of recovery from that situation at layer 3 if > it's not MAC collision. >=20 > -- > JINMEI, Tatuya > . >=20 From brian.e.carpenter@gmail.com Tue Jul 23 13:15:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577A611E8399 for ; Tue, 23 Jul 2013 13:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Y2lyIHgtG4v8 for ; Tue, 23 Jul 2013 13:15:33 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 868B211E839A for ; Tue, 23 Jul 2013 13:15:32 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so8758348pad.2 for ; Tue, 23 Jul 2013 13:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sjKVdqCGlgndklHzJ9XTzuKkEFOTQNkjdfeTHiJZPi4=; b=XfEMVn3/s7PVhmC/Dv0ZWpVLQf0ywn3LefgYJh8tZDFLUDPawqCqcpM04iuuYbb9EX g0sPx2K44Y/i/Vmr88rRODkbi9UsK72oAfY9KJXkp3+wOdGQggmSWD+nmXj+hqjPSTh+ TCNXryE65iOU1Shl21pEQ6+OCoJ0C2HSpQpKawzjbA6dA+xRlZDZJjVpQOQZ+4266yTq eOXPbYMKO6ovO5hjmyGjUFR+Ur43oebH5hJAz9HAOBXqvsMm77B6f4WgSywjzzYathUN f6We4mAhTvk2oSslmfqr8JXEQm9FxZlvom/QEtPgA2PD9gwRQ2FAfdyAJeGWncGeT598 TBDg== X-Received: by 10.66.249.202 with SMTP id yw10mr39056453pac.145.1374610532669; Tue, 23 Jul 2013 13:15:32 -0700 (PDT) Received: from [192.168.178.23] (93.199.69.111.dynamic.snap.net.nz. [111.69.199.93]) by mx.google.com with ESMTPSA id ht5sm43460898pbb.29.2013.07.23.13.15.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 13:15:31 -0700 (PDT) Message-ID: <51EEE466.302@gmail.com> Date: Wed, 24 Jul 2013 08:15:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ralph Droms Subject: Re: 6MAN WG Last Call: References: <9129C690-16EB-4A84-8CF6-7AB44DB500D1@gmail.com> In-Reply-To: <9129C690-16EB-4A84-8CF6-7AB44DB500D1@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 20:15:34 -0000 On 23/07/2013 20:14, Ralph Droms wrote: > I have reviewed the document; in my opinion it is ready to be sent to t= he IESG. >=20 > I suggest that RFC 6775 (6LoWPAN-ND) be mentioned in section 4 along wi= th draft-ietf-6man-dad-proxy as a way in which "the scope of DAD may be e= xtended to a set of links." For completeness, RFC 6775 could be cited al= ong with RFC 4862 in section 1.2. Makes sense to me. Brian > - Ralph >=20 > On Jul 18, 2013, at 6:11 PM 7/18/13, Bob Hinden = wrote: >=20 >> All, >> >> This message starts a two week 6MAN Working Group on advancing: >> >> Title : Significance of IPv6 Interface Identifiers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-ietf-6man-ug-01.txt >> Pages : 11 >> Date : 2013-05-24 >> >> http://tools.ietf.org/html/draft-ietf-6man-ug-01 >> >> as a Proposed Standard. Substantive comments and statements of suppor= t for advancing this document should be directed to the mailing list. Ed= itorial suggestions can be sent to the author. This last call will end o= n 1 August 2013. >> >> The chairs would also like to solicit a few people to do a detailed re= view of this document. Please contact the chairs directly. >> >> Regards, >> >> Bob Hinden & Ole Tr=C3=B8an >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From jtatuya@infoblox.com Tue Jul 23 17:21:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE7911E81A4 for ; Tue, 23 Jul 2013 17:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wNL0oG0aVAwB for ; Tue, 23 Jul 2013 17:21:24 -0700 (PDT) Received: from mx2.infoblox.com (mx2.infoblox.com [205.234.19.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF5F11E819A for ; Tue, 23 Jul 2013 17:21:24 -0700 (PDT) X-ASG-Debug-ID: 1374625282-0640d710c98c31a0001-WbpaHM Received: from x2008hub1.infoblox.com (x2008hub1.infoblox.com [205.234.19.248]) by mx2.infoblox.com with ESMTP id sUNttyC7E9FC012Z; Tue, 23 Jul 2013 17:21:22 -0700 (PDT) X-Barracuda-Envelope-From: jtatuya@infoblox.com X-Barracuda-Apparent-Source-IP: 205.234.19.248 Received: from jinmei-mbp.infoblox.com (10.102.29.200) by x2008hub1.infoblox.com (10.120.3.105) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 23 Jul 2013 17:21:22 -0700 Date: Tue, 23 Jul 2013 17:21:10 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Subject: comments on draft-droms-6man-multicast-scopes-00.txt User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) X-ASG-Orig-Subj: comments on draft-droms-6man-multicast-scopes-00.txt MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [10.102.29.200] X-Barracuda-Connect: x2008hub1.infoblox.com[205.234.19.248] X-Barracuda-Start-Time: 1374625282 X-Barracuda-URL: http://205.234.19.214:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at infoblox.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.137262 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 00:22:15 -0000 I have a couple of comments on the draft: - I think the draft explains the motivation of introducing the new scope. It will also help understand the vague term of the "Network-Specific" scope, or "defined automatically from the network topology". I've checked the ML archive and understood it's related to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-04 But I suspect it's quite difficult to figure it out just from the generic description of the draft. - You might want to explicitly note that this new scope is smaller than the Admin (or Site or Organization) -Local scope and that if the administrator configures an Admin/Site/Organization-Local scope zone for a network, that zone must not be separated by a Network-Specific scope zone per the scoped address architecture (RFC 4007). This restriction is not specific to this particular relationship, but since the Network-Specific scope (seems) dynamic and self defined while Admin/Site/Organization-Local scopes are always defined manually, I guess it'll be more likely to cause accidental violation. -- JINMEI, Tatuya Infoblox Inc. From rdroms.ietf@gmail.com Wed Jul 24 00:19:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669B721F9C12 for ; Wed, 24 Jul 2013 00:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.903 X-Spam-Level: X-Spam-Status: No, score=-100.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXaEucmxTNYz for ; Wed, 24 Jul 2013 00:19:01 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD311E80E2 for ; Wed, 24 Jul 2013 00:19:01 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it19so18437bkc.41 for ; Wed, 24 Jul 2013 00:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=G7qcrEElDiE8QBDm11uH/YHs3EWaqK3POjqc3nonpe4=; b=U3iHRLeYWS+A+d2NooEF7LBtRakGWeYb532e+aDH3is4BxFkyTIWo8rFcACAdkneE1 gk0iEBiVzSmdKZ3ymXxAejNvrVnbl2YoHFx3ynQD8B6zaqUnia47kxGHrrqCdsHU42X9 VIURZzwFlot4Uz6FNlpOgI8dwwPEQBTWPGPOdgppo+Ir6AONPoHABqWrCNq0XaO+ye4p dRByBMxTrtNZ4ZGGo6rKDKpS6FEG364q46+BWO2NoTjuQS9lvYqn8bpQaJWVmZcFKO0p 4z/4PWUvUiPJz8DObRwKrxLDBy26poJeWsJKrh7eYw+Wn15f+JIQtolKApbZ51UJZyba 3qUA== X-Received: by 10.204.226.75 with SMTP id iv11mr5269420bkb.136.1374650340594; Wed, 24 Jul 2013 00:19:00 -0700 (PDT) Received: from [141.89.87.39] ([141.89.87.39]) by mx.google.com with ESMTPSA id cb7sm9197272bkb.16.2013.07.24.00.18.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 00:19:00 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <78E65FA0-9381-4867-B845-EB3D798BB3EB@gmail.com> X-Mailer: iPad Mail (9B206) From: Ralph Droms Subject: Re: comments on draft-droms-6man-multicast-scopes-00.txt Date: Wed, 24 Jul 2013 09:19:15 +0200 To: =?utf-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Cc: "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 07:19:02 -0000 Jinmei-san - thanks for your review... On Jul 24, 2013, at 2:21 AM, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: > I have a couple of comments on the draft: >=20 > - I think the draft explains the motivation of introducing the new > scope. It will also help understand the vague term of the > "Network-Specific" scope, or "defined automatically from the network > topology". I've checked the ML archive and understood it's related > to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-04 > But I suspect it's quite difficult to figure it out just from the > generic description of the draft. The lack of direct connection between draft-ietf-roll-trickle-mcast and this= document is intentional. The purpose of the definition of Network-Specific= scope is to allow the use of that scope by draft-ietf-roll-trickle-mcast, a= s well as other use cases. > - You might want to explicitly note that this new scope is smaller > than the Admin (or Site or Organization) -Local scope and that if > the administrator configures an Admin/Site/Organization-Local scope > zone for a network, that zone must not be separated by a > Network-Specific scope zone per the scoped address architecture (RFC > 4007). This restriction is not specific to this particular > relationship, but since the Network-Specific scope (seems) dynamic > and self defined while Admin/Site/Organization-Local scopes are > always defined manually, I guess it'll be more likely to cause > accidental violation. Agreed. I'll add some explanatory text to the next rev. - Ralph >=20 > -- > JINMEI, Tatuya > Infoblox Inc. From robert.cragie@gridmerge.com Tue Jul 23 10:44:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA3511E8302; Tue, 23 Jul 2013 10:44:35 -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 nJOTUAxOJVBA; Tue, 23 Jul 2013 10:44:30 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 37D8011E82AF; Tue, 23 Jul 2013 10:44:23 -0700 (PDT) Received: from [94.116.234.145] (helo=[10.38.244.130]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1V1gdI-0008PP-K4; Tue, 23 Jul 2013 18:44:20 +0100 Message-ID: <51EEC0F2.9010601@gridmerge.com> Date: Tue, 23 Jul 2013 18:44:18 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> In-Reply-To: <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000608020202000309080200" X-Authenticated-As: robert.cragie@gridmerge.com X-Mailman-Approved-At: Wed, 24 Jul 2013 01:38:54 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 17:44:35 -0000 This is a cryptographically signed message in MIME format. --------------ms000608020202000309080200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 So "subnet" is not the right term. I think "network" as Ralph wrote is=20 fine but if the disassociation with network addressing needs to be=20 clear, why not use the term "domain"? After all, trickle-mcast talks=20 about MPL Domains. I appreciate it may have some pre-established=20 connotations but from an abstract definition point of view, "domain"=20 seems eligible enough. Robert On 16/07/2013 23:59, Ralph Droms wrote: > This draft is on the 6man agenda for Berlin. I expect the discussion w= ill be taken up there. > > In my opinion, the multicast scope should not be tied, thought the word= s in the description of the scope, to the address assignment architecture= =2E > > - Ralph > > On Jul 16, 2013, at 1:41 PM, "Pascal Thubert (pthubert)" wrote: > >> Hi: >> >>>> "subnet" implies that this multicast scope must derive from the addr= ess >>>> assignment topology. The first (and only) use case is derived from = the >>>> /64 prefix; do we want to have that limitation for all uses of scope= >>>> 0x03? >>> I think so. >> Same here. >> >> Pascal >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------ms000608020202000309080200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA3MjMxNzQ0MThaMCMGCSqGSIb3DQEJBDEWBBSUDHkvqvNcHkXFEJTMTIlCx4vwuTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAGYpedAy18TdlgHCl9Xhv4JNAczqYT13D9bXw8fG4nVNfdUj wwaMERObooDnqu4N51HKhvg6ePn3Hnk4IgTdJWJcx5+2cWyxIrVK1uWwxjKGU48zZPuFtXEr DSLHUJVrSXBqdVFdyhfO8t1xE6DLy8o+scs85hucdORhG92gBWO0yuNbgta/fcXAQ71N6UXk 9KmXvi/judfxweDe2FS/AJg/zUJ3qg5Rf/Frq5dsLmMbBxC5xyskSspvTeFMMT/A8bCkPVLX DKiuI2P1HKnVEGUc/zpJm8gpLkzdDk7ct2i0RSzM3CB4t76zzHiFWwwippPbzxsW0mVY7Lno MpyWt9YAAAAAAAA= --------------ms000608020202000309080200-- From markzzzsmith@yahoo.com.au Wed Jul 24 02:38:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3FE11E83C5 for ; Wed, 24 Jul 2013 02:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xaVFCqH8g+7 for ; Wed, 24 Jul 2013 02:38:27 -0700 (PDT) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7CD11E8156 for <6man@ietf.org>; Wed, 24 Jul 2013 02:38:27 -0700 (PDT) Received: from [98.139.215.140] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 09:38:27 -0000 Received: from [98.139.212.238] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 09:38:27 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 09:38:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 40937.64361.bm@omp1047.mail.bf1.yahoo.com Received: (qmail 1174 invoked by uid 60001); 24 Jul 2013 09:38:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1374658706; bh=1kwvI8xOMyYEjME4ZBHguE5DF0n/XyDXKU9V15B4qtQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=E9b8paDSUYmKq5GfR+yn5r4bpXT0nqJVf4KtyZ2ETw+ZyQROFhuI4NnjyKRhTrtCwTxD+rG5ZWa6yqwEZ2R2/6H2AtJPD5Ta5RT8USa/M2XH0pJxFxd68xONHpPp0GmiSR+IZMPoG5SYOLQGl6HuFxVLLRjGAJtBHQQUwkAU4vU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RIqwakPU9Ad0apreJbsRmC9O/5pJVmMG6Zh4q2cCVopbzrLsUPICPMp4/QxYwfB2N7gXxjg2tYBbFPGLoOBReq6Uqjy0Hi0cHdmnLQEDzdLxJFOr2EgQVVEjRqfdq98K2bNx4k6Yj1Ho9alWKKoCKhCEtBH/TZ5t4IKqTxZCX1E=; X-YMail-OSG: SA97DToVM1kdHSqZYjropeWEY7AkFVvWLbYiiCH2SCXj309 Mx2PCEpNyfkdqjAtCtImaAjOTXh2iDEOaYlPMbXeYMUWBwRxP17jS6nxJxRw YHV6_axg6Jahm1UIx0A0YdvyzHFZckkVGudxmIznrZt22Xcx.GKwUY3QE3gN 3Poby152z_YBsrLZdEOzNOSIZMxKGQDvbvMe0QDgOxTscxp5t4ZyoH7BM3je ca3ewRqS1p.Eh42rhvnu_IKkvB48KSZznyLyT2mdH3y3UE1CMrBMux1ZfjnH 5yU98SFuwpVVBEDsqQ8FJcdLEetscGFeyMo4NDzjd2eymqaUw1HC24QSu67A R1L7rzPBwdeLiuNh0e_wDXBSU_zQiR_1mS9W7plt6R7nkwaj9OtRFw6sgekU ktnE8c8Y7j22IY8VQafh5oGEKOSZLINq3yja2GeBPqgfCI4te04MIyVal9v5 kvi_1_5zbXM.6ltMtJbZdpJWIyvIy6ZR_zOr2Cj6SzCEUfkh2uY7JTAfEU0I g6KA6MCI0n9RlrJV6T6PSsqL09RJAFpjBRu4T9GvIwjlI9IQlWHIFWv8NSzm JJnU6XO64 Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Wed, 24 Jul 2013 02:38:26 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBSb2JlcnQgQ3JhZ2llIDxyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20.Cj4gVG86IHJvbGxAaWV0Zi5vcmc7IDZtYW5AaWV0Zi5vcmcKPiBDYzogCj4gU2VudDogV2VkbmVzZGF5LCAyNCBKdWx5IDIwMTMgMzo0NCBBTQo.IFN1YmplY3Q6IFJlOiBbUm9sbF0gdHJpY2tsZS1tY2FzdC0wNCAtIENsYXJpZnkgc2NvcGUgdmFsdWUgb2YgMyAtCXN1Ym5ldC1sb2NhbAo.IAo.ICsxCj4gCj4gU28gInN1Ym5ldCIgaXMgbm90IHRoZSByaWdodCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.150.561 References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> Message-ID: <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Wed, 24 Jul 2013 02:38:26 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local To: "robert.cragie@gridmerge.com" , "roll@ietf.org" , "6man@ietf.org" <6man@ietf.org> In-Reply-To: <51EEC0F2.9010601@gridmerge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:38:32 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Robert Cragie =0A> To: roll@ietf.org; 6man@ietf.org=0A> Cc: =0A> Sent:= Wednesday, 24 July 2013 3:44 AM=0A> Subject: Re: [Roll] trickle-mcast-04 -= Clarify scope value of 3 -=09subnet-local=0A> =0A> +1=0A> =0A> So "subnet"= is not the right term. I think "network" as =0A> Ralph wrote is =0A> fine = but if the disassociation with network addressing needs to be =0A> clear, w= hy not use the term "domain"? After all, trickle-mcast talks =0A> about MPL= Domains. I appreciate it may have some pre-established =0A> connotations b= ut from an abstract definition point of view, "domain" =0A> seems eligible = enough.=0A>=A0=0A=0AI think "domain" is really good when there is a qualifi= er on the front e.g., addressing domain, routing domain, multicast domain e= tc.=0A=0ARegards,=0AMark.=0A=0A> Robert=0A> =0A> On 16/07/2013 23:59, Ralph= Droms wrote:=0A>> This draft is on the 6man agenda for Berlin.=A0 I expec= t the discussion will =0A> be taken up there.=0A>> =0A>> In my opinion, th= e multicast scope should not be tied, thought the words in =0A> the descrip= tion of the scope, to the address assignment architecture.=0A>> =0A>> - Ra= lph=0A>> =0A>> On Jul 16, 2013, at 1:41 PM, "Pascal Thubert (pthubert)" = =0A> wrote:=0A>> =0A>>> Hi:=0A>>> =0A>>>>> "subnet" = implies that this multicast scope must =0A> derive from the address=0A>>>>>= assignment topology.=A0 The first (and only) use case is derived =0A> fro= m the=0A>>>>> /64 prefix; do we want to have that limitation for all uses = of =0A> scope=0A>>>>> 0x03?=0A>>>> I think so.=0A>>> Same here.=0A>>> = =0A>>> Pascal=0A>>> _______________________________________________=0A>>>= Roll mailing list=0A>>> Roll@ietf.org=0A>>> https://www.ietf.org/mailma= n/listinfo/roll=0A>> _______________________________________________=0A>> = Roll mailing list=0A>> Roll@ietf.org=0A>> https://www.ietf.org/mailman/l= istinfo/roll=0A>> =0A> =0A> =0A> ------------------------------------------= --------------------------=0A> IETF IPv6 working group mailing list=0A> ipv= 6@ietf.org=0A> Administrative Requests: https://www.ietf.org/mailman/listin= fo/ipv6=0A> ---------------------------------------------------------------= -----=0A> From bjones@vt.edu Wed Jul 24 07:45:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794611E8218 for ; Wed, 24 Jul 2013 07:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxeKICwpKTUo for ; Wed, 24 Jul 2013 07:45:54 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietfa.amsl.com (Postfix) with ESMTP id 4962711E80F4 for ; Wed, 24 Jul 2013 07:45:54 -0700 (PDT) Received: from steiner.cc.vt.edu (steiner.cc.vt.edu [198.82.163.51]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r6OEdGKE017161 for ; Wed, 24 Jul 2013 10:44:35 -0400 Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by steiner.cc.vt.edu (MOS 4.3.3-GA) with ESMTP id YHZ01450; Wed, 24 Jul 2013 10:44:34 -0400 X-Mirapoint-Received-SPF: 209.85.128.41 mail-qe0-f41.google.com 0 softfail Received: by mail-qe0-f41.google.com with SMTP id b4so5481938qen.0 for ; Wed, 24 Jul 2013 07:44:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Z5JV6QLe0vjGwilUszWj4imrB3Jo07h+y5uw3FaRy6w=; b=YJ+baw0P6zTT2f5fJb7bQn0kl92YX8z7I4MyZAJVlEOTNKXvshRuDO9X3F1Ox1BGqY qrhnJq/Bg9yc0nBhAyhYpxsjHhGp8VDKDc4tukY5SGmMvPPOrfrZJzfMfx0XKqjZ7pYn UBn+Bag6cPBlV5ulRcVnzILnu1CFAmi9sCilrkOOZxcRQi5zFbXad1ILZ6nfl1Rh+x62 +brWBVw8io2i9/arehg9DxIOmLjEuxo57HkJF0EE+jTVk/FWjmGxomVRT6kjQwMA5P3v 3V0SVQHF8CysHhRXACIFs+3fcAp7vdiK0RLyctO5XR2zK/YKvT+LYnPslurODg6cMKLu M0Uw== X-Received: by 10.224.2.194 with SMTP id 2mr30653823qak.40.1374677073564; Wed, 24 Jul 2013 07:44:33 -0700 (PDT) X-Received: by 10.224.2.194 with SMTP id 2mr30653815qak.40.1374677073502; Wed, 24 Jul 2013 07:44:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.197 with HTTP; Wed, 24 Jul 2013 07:44:13 -0700 (PDT) In-Reply-To: <111B8370-7FB5-420B-8250-F0D09FBB5BEF@gmail.com> References: <111B8370-7FB5-420B-8250-F0D09FBB5BEF@gmail.com> From: Brian Jones Date: Wed, 24 Jul 2013 10:44:13 -0400 Message-ID: Subject: Re: RESEND: 6MAN WG Last Call: To: IPv6 IPv6 List Content-Type: multipart/alternative; boundary=001a11c3e092a5aa6004e242f2d3 X-Gm-Message-State: ALoCoQmiMdMCORjfpnGWHNdnUzGRVANTSaqbbS90uLPzjZkZRZSegsooIMlXi4ci23UFF24NrnFghaNLkYH7oSIVBNvw8VjmC6udpOj1WEJuLrdGGtjkC6sSoern7tjhg6Tmmqcar9rP Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:46:00 -0000 --001a11c3e092a5aa6004e242f2d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support advancing the proposal. -- Brian On Thu, Jul 18, 2013 at 7:31 PM, Bob Hinden wrote: > Wrong file name in the Subject line. > > Bob > > ------------- > > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Transmission of IPv6 Extension Headers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ext-transmit-01.txt > Pages : 9 > Date : 2013-05-29 > > http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 > > as a Proposed Standard. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will en= d > on 1 August 2013. > > The chairs would also like to solicit a few people to do a detailed revie= w > of this document. Please contact the chairs directly. > > Regards, > > Bob Hinden & Ole Tr=C3=B8an > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11c3e092a5aa6004e242f2d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support advancing the proposal.
--
Brian

On Thu, Jul 18, 2013 at 7:31 PM, Bob Hinden <bob.= hinden@gmail.com> wrote:
Wrong file name in the Subject line.

Bob

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

All,

This message starts a two week 6MAN Working Group on advancing:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Tran= smission of IPv6 Extension Headers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Brian Carpente= r
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Sheng Jiang
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-6man-ext-transmit-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 9 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2013-05-29

=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/draft-i= etf-6man-ext-transmit-01

as a Proposed Standard. =C2=A0Substantive comments and statements of suppor= t for advancing this document should be directed to the mailing list. =C2= =A0Editorial suggestions can be sent to the author. =C2=A0This last call wi= ll end on 1 August 2013.

The chairs would also like to solicit a few people to do a detailed review = of this document. =C2=A0Please contact the chairs directly.

Regards,

Bob Hinden & Ole Tr=C3=B8an


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

--001a11c3e092a5aa6004e242f2d3-- From mcr@sandelman.ca Wed Jul 24 08:00:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7878711E81DD; Wed, 24 Jul 2013 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0HET2TBfDR5; Wed, 24 Jul 2013 08:00:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id C993511E80DF; Wed, 24 Jul 2013 08:00:23 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0AABD2018E; Wed, 24 Jul 2013 12:05:31 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3F9BD63A88; Wed, 24 Jul 2013 10:58:29 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3075963A7C; Wed, 24 Jul 2013 10:58:29 -0400 (EDT) From: Michael Richardson To: "roll\@ietf.org" , "6man\@ietf.org" <6man@ietf.org> Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 15:00:47 -0000 --=-=-= I would still like an explanation of why "subnet" is the wrong term. When would scope-3 would be used such that it would not correspond to the set of links on which a "/64" (or other size) is used? -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUe/rkoqHRg3pndX9AQKFFwQAo6ZkpF8ov/YeNlBRPQqBufd6NZ5NPd0r 5v18wjVf6vsveeFRnVJ2NurO72XEg5RY7mEFOKkAuqklIwt6CTaHw9/KnX76YEHF gELgHKxA44mx/k66PY8PVE08edTD75RLhZwou5he8GCLEOW6K4rppdykbUd6L9Gc kxnQyROTJ1E= =dLgC -----END PGP SIGNATURE----- --=-=-=-- From rdroms@cisco.com Wed Jul 24 08:23:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB3411E8210; Wed, 24 Jul 2013 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb9o56midTSA; Wed, 24 Jul 2013 08:21:50 -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 6046311E820E; Wed, 24 Jul 2013 08:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=819; q=dns/txt; s=iport; t=1374679277; x=1375888877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DjKF8aF7UF90BbwUfILFU6T9mxa6oS8FX8suHm4UPxk=; b=ONoTQx8wpk/DW9tlxu8ZTzuk4ntk/uN051DEc9G9hemZVaEekLe4B42r qCwBq/zQaZZx2uPmfn/8qmCAuvzn/wt8/IlWfQCn6KhIDn/PQyD4tK04Q sqqiexx76x+ogb7dmqc3a5RU3JFi5jd7PgSYvjGYMNNlRbl3+kclhJXeX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAPjv71GtJXG8/2dsb2JhbABbgwaBBYJCvkCBFhZ0giQBAQEDATo/EAIBCCIUEDIlAgQOBQiIAga5RY9KAjEHgxJuA6ksgxSCKg X-IronPort-AV: E=Sophos;i="4.89,736,1367971200"; d="scan'208";a="238828476" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jul 2013 15:21:16 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6OFLGVx016698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 15:21:16 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.242]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 10:21:16 -0500 From: "Ralph Droms (rdroms)" To: Michael Richardson Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Topic: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOfnvAE0hdpuPffU2KL5nISCt1Apll6o6AgA4VXjqAAFnNgA== Date: Wed, 24 Jul 2013 15:21:16 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> In-Reply-To: <18208.1374677909@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <949CA0B7DF4902489178894EC8FFAA48@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 15:23:01 -0000 On Jul 24, 2013, at 4:58 PM 7/24/13, Michael Richardson wrote: >=20 > I would still like an explanation of why "subnet" is the wrong term. >=20 > When would scope-3 would be used such that it would not correspond to the= set > of links on which a "/64" (or other size) is used? Hm, I thought I responded but apparently not... This change to scope 0x03 is not just for MPL, so we don't know how else it= might be used in the future. Specific examples: 1) two adjacent RPL domains, which do not share a prefix but are to be cons= idered as one realm for mDNS 2) one RPL domain and one other non-RPL subnet that are to be considered as= one realm for mDNS - Ralph >=20 > -- > Michael Richardson , Sandelman Software Works >=20 >=20 From jinmei@isc.org Wed Jul 24 09:27:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D0D11E8142 for ; Wed, 24 Jul 2013 09:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.248, 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 4n7ZqXz6bPtb for ; Wed, 24 Jul 2013 09:26: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 E685611E80EA for ; Wed, 24 Jul 2013 09:26:37 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BC059C94DC; Wed, 24 Jul 2013 16:26:09 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 24 Jul 2013 16:26:09 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0E0C3160197; Wed, 24 Jul 2013 16:29:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1foeiVzAVToU; Wed, 24 Jul 2013 16:29:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C48AC160255; Wed, 24 Jul 2013 16:29:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PrOAl-wXaJvy; Wed, 24 Jul 2013 16:29:24 +0000 (UTC) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) by zmx1.isc.org (Postfix) with ESMTPSA id 8B8AD160197; Wed, 24 Jul 2013 16:29:24 +0000 (UTC) Date: Wed, 24 Jul 2013 09:26:08 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ralph Droms Subject: Re: comments on draft-droms-6man-multicast-scopes-00.txt In-Reply-To: <78E65FA0-9381-4867-B845-EB3D798BB3EB@gmail.com> References: <78E65FA0-9381-4867-B845-EB3D798BB3EB@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist Cc: "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:27:31 -0000 At Wed, 24 Jul 2013 09:19:15 +0200, Ralph Droms wrote: > > I have a couple of comments on the draft: > > > > - I think the draft explains the motivation of introducing the new (I meant "the draft should explain...") > > scope. It will also help understand the vague term of the > > "Network-Specific" scope, or "defined automatically from the network > > topology". I've checked the ML archive and understood it's related > > to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-04 > > But I suspect it's quite difficult to figure it out just from the > > generic description of the draft. > > The lack of direct connection between draft-ietf-roll-trickle-mcast > and this document is intentional. The purpose of the definition of > Network-Specific scope is to allow the use of that scope by > draft-ietf-roll-trickle-mcast, as well as other use cases. I see you want to keep the scope document not too specific. But in its current form, the concept of "network specific" is too vague and I'm afraid it's reader-unfriendly (in fact I couldn't understand the idea just from this draft and ended up digging into the ML archive). I don't think it too restrictive if we show one specific example of the intended usage with a note that reads "but the use of this scope is not limited to this case; in terms of the scope definition it can be used for any other usage as long as it meets other architectural constraints". But I wouldn't strongly argue for that. It's just a suggestion. -- JINMEI, Tatuya From jouni.nospam@gmail.com Wed Jul 24 09:31:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFCD11E80EA for ; Wed, 24 Jul 2013 09:31:56 -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 9yRxwCVw0GrL for ; Wed, 24 Jul 2013 09:31:56 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1892B11E80D3 for ; Wed, 24 Jul 2013 09:31:55 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm19so175176bkc.30 for ; Wed, 24 Jul 2013 09:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=49+aS8mwjn7C5yU0aTleFK9zetmWNVdqrOTb+0QgllE=; b=MjmyIKZ7R3acSUXpa5LhxqQufaac0tBv3bT4HuFluZrewk/3WoXvFOoKP/3VPkkJIn PEDwkfYwXyETVhXNtVeysn3SWTGSpHD0chNMz/zMKUXbv3lQegJcChr87jjJ5CVSfS5c 1GGjpEU6SN0mWmJWM9t0kiTyvRfn9aMt3G5ovLUaVoUvfRY9urqC//A8JbIGLpiIxuEk o7eFpDTcSi2PG4yjBMJEkd5WXFNl95E2NSrWajP2aB9A7Qf1K3jtx/1UfpULdnbfUXTB SkutIQLZkATMGjMs+nbqdsOI8lVyK6KHC2sljCxf3nnNtmsyVfgheDCS57KBQ00kIP2X k93g== X-Received: by 10.204.185.76 with SMTP id cn12mr5594946bkb.113.1374683515049; Wed, 24 Jul 2013 09:31:55 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ok9sm9892101bkb.8.2013.07.24.09.31.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 09:31:53 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: 6MAN WG Last Call: From: Jouni Korhonen In-Reply-To: Date: Wed, 24 Jul 2013 19:31:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9ADA1F39-5DCF-4257-9193-EAA8CD29795A@gmail.com> References: To: IPv6 IPv6 List X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:31:57 -0000 I think the document is ready to go. Good that we finally can close the eternal u & g bit mess. For the open issue in Section 7. I am also in favour of retaining the reserved IID registry. Then one or two nits. In Section 5. where changes to RFC4291 are listed I wonder why those new pieces of text do not use RFC2119 language. I recon RFC4291 does not use RFC2119 language but still this is going to be a new RFC that itself refers and uses RFC2119 language. - Jouni=09 On Jul 19, 2013, at 1:11 AM, Bob Hinden wrote: > All, >=20 > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-01.txt > Pages : 11 > Date : 2013-05-24 >=20 > http://tools.ietf.org/html/draft-ietf-6man-ug-01 >=20 > as a Proposed Standard. Substantive comments and statements of = support for advancing this document should be directed to the mailing = list. Editorial suggestions can be sent to the author. This last call = will end on 1 August 2013. >=20 > The chairs would also like to solicit a few people to do a detailed = review of this document. Please contact the chairs directly. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From mcr@sandelman.ca Wed Jul 24 09:39:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D13411E80FE; Wed, 24 Jul 2013 09:39: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 w7Fsqd6l2u7e; Wed, 24 Jul 2013 09:39:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 6656121F854E; Wed, 24 Jul 2013 09:39:13 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 00A502018F; Wed, 24 Jul 2013 13:44:47 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E7CF363A88; Wed, 24 Jul 2013 12:37:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D61D463A7C; Wed, 24 Jul 2013 12:37:44 -0400 (EDT) From: Michael Richardson To: "Ralph Droms \(rdroms\)" Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "roll@ietf.org" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:39:18 -0000 --=-=-= Ralph Droms (rdroms) wrote: >> I would still like an explanation of why "subnet" is the wrong term. >> >> When would scope-3 would be used such that it would not correspond to the set >> of links on which a "/64" (or other size) is used? > Hm, I thought I responded but apparently not... > This change to scope 0x03 is not just for MPL, so we don't know how > else it might be used in the future. I understand, but perhaps it would be better, if, when another use case comes along, they write a document explaining why scope-3 is correct and non-conflicting with the trickle mcast use case. > Specific examples: > 1) two adjacent RPL domains, which do not share a prefix but are to be > considered as one realm for mDNS I accept that this is a plausible scenario, but I believe that it presupposes a technical answer from the not-yet occured sdnsext BOF. sDNSext could well mandate a proxy solution where actual multicast packets do not cross that boundary. > 2) one RPL domain and one other non-RPL subnet that are to be considered as one realm for mDNS Do you mean, in fact, one LLN and another non-LLN technology, which have MPL capable routers connecting them? I write it this way, because I think that there is a belief that RPL can only be used in LLNs, while the RPL architecture is very specifically for multiple link types, and I find it hard to imagine an MPL capable router which does not also speak RPL. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfAC1oqHRg3pndX9AQLlfgP/dvg8MPKdXPSX5gJKg9kl+lxx7G2A+nXT WkvpfoTXmg/PHe0fnosf0095Vz+oj1KP1obC4Lge6KQuJvkMKQeOGysqsK+gUZjr xwyrjzoNkzSi869vDLizZEzXXwQUBEMZAFWE0lETY0y1JEzGi+QCDAKb1ukLkpa/ 6LFhvXWFaKU= =f9fm -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Wed Jul 24 09:49:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F0011E8115 for ; Wed, 24 Jul 2013 09:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVdD7KIW9kWX for ; Wed, 24 Jul 2013 09:49:48 -0700 (PDT) Received: from nm18-vm8.access.bullet.mail.bf1.yahoo.com (nm18-vm8.access.bullet.mail.bf1.yahoo.com [216.109.115.87]) by ietfa.amsl.com (Postfix) with ESMTP id C111211E8105 for <6man@ietf.org>; Wed, 24 Jul 2013 09:49:47 -0700 (PDT) Received: from [66.196.81.166] by nm18.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 16:49:46 -0000 Received: from [98.139.221.48] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 16:49:46 -0000 Received: from [127.0.0.1] by smtp101.sbc.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 16:49:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374684586; bh=837pIVGUCeynIYw+sY4b2aCQycSdaBoQ8w2cFyNwouM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=rAHiXb5Xji407V1Ji5WPBRy41cPtEFZcrROQarXKLM2n3S0q73JOqdlS7CmObGDQp4TPEfqOLVuxIY2djqIi0SufI5TTbpg0yGF48tgcwvM+TMss9nEVhp1+27weJvDvMXemGUw1dc2edaQOo34rCkaNEvkB/tv6ubIFrVZlB8o= X-Yahoo-Newman-Id: 355961.70657.bm@smtp101.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: wSnMoykVM1k7AZvCoWEE4DiGFXHhowTpUfgZheECLUHnuu1 b3jXrCeKtWNTlBDwBuAuDUoopxHVgJfW8THb_PyWUfZpE2iasdZmvAiisuRd JXoMaXfuThUrqSL3_HWBQcpE3dA4OXQoekm3ODVASL7I881bmjvCy3dcsVgq DZ9gxrUDjioHNZ_yk.pvIYR_G2j8tSaew79FmDKlUlzN54ZYzSJ0LQQfYL5k x280UsM18CjP91YeqXbZNZlg4mepr9A2rCi1E5clz.CpJ0ePOGGEh2qZ35r_ mBtZ0CLcY5q5hnNhi0HcD.QUS_pJfcIUmbCvkX1XPItFy44OI2eLzozfDIOp hPlJewUXquKCDCzTfzdoBK0enRL2D1C3PkzjbMedmwjQDk1.Kcc_EsEpWOCm x9Z5P9wKUOU7s.NpjRw8sSLKuGU37fm.MKpqtgOyUu65S7iyXGrJ9pkcB5l8 QX0kpugylhnA.LRTa6B5tG0STlmSdGD4FUYe_TleWawrNMGEAZOJn0KiAFjw mx1X_psd3vmm2eCyc_A-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.129] (d.sturek@66.27.60.174 with login) by smtp101.sbc.mail.bf1.yahoo.com with SMTP; 24 Jul 2013 09:49:46 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Wed, 24 Jul 2013 09:49:42 -0700 Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org>, Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:49:53 -0000 Hi Ulrich, I did review the you cited in your earlier e-mail (RFC 5889). It seems that RFC suggests that link local addresses not be generated for interfaces with undetermined link characteristics (which certainly apply to route over protocols like ROLL RPL and the MANET protocols). However, in looking 6LoWPAN ND (RFC 6775), isn't assignment of link local addresses to such a topology exactly what is going on? If you add ROLL RPL (RFC 655) to this deployment scenario and specifcally with the illustrative examples in Annex A, it seems clear that a multi-hop subnet is exactly what is described. Next, if someone were to want to support a protocol like mDNS (RFC 6792) which uses link locals, how could that be supported using RFC 5889? I think these are important topics as we seemed to have to go to extremes in our work (ZigBee IP) to deal with ULAs when it would have been great if link locals were available in the context of a route over protocol like ROLL RPL. Don On 7/24/13 8:32 AM, "Ulrich Herberg" wrote: >I have pointed out two documents in my earlier email that explain in >long detail why I believe that multi-hop subnets are a really bad >idea. The AUTOCONF RFC 5889 presents an architecture for avoiding all >these problems by using /128 prefixes. In that regards, a subnet wide >flooding would be fairly uninteresting, as it would not go beyond a >single router. > >Regards >Ulrich > >On Wed, Jul 24, 2013 at 7:58 AM, Michael Richardson > wrote: >> >> I would still like an explanation of why "subnet" is the wrong term. >> >> When would scope-3 would be used such that it would not correspond to >>the set >> of links on which a "/64" (or other size) is used? >> >> -- >> Michael Richardson , Sandelman Software Works >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From tjc@ecs.soton.ac.uk Wed Jul 24 10:30:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD1C11E8220; Wed, 24 Jul 2013 10:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 s05GUltp9-9I; Wed, 24 Jul 2013 10:30:25 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D211E819E; Wed, 24 Jul 2013 10:30:25 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6OHUKgZ004593; Wed, 24 Jul 2013 18:30:20 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r6OHUKgZ004593 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1374687020; bh=uS35M5Ew+UuVGZXcAkXiihgsxOo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=sBZblnGdOzhTKcvxMcGYho0UdEPhycxRWpu3FRqWGU6WcA1qvt/pYZP22xIdUXYmY WxR2I55IOeNTOkZoinfTyskSq0i6xhhK+rUszPcWXAmMIJrkLmWJAsVAhrVuvq8W++ ptEeyQc/lT1tukY5xilLAGqj61W+5x0XnYP3Mneo= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p6NIUK0544549066q0 ret-id none; Wed, 24 Jul 2013 18:30:20 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6OHT15c020291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jul 2013 18:29:02 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_17964996-AEC1-4470-BC02-B89F832EB38D" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: New draft - draft-lepape-6man-prefix-metadata-00 From: Tim Chown In-Reply-To: Date: Wed, 24 Jul 2013 18:29:04 +0100 Message-ID: References: <6097B6BC-2013-4327-9FDF-DAAEA826A3D7@ecs.soton.ac.uk> To: Shwetha Bhandari (shwethab) X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p6NIUK054454906600; tid=p6NIUK0544549066q0; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r6OHUKgZ004593 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "'ian.farrer@telekom.de'" , homenet , "6man@ietf.org" <6man@ietf.org>, "draft-bhandari-dhc-class-based-prefix@tools.ietf.org" , "draft-korhonen-6man-prefix-properties@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:30:26 -0000 --Apple-Mail=_17964996-AEC1-4470-BC02-B89F832EB38D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Jul 2013, at 10:01, Shwetha Bhandari (shwethab) = wrote: > Hello, >=20 > A new draft draft-lepape-6man-prefix-metadata-00 describing=20 > a method for applications to learn and influence source address = selection by associating > IPv6 prefixes with meta-data when configured by > the network is submitted. Motivation to do this and details of a = prototype that has been developed are included. Related drafts that = define DHCPv6 and ND options to realize > conveying of meta-data associated with a prefix are = draft-bhandari-dhc-class-based-prefix > and=20 > draft-korhonen-6man-prefix-properties. > Motivation for doing this work is relevant to homenet hence adding = homenet wg. Hi Swetha, You may want to have a look at draft-anipko-mif-mpvd-arch-00, if you = ahven't already, which is work from a design team in the mif WG. Section = 4.2.2 is very relevant. The "metadata" could also be provisioning = domain information, perhaps. Tim >=20 > On 7/15/13 8:52 PM, "internet-drafts@ietf.org" = wrote: >=20 >>=20 >> A new version of I-D, draft-lepape-6man-prefix-metadata-00.txt >> has been successfully submitted by Maico Le Pape and posted to the >> IETF repository. >>=20 >> Filename: draft-lepape-6man-prefix-metadata >> Revision: 00 >> Title: IPv6 Prefix Meta-data and Usage >> Creation date: 2013-07-15 >> Group: Individual Submission >> Number of pages: 16 >> URL: = http://www.ietf.org/internet-drafts/draft-lepape-6man-prefix-metadata-00.t= xt >> Status: = http://datatracker.ietf.org/doc/draft-lepape-6man-prefix-metadata >> Htmlized: = http://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00 >>=20 >>=20 >> Abstract: >> This document presents a method for applications to influence the >> IPv6 source selection algorithm used by the IP stack in a host. = To >> do so, IPv6 prefixes are associated with meta-data when configured = by >> the network. This meta-data allows the network to describe the >> purpose and properties of the prefix enabling applications to make >> intelligent decision when selecting a prefix. >>=20 >>=20 >> = =20 >>=20 >>=20 >> The IETF Secretariat >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_17964996-AEC1-4470-BC02-B89F832EB38D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 22 Jul 2013, at 10:01, Shwetha Bhandari (shwethab) <shwethab@cisco.com> wrote:

Hello,

A new draft draft-lepape-6man-prefix-metadata-00  describing a method for applications to learn and influence source address selection by associating IPv6 prefixes with meta-data when configured by the network is submitted. Motivation to do this and details of a prototype that has been developed are included. Related drafts that define DHCPv6 and ND options to realize conveying of meta-data associated with a prefix are draft-bhandari-dhc-class-based-prefix and draft-korhonen-6man-prefix-properties. Motivation for doing this work is relevant to homenet hence adding homenet wg.

Hi Swetha,

You may want to have a look at draft-anipko-mif-mpvd-arch-00, if you ahven't already, which is work from a design team in the mif WG. Section 4.2.2 is very relevant.  The "metadata" could also be provisioning domain information, perhaps.

Tim

On 7/15/13 8:52 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:


A new version of I-D, draft-lepape-6man-prefix-metadata-00.txt
has been successfully submitted by Maico Le Pape and posted to the
IETF repository.

Filename:     draft-lepape-6man-prefix-metadata
Revision:     00
Title:         IPv6 Prefix Meta-data and Usage
Creation date:     2013-07-15
Group:         Individual Submission
Number of pages: 16


Abstract:
   This document presents a method for applications to influence the
   IPv6 source selection algorithm used by the IP stack in a host.  To
   do so, IPv6 prefixes are associated with meta-data when configured by
   the network.  This meta-data allows the network to describe the
   purpose and properties of the prefix enabling applications to make
   intelligent decision when selecting a prefix.


                                                                                  


The IETF Secretariat

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

--Apple-Mail=_17964996-AEC1-4470-BC02-B89F832EB38D-- From brian.e.carpenter@gmail.com Wed Jul 24 13:07:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B4911E8146 for ; Wed, 24 Jul 2013 13:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 l5l1JjxHIlbn for ; Wed, 24 Jul 2013 13:07:16 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3501511E80D5 for ; Wed, 24 Jul 2013 13:07:13 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so792300pdj.17 for ; Wed, 24 Jul 2013 13:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uj9PS7GhhmFkDhf6qVfqwlSpq23tQTgB35y0hb78S4o=; b=vlQXHUxY+ejW7iMqq32O44b9oup0UVnG6lFkXVA9HnYTMXfnBCayPVgcggoWVvG7Vz PMQuKLz8BnFxQvQbMVzX+xDClfEU9xc19uLBO27WuMt8KnLIiQXsGpn0vPBRwL6SsvS4 +avHqHXkHlRUvnUdAEIrPLZAYpY3TrXd1uen8/VoweJMkl68FHVfMWbR4JRPp8WLZFxS PAbbpdnwhyQSz0TLCSXaMHCUTUw7Ki9qr4Fo8JMVGwsRjHhbjXPVUyknXuwiWyFrMp7j VmOU4zT/ug70WE4KqoxgTzMhlHh7CpKwwGVf7oTP+bqwQW72QKe/Ve9XKiQ/gmEPr+Xc WvVw== X-Received: by 10.68.200.104 with SMTP id jr8mr44450004pbc.43.1374696430559; Wed, 24 Jul 2013 13:07:10 -0700 (PDT) Received: from [192.168.178.23] (16.197.69.111.dynamic.snap.net.nz. [111.69.197.16]) by mx.google.com with ESMTPSA id nj9sm5134148pbc.13.2013.07.24.13.07.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 13:07:09 -0700 (PDT) Message-ID: <51F033F3.3070509@gmail.com> Date: Thu, 25 Jul 2013 08:07:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jouni Korhonen Subject: Re: 6MAN WG Last Call: References: <9ADA1F39-5DCF-4257-9193-EAA8CD29795A@gmail.com> In-Reply-To: <9ADA1F39-5DCF-4257-9193-EAA8CD29795A@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bob Hinden , IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 20:07:17 -0000 On 25/07/2013 04:31, Jouni Korhonen wrote: > I think the document is ready to go. Good that we finally can > close the eternal u & g bit mess. >=20 > For the open issue in Section 7. I am also in favour > of retaining the reserved IID registry. >=20 > Then one or two nits. In Section 5. where changes to RFC4291 are > listed I wonder why those new pieces of text do not use RFC2119 > language. I recon RFC4291 does not use RFC2119 language but still > this is going to be a new RFC that itself refers and uses RFC2119 > language. That was intentional so that if you read a "virtual" 4291bis including these wording changes you do not find upper-case keywords but no citation of 2119. I think it's more logical this way. Thanks Brian >=20 > - Jouni=09 >=20 >=20 >=20 >=20 > On Jul 19, 2013, at 1:11 AM, Bob Hinden wrote: >=20 >> All, >> >> This message starts a two week 6MAN Working Group on advancing: >> >> Title : Significance of IPv6 Interface Identifiers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-ietf-6man-ug-01.txt >> Pages : 11 >> Date : 2013-05-24 >> >> http://tools.ietf.org/html/draft-ietf-6man-ug-01 >> >> as a Proposed Standard. Substantive comments and statements of suppor= t for advancing this document should be directed to the mailing list. Ed= itorial suggestions can be sent to the author. This last call will end o= n 1 August 2013. >> >> The chairs would also like to solicit a few people to do a detailed re= view of this document. Please contact the chairs directly. >> >> Regards, >> >> Bob Hinden & Ole Tr=C3=B8an >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From jouni.nospam@gmail.com Thu Jul 25 00:43:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E81121F99D0 for ; Thu, 25 Jul 2013 00:43:41 -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 b+1WuuW5vSX8 for ; Thu, 25 Jul 2013 00:43:40 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9B42521F9360 for ; Thu, 25 Jul 2013 00:43:39 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so1104157lab.13 for ; Thu, 25 Jul 2013 00:43: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:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dUIG6ztM1mS1HpEWoThjzYbnnPtQJKQlW2rlDWn2QBY=; b=xPuQlZvqidowVQco0MwP3+wuZoGub9/HNwVf/5PCQq0pVsTJVeXwrlhIaPXNViHpR2 64YGUfME3MwfCmP0dF/EhOdy5VUdp0fL3+jCoxKtZpd6kmMBhjvd0fBEz0MYMezqRexl bmfzcRCm3Vy70SLdf+FdmvIyhwPx90qlNvYWqmV9rwPy8bhhdbiJqRTPOoXx4G+SpDDj v4yrTzzVbUlqngaCZAvMeskgypdRQtxMW8/sKzhllGQQQe0lVFk+mOeqlqaxruANCw7C WwXU4lNYGW2oGJEWUzO3wphAT2E4Mk7n6xV+hw4kbCJvKmN36CBGkskL1pOHF/zLh5eD u0sg== X-Received: by 10.152.44.170 with SMTP id f10mr18289977lam.68.1374738218576; Thu, 25 Jul 2013 00:43:38 -0700 (PDT) Received: from [192.168.250.152] ([194.100.71.98]) by mx.google.com with ESMTPSA id w9sm15901940lbk.7.2013.07.25.00.43.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 00:43:35 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: 6MAN WG Last Call: From: Jouni Korhonen In-Reply-To: <51F033F3.3070509@gmail.com> Date: Thu, 25 Jul 2013 10:43:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <674FB9E7-342C-49DA-99CE-4F53F34BDA7E@gmail.com> References: <9ADA1F39-5DCF-4257-9193-EAA8CD29795A@gmail.com> <51F033F3.3070509@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden , IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:43:41 -0000 On Jul 24, 2013, at 11:07 PM, Brian E Carpenter = wrote: > On 25/07/2013 04:31, Jouni Korhonen wrote: >> I think the document is ready to go. Good that we finally can >> close the eternal u & g bit mess. >>=20 >> For the open issue in Section 7. I am also in favour >> of retaining the reserved IID registry. >>=20 >> Then one or two nits. In Section 5. where changes to RFC4291 are >> listed I wonder why those new pieces of text do not use RFC2119 >> language. I recon RFC4291 does not use RFC2119 language but still >> this is going to be a new RFC that itself refers and uses RFC2119 >> language. >=20 > That was intentional so that if you read a "virtual" 4291bis including > these wording changes you do not find upper-case keywords but no > citation of 2119. I think it's more logical this way. Sounds plausible to me. - Jouni >=20 > Thanks > Brian >=20 >=20 >>=20 >> - Jouni=09 >>=20 >>=20 >>=20 >>=20 >> On Jul 19, 2013, at 1:11 AM, Bob Hinden wrote: >>=20 >>> All, >>>=20 >>> This message starts a two week 6MAN Working Group on advancing: >>>=20 >>> Title : Significance of IPv6 Interface Identifiers >>> Author(s) : Brian Carpenter >>> Sheng Jiang >>> Filename : draft-ietf-6man-ug-01.txt >>> Pages : 11 >>> Date : 2013-05-24 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-6man-ug-01 >>>=20 >>> as a Proposed Standard. Substantive comments and statements of = support for advancing this document should be directed to the mailing = list. Editorial suggestions can be sent to the author. This last call = will end on 1 August 2013. >>>=20 >>> The chairs would also like to solicit a few people to do a detailed = review of this document. Please contact the chairs directly. >>>=20 >>> Regards, >>>=20 >>> Bob Hinden & Ole Tr=F8an >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 From rdroms@cisco.com Thu Jul 25 02:14:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1019A21F9AE3; Thu, 25 Jul 2013 02:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb1ww0kFMcaN; Thu, 25 Jul 2013 02:14:05 -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 5D1B021F9AD8; Thu, 25 Jul 2013 02:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1968; q=dns/txt; s=iport; t=1374743645; x=1375953245; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EWqOEWPT8m1HE1rbQlBcdmj9yaTyYPOeaif4d4ObRKk=; b=FIaw0asWVdX+BdJNCcJkboG1GS+/Cgz9X7lerjeli+bhfDfotSmMlb5T 5SKMu4+3U3gz0XCwonsF71ucYdHjrLFnLI8QrxY1/+uHqilG1xSGEhrBt j9hcsF100ctG+mGgCvSLiqB+emGiNJbgBryO9zf3/KTCRq1Qs9/psDgGZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAOrr8FGtJV2b/2dsb2JhbABagwaBBb1dgRgWdIIkAQEBAwE6PxACAQgSBgoUEDIXDgIEDgUIE4dvBrocj0oCMQeDEm4DqSyDFIIq X-IronPort-AV: E=Sophos;i="4.89,742,1367971200"; d="scan'208";a="239286703" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jul 2013 09:14:05 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6P9E4RY031721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 09:14:04 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.242]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 04:13:54 -0500 From: "Ralph Droms (rdroms)" To: Michael Richardson Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Topic: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOfnvAE0hdpuPffU2KL5nISCt1Apll6o6AgA4VXjqAAFnNgIAAFV8AgAEWUoA= Date: Thu, 25 Jul 2013 09:13:53 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA37BFCF7@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> <1177.1374683864@sandelman.ca> In-Reply-To: <1177.1374683864@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.148] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A4594E4499FEB48BBD8395F27B7687B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org Lossy networks Over Low power and" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 09:14:11 -0000 Michael... On Jul 24, 2013, at 6:37 PM 7/24/13, Michael Richardson wrote: >=20 > Ralph Droms (rdroms) wrote: >>> I would still like an explanation of why "subnet" is the wrong term. >>>=20 >>> When would scope-3 would be used such that it would not correspond to t= he set >>> of links on which a "/64" (or other size) is used? >=20 >> Hm, I thought I responded but apparently not... >=20 >> This change to scope 0x03 is not just for MPL, so we don't know how >> else it might be used in the future. >=20 > I understand, but perhaps it would be better, if, when another use case c= omes > along, they write a document explaining why scope-3 is correct and > non-conflicting with the trickle mcast use case. I don't agree; in my opinion, it's better to release scope 0x03 from "reser= ved" state and give guidelines for its use. Let's see how 6man WG consensus develops... - Ralph >=20 >> Specific examples: >> 1) two adjacent RPL domains, which do not share a prefix but are to be >> considered as one realm for mDNS >=20 > I accept that this is a plausible scenario, but I believe that it > presupposes a technical answer from the not-yet occured sdnsext BOF. > sDNSext could well mandate a proxy solution where actual multicast packet= s do > not cross that boundary. >=20 >> 2) one RPL domain and one other non-RPL subnet that are to be considered= as one realm for mDNS >=20 > Do you mean, in fact, one LLN and another non-LLN technology, which have = MPL > capable routers connecting them? >=20 > I write it this way, because I think that there is a belief that RPL can = only > be used in LLNs, while the RPL architecture is very specifically for mult= iple > link types, and I find it hard to imagine an MPL capable router which doe= s > not also speak RPL. >=20 > -- > Michael Richardson , Sandelman Software Works >=20 >=20 From ulrich@herberg.name Wed Jul 24 08:32:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0831B11E8151 for ; Wed, 24 Jul 2013 08:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwcS46p33rXo for ; Wed, 24 Jul 2013 08:32:15 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 16C1211E80DF for <6man@ietf.org>; Wed, 24 Jul 2013 08:32:15 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx1so513730pab.41 for <6man@ietf.org>; Wed, 24 Jul 2013 08:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IG5d/3CZ2j3v+ValzltHFpaRHB5crTsNFowG/tA8zgg=; b=Lf8pvvRLT39fznRLNNloiEzqsUhJrULV4XlDGHo24qSMuDYWxX5AZw9ZvZXivXnq0h 5Nm9goLBHuu4bTOX7yT/DE1qh7ZHuvYMgi1QlhrRgNmvyhuAaF+I0kpKx3903vjP7lah fmPHhXBEfFPdAdqFNdAX1dLYu8SW2SU4kVlrQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=IG5d/3CZ2j3v+ValzltHFpaRHB5crTsNFowG/tA8zgg=; b=oJtnheIyauc4c4xL0FoFuRq3zooqxSc5eMg5vayCUU09FCorPE1QvVSULPAa1WH6cl sHUYT0VCTiROoxk8nvLnUu/pA1Wz4uYKcpvrY4cAKbdE3czszVZcxYdmObEnnb3kUDC1 Dz6Q/EOUOpDLqcyiY+vfi1em0d2VULjx/pJxLzw7ynLqZXkkay+bjOr2919QBXcpM2NJ ygZnPx1my4IcedHuiGbnAix0sgHqVLoauuiqw+BHi1w2bgAv4rUmhc/3xy7ySfG3oi4u o0YCrWiwWtRQJGxQWwTyHMrtR/GaZAob/NdnAjV+tt2wVJRKDsXHHZYrdypVmH67wZEn eVCQ== MIME-Version: 1.0 X-Received: by 10.68.231.200 with SMTP id ti8mr42778555pbc.46.1374679934765; Wed, 24 Jul 2013 08:32:14 -0700 (PDT) Received: by 10.70.34.111 with HTTP; Wed, 24 Jul 2013 08:32:14 -0700 (PDT) In-Reply-To: <18208.1374677909@sandelman.ca> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> Date: Wed, 24 Jul 2013 08:32:14 -0700 Message-ID: Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local From: Ulrich Herberg To: Routing Over Low power and Lossy networks Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmIACvuN414L7HQBmR70qYRFQTm66jzCUoHPB51RkuqDY1afFbvT0zm81MBtj9LqPEHD9+l X-Mailman-Approved-At: Thu, 25 Jul 2013 02:18:06 -0700 Cc: "6man@ietf.org" <6man@ietf.org>, Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 15:32:16 -0000 I have pointed out two documents in my earlier email that explain in long detail why I believe that multi-hop subnets are a really bad idea. The AUTOCONF RFC 5889 presents an architecture for avoiding all these problems by using /128 prefixes. In that regards, a subnet wide flooding would be fairly uninteresting, as it would not go beyond a single router. Regards Ulrich On Wed, Jul 24, 2013 at 7:58 AM, Michael Richardson wrote: > > I would still like an explanation of why "subnet" is the wrong term. > > When would scope-3 would be used such that it would not correspond to the set > of links on which a "/64" (or other size) is used? > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From rdroms.ietf@gmail.com Thu Jul 25 02:39:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94D21F9ABA for ; Thu, 25 Jul 2013 02:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 ARTyJYnzDPWw for ; Thu, 25 Jul 2013 02:39:32 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F194E21F9AB3 for ; Thu, 25 Jul 2013 02:39:31 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id p14so333379vbm.18 for ; Thu, 25 Jul 2013 02:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9VHMX3w9aOLIevc/DTXC64Pd7fbygl5m46tzh7o6Zso=; b=fiEYD1IYVAe2Zbb+njhEJW+YJFiuB13l8u2xlcC+hsqjNqOkhd1PMFkFdNhBQp/Q9L 4EudDCzieyXGWUjdOUakx4zMq1jCwnqkr/gDN8a/oD8l7B7evpwvfRbratcUEYKTXnnJ cR+qORfZ5R9+D+G5M9Ino4kPa8T++xjHoupyAoL2SHpNycWpEdT+6YwCwVeeRX+3+6qn p2bWT+1ltGq26lrEsgEDoYcg7QG7wf/uR4LohXBVm1bJJuxRt2UNPkrOj0DTxlIFuC15 sDm+7FDF3f9yFpefpLcZo6QWMcX6M4PGpXX4nyWS6pK7jDelRYMRx8TRLxi9CFIctzH8 zkpA== X-Received: by 10.52.188.73 with SMTP id fy9mr14687780vdc.53.1374745169995; Thu, 25 Jul 2013 02:39:29 -0700 (PDT) Received: from che-vpn-cluster-2-148.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id p5sm17329328vek.1.2013.07.25.02.39.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 02:39:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: comments on draft-droms-6man-multicast-scopes-00.txt From: Ralph Droms In-Reply-To: Date: Thu, 25 Jul 2013 11:39:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78E65FA0-9381-4867-B845-EB3D798BB3EB@gmail.com> To: =?utf-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.1508) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 09:39:32 -0000 On Jul 24, 2013, at 6:26 PM 7/24/13, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9= =81=94=E5=93=89 wrote: > At Wed, 24 Jul 2013 09:19:15 +0200, > Ralph Droms wrote: >=20 >>> I have a couple of comments on the draft: >>>=20 >>> - I think the draft explains the motivation of introducing the new >=20 > (I meant "the draft should explain...") >=20 >>> scope. It will also help understand the vague term of the >>> "Network-Specific" scope, or "defined automatically from the network >>> topology". I've checked the ML archive and understood it's related >>> to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-04 >>> But I suspect it's quite difficult to figure it out just from the >>> generic description of the draft. >>=20 >> The lack of direct connection between draft-ietf-roll-trickle-mcast >> and this document is intentional. The purpose of the definition of >> Network-Specific scope is to allow the use of that scope by >> draft-ietf-roll-trickle-mcast, as well as other use cases. >=20 > I see you want to keep the scope document not too specific. But in > its current form, the concept of "network specific" is too vague and > I'm afraid it's reader-unfriendly (in fact I couldn't understand the > idea just from this draft and ended up digging into the ML archive). > I don't think it too restrictive if we show one specific example of > the intended usage with a note that reads "but the use of this scope > is not limited to this case; in terms of the scope definition it can > be used for any other usage as long as it meets other architectural > constraints". >=20 > But I wouldn't strongly argue for that. It's just a suggestion. Sounds like a good suggestion to me. I have no objection to adding such = text, if there is WG consensus for the change... - Ralph >=20 > -- > JINMEI, Tatuya From tjc@ecs.soton.ac.uk Thu Jul 25 02:46:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C7121F9AD2 for ; Thu, 25 Jul 2013 02:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR0WpUYCDFXy for ; Thu, 25 Jul 2013 02:46:43 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3F76621F9ADA for ; Thu, 25 Jul 2013 02:46:37 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6P9kZnB020544; Thu, 25 Jul 2013 10:46:35 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r6P9kZnB020544 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1374745595; bh=aAIy8ddqpU6Qs6cdVxEOEryltzs=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=cKQ6KbF0uZKuvMbCCLIrROnsV5slyoycWEk3NEfyA04ywOV5f0FAupfubWRmJ916N AD/WWgO81sFUCYYjsQvtuumzY2df3PA0Mvs4gGGaA2qwuVGnUth+Jb6vdT/JF0Oo9i uZjGQa/AMv41QDiKY4LU7F7lruAQkvC1KUpMHEf4= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p6OAkZ05445562143K ret-id none; Thu, 25 Jul 2013 10:46:35 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6P9kSJx023199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 10:46:28 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: comments on draft-droms-6man-multicast-scopes-00.txt From: Tim Chown In-Reply-To: Date: Thu, 25 Jul 2013 10:46:28 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <78E65FA0-9381-4867-B845-EB3D798BB3EB@gmail.com> <3AAA73C3-6454-4241-A8CF-76AD92AC6909@ecs.soton.ac.uk> To: Ralph Droms X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p6OAkZ054455621400; tid=p6OAkZ05445562143K; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r6P9kZnB020544 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 09:46:44 -0000 On 25 Jul 2013, at 10:39, Ralph Droms wrote: >=20 > On Jul 24, 2013, at 6:26 PM 7/24/13, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9= =81=94=E5=93=89 wrote: >=20 >> At Wed, 24 Jul 2013 09:19:15 +0200, >> Ralph Droms wrote: >>=20 >>>> I have a couple of comments on the draft: >>>>=20 >>>> - I think the draft explains the motivation of introducing the new >>=20 >> (I meant "the draft should explain...") >>=20 >>>> scope. It will also help understand the vague term of the >>>> "Network-Specific" scope, or "defined automatically from the = network >>>> topology". I've checked the ML archive and understood it's related >>>> to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-04 >>>> But I suspect it's quite difficult to figure it out just from the >>>> generic description of the draft. >>>=20 >>> The lack of direct connection between draft-ietf-roll-trickle-mcast >>> and this document is intentional. The purpose of the definition of >>> Network-Specific scope is to allow the use of that scope by >>> draft-ietf-roll-trickle-mcast, as well as other use cases. >>=20 >> I see you want to keep the scope document not too specific. But in >> its current form, the concept of "network specific" is too vague and >> I'm afraid it's reader-unfriendly (in fact I couldn't understand the >> idea just from this draft and ended up digging into the ML archive). >> I don't think it too restrictive if we show one specific example of >> the intended usage with a note that reads "but the use of this scope >> is not limited to this case; in terms of the scope definition it can >> be used for any other usage as long as it meets other architectural >> constraints". >>=20 >> But I wouldn't strongly argue for that. It's just a suggestion. >=20 > Sounds like a good suggestion to me. I have no objection to adding = such text, if there is WG consensus for the change... I think the suggested change would enhance the text. Tim >=20 > - Ralph >=20 >>=20 >> -- >> JINMEI, Tatuya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From mcr@sandelman.ca Thu Jul 25 07:08:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8C621F8C72; Thu, 25 Jul 2013 07:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5TXmLQeqt1J; Thu, 25 Jul 2013 07:08:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 359D321F9A4C; Thu, 25 Jul 2013 07:08:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0D7DE20256; Thu, 25 Jul 2013 11:14:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 63BC163A88; Thu, 25 Jul 2013 10:07:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4E30763A7C; Thu, 25 Jul 2013 10:07:05 -0400 (EDT) From: Michael Richardson To: "Ralph Droms \(rdroms\)" Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA37BFCF7@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> <1177.1374683864@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BFCF7@xmb-aln-x04.cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "roll@ietf.org Lossy networks Over Low power and" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:08:29 -0000 --=-=-= Ralph Droms (rdroms) wrote: >> Ralph Droms (rdroms) wrote: >>>> I would still like an explanation of why "subnet" is the wrong term. >>>> >>>> When would scope-3 would be used such that it would not correspond to the set >>>> of links on which a "/64" (or other size) is used? >> >>> Hm, I thought I responded but apparently not... >> >>> This change to scope 0x03 is not just for MPL, so we don't know how >>> else it might be used in the future. >> >> I understand, but perhaps it would be better, if, when another use case comes >> along, they write a document explaining why scope-3 is correct and >> non-conflicting with the trickle mcast use case. > I don't agree; in my opinion, it's better to release scope 0x03 from > "reserved" state and give guidelines for its use. I think that we agree about what we want. What I see you saying is that you want a definition which I find rather (technically) vague, in anticipation of uses which are not yet well defined, and may never come to pass. I'm saying, let's make the MPL scope-3 use case clear and precise, and if another situation comes along for which scope-3 is appropriate, let's extend the definition at that time. Otherwise, this reminds of site-local scope: We defined it in what we thought were clear terms for a human, but which turned out to be too vague for machines, with the result that it could never be discovered/used. Meanwhile, I think that MPL is hung up waiting for this to be properly clarified. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfExBoqHRg3pndX9AQIlrAQA4PvbkBgxY7iGDzzJtuuvuF2juvPWYk0H aNnQPucW+RG2wHOfTIPBhA3T3JlLiXDK2WVYpaC5Dg/t+mSkuJ8UUds6ORkdYgPf 9JcTmg/SJqMzpvUtaSdqSmWjOo/Ilm62CFJEkydNzLhn3wEA5BKenPAcYY8qQH4A P3nTvsQNTew= =9CEv -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Jul 25 07:20:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B930821F9AB4; Thu, 25 Jul 2013 07:20:38 -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.159, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh+csYR1wkcQ; Thu, 25 Jul 2013 07:20:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 41B0321F99BF; Thu, 25 Jul 2013 07:20:34 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2205820256; Thu, 25 Jul 2013 11:26:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 71E9B63A88; Thu, 25 Jul 2013 10:19:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5D41163A7C; Thu, 25 Jul 2013 10:19:13 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <202e77ad4286b74c606d04de997bd996@xs4all.nl> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> <1177.1374683864@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BFCF7@xmb-aln-x04.cisco.com> <202e77ad4286b74c606d04de997bd996@xs4all.nl> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: roll@ietf.org, 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:20:41 -0000 --=-=-= It is important to keep the 6man CC, since the document is a 6man document. I will top-post your entire comments for 6man, but then copy them again and comment. > For me RFC 1136 was quite clarifying. > It states that the Internet subnet term is ambiguous > - It refers to one-hop IP connectivity > - it refers to address hierarchy Please recognize that RFC1136 is from an era prior to classless domain routing. Subnetting in that period of time referred to taking a class-ful route ("class A", "class B", "class C") and further dividing it within an AS. RFC1136 also predates BGP4, and therefore even the term AS is not used. Further, it's a translation from OSI to IETF terminology. > IMO, routing domain is nicely defined in RFC 1136. > an adminsitrative domain can contain one or more routing domains. In the internet today, one has Autonomous Systems (AS), identified by AS Numbers in BGP4. The terms routing domain and administrative domains are not also very precise today. For ISPs, an administrative domain may correspond to the convex set of all networks that announce using the same ASN. Some ISPs have non-convex parts of their networks, and use multiple ASNs. A routing domain might be said to be akin to an OSPF area, which is typically a subset of an ASN. (In particular, the convex nature of BGP4 means that an AS needs to have full connectivity within) > I translate a mesh subnet running RPL as a routing domain > while an adminstrative domain can contain several interconnected RPL domains I don't think use of these terms helps define scope-3 at all. peter van der Stok wrote: > For me RFC 1136 was quite clarifying. > It states that the Internet subnet term is ambiguous > - It refers to one-hop IP connectivity > - it refers to address hierarchy > RFC 1136 defines the adminsitrative domain and the routing domain > IMO, routing domain is nicely defined in RFC 1136. > an adminsitrative domain can contain one or more routing domains. > I translate a mesh subnet running RPL as a routing domain > while an adminstrative domain can contain several interconnected RPL domains > For the latter I understood we want to use scope-3 to run for example service > discovery. > and in our case multicast to multiple devices where the network topology is > motivated by history, and organizational and physical constraints. > Any mistakes in the above? > Peter > Ralph Droms (rdroms) schreef op 2013-07-25 11:13: >> Michael... >> >> On Jul 24, 2013, at 6:37 PM 7/24/13, Michael Richardson >> wrote: >> >> >> Ralph Droms (rdroms) wrote: >> I would still like an explanation of why "subnet" is the wrong term. >> >> When would scope-3 would be used such that it would not correspond to the >> set >> of links on which a "/64" (or other size) is used? >> >> Hm, I thought I responded but apparently not... >> >> This change to scope 0x03 is not just for MPL, so we don't know how >> else it might be used in the future. >> >> I understand, but perhaps it would be better, if, when another use case >> comes >> along, they write a document explaining why scope-3 is correct and >> non-conflicting with the trickle mcast use case. >> >> I don't agree; in my opinion, it's better to release scope 0x03 from >> "reserved" state and give guidelines for its use. >> >> Let's see how 6man WG consensus develops... >> >> - Ralph >> >> >> Specific examples: >> 1) two adjacent RPL domains, which do not share a prefix but are to be >> considered as one realm for mDNS >> >> I accept that this is a plausible scenario, but I believe that it >> presupposes a technical answer from the not-yet occured sdnsext BOF. >> sDNSext could well mandate a proxy solution where actual multicast packets >> do >> not cross that boundary. >> >> 2) one RPL domain and one other non-RPL subnet that are to be considered as >> one realm for mDNS >> >> Do you mean, in fact, one LLN and another non-LLN technology, which have >> MPL >> capable routers connecting them? >> >> I write it this way, because I think that there is a belief that RPL can >> only >> be used in LLNs, while the RPL architecture is very specifically for >> multiple >> link types, and I find it hard to imagine an MPL capable router which does >> not also speak RPL. >> >> -- >> Michael Richardson , Sandelman Software Works >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfEz3oqHRg3pndX9AQJT3wQA3r35vkrJCFn/MIUkFzuN9TClpP/tOIT3 f3OQ0IyEAxNSbayR31rVxGOM4oA7vNaTFpJYVpQXpGejomXDUfcJiLuOtpAOP6au 7Ujkr8oEPYxCGbYUjEK2K0msJySF+e3Tko3C2G18t7vnmBTuXe8Eas1VTRot1TJp 7wShu4dQqHI= =AGZx -----END PGP SIGNATURE----- --=-=-=-- From rdroms@cisco.com Thu Jul 25 07:47:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8CA21F9AB4; Thu, 25 Jul 2013 07:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsE+IVn1uska; Thu, 25 Jul 2013 07:46: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 9C7EE21F938E; Thu, 25 Jul 2013 07:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2838; q=dns/txt; s=iport; t=1374763606; x=1375973206; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sY+RIZeMhz0/g4IXWGjBzvxLJi/trYb1oTzAWevwVFY=; b=hVUivE6NgsCReOEBrPtOJtz9svHnMfA2GHj14a8aeQ2zfN88+em79uK7 Kzr3swZgZO5sHDX2du2nzbhwttMRkj4UxBGleRm1g9F7ZA1koziOOhCpl CFFNGL7rqXDzMud/3Pm7d/e0Swhi+YXME67bLQdu4kyxadBRXELykPWWu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAk58VGtJXG+/2dsb2JhbABagwY1UL1dgRYWdIIkAQEBAwEBAQE3NAsQAgEIGAoUECcLJQIEDgUIiAIGDLk+BI5OfAIxB4MSbgOpLIMUgXE5 X-IronPort-AV: E=Sophos;i="4.89,743,1367971200"; d="scan'208";a="239375771" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2013 14:46:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6PEkj9Z016209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 14:46:45 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.242]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 09:46:45 -0500 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Topic: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOfnvAE0hdpuPffU2KL5nISCt1Apll6o6AgA4VXjqAAFnNgIAAFV8AgAEWUoCAAFHsgIAACxMA Date: Thu, 25 Jul 2013 14:46:45 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA37C0D96@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> <1177.1374683864@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BFCF7@xmb-aln-x04.cisco.com> <3896.1374761225@sandelman.ca> In-Reply-To: <3896.1374761225@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <2403AFDE716A3348BC9CAFC34F49171D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:47:00 -0000 On Jul 25, 2013, at 4:07 PM 7/25/13, Michael Richardson wrote: >=20 > Ralph Droms (rdroms) wrote: >>> Ralph Droms (rdroms) wrote: >>>>> I would still like an explanation of why "subnet" is the wrong term. >>>>>=20 >>>>> When would scope-3 would be used such that it would not correspond to= the set >>>>> of links on which a "/64" (or other size) is used? >>>=20 >>>> Hm, I thought I responded but apparently not... >>>=20 >>>> This change to scope 0x03 is not just for MPL, so we don't know how >>>> else it might be used in the future. >>>=20 >>> I understand, but perhaps it would be better, if, when another use case= comes >>> along, they write a document explaining why scope-3 is correct and >>> non-conflicting with the trickle mcast use case. >=20 >> I don't agree; in my opinion, it's better to release scope 0x03 from >> "reserved" state and give guidelines for its use. >=20 > I think that we agree about what we want. Sorry, I disagree. I simply want to release the scope from "(reserved)" st= ate and write down whatever constraints needed for consistency with other s= copes. Jinmei-san (if I may make an inference from his e-mail) supports writing th= is definition into and made the helpful suggestion to add the MPL use case= as an example, which I support. >=20 > What I see you saying is that you want a definition which I find rather > (technically) vague, in anticipation of uses which are not yet well defin= ed, > and may never come to pass. >=20 > I'm saying, let's make the MPL scope-3 use case clear and precise, and if > another situation comes along for which scope-3 is appropriate, let's ext= end > the definition at that time. >=20 > Otherwise, this reminds of site-local scope: > We defined it in what we thought were clear terms for a human, but which > turned out to be too vague for machines, with the result that it could n= ever > be discovered/used. >=20 > Meanwhile, I think that MPL is hung up waiting for this to be properly > clarified. Really? I suggest MPL is hung up waiting author revisions for several last= call comments, including this one - none of which have been addressed sinc= e the last call back in March. This issue could be addressed directly in t= he roll WG by explicitly writing down the behavior of scope 0x03 for MPL fo= rwarding in the MPL spec, which is, in my opinion, where it belongs. My point is that, in my opinion, reserving scope 0x03 for MPL is not the ri= ght thing to do. - Ralph >=20 > -- > Michael Richardson , Sandelman Software Works >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Thu Jul 25 11:03:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E3E21F9946 for ; Thu, 25 Jul 2013 11:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 niLefrCw0NTf for ; Thu, 25 Jul 2013 11:03:48 -0700 (PDT) Received: from nm6-vm1.access.bullet.mail.bf1.yahoo.com (nm6-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF9C21F84F6 for <6man@ietf.org>; Thu, 25 Jul 2013 11:03:48 -0700 (PDT) Received: from [66.196.81.162] by nm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2013 18:03:47 -0000 Received: from [98.138.84.214] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2013 18:03:47 -0000 Received: from [127.0.0.1] by smtp103.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 18:03:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374775427; bh=/ZBZWt8evzcnqiYElSCB4xvMsuIuYCGOAbbxSuT/waQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=n8ZBgyx3P5uYsd9Ah3yS48ZhMyo/RU9Yp2jk/vwUHzc5FT3iqCYAKx20ewuBrwxhkwF+/B+Wix6MbJggbUnmhgl4vSxNJ9k/FxTxYCDhP5U+Xvg6SSFfu86cSNHfF1FU+BBZT1jTqn+vvl4cZRdem1ZWTUhpo4fNDUueKHbyUU8= X-Yahoo-Newman-Id: 319575.50611.bm@smtp103.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: F36a108VM1l9CIvzT0OlaaSIzeKsP9f4lOd0paC834AzFjc khlzO4S6fsfagfq1vvwafKl78YXia45jjykYFOYpD1WHbuHM1h6p4IKetURK M3veX0UxnYAJk_nIP_K9KILE3jHb_G0G7FNknngMgC5LezEmWxKK5ruid1on 5eAgJYczl0AX8Ze8pBnOuOAAi836HgMy0eaZkXZ4bk7DLxE9fMzNM8dUj87v 50WoY_RSHd7b1PVCuy9HXKZ6RMgHB5P849HlQ5z_L4860xl3UIgWRg1XpFwp 2KKLkjrXNsb4XEq8CmsPOY10CazllzVayid2T.Md7Rubox_xSB_YPJI7JHRi I45bkXgaEjD_IVa7z6uAs72PAuKdUm9.njm3Dv4QWmPTRcSfgKc43faDt1NJ fvOdsRPYVfN6QRKTv6S.qsQaMth1EKk3pqeWDLUm8_eZwAVXGrXi4EdR1d2E ms5CFkK3j8EKOyMuTdbKmkPA4lMu7mIWeC1sBumUiIclm3ZjYvf4Ijq8oqZn VyfCc.jw2GEgtVIOuH94- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp103.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 18:03:47 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 11:03:44 -0700 Subject: Re: [Roll] Dissenting technical arguments unwelcome (was: Re: trickle-mcast-04 - Clarify scope value of 3 - subnet-local) From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] Dissenting technical arguments unwelcome (was: Re: trickle-mcast-04 - Clarify scope value of 3 - subnet-local) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 18:03:54 -0000 Hi Ulrich, Let me say as an implementer of ROLL RPL (and Trickle Multicast) the topic of multi-link subnets and the general topic of multicast address scope continues to be a major concern. For example, we needed to extend mDNS to cover site specific addressing for this reason as well as need to define another draft describing ULA prefix delegation rules and forwarding rules for border routers (yet to be done). While our current profile (ZigBee IP) will continue to use multi-link subnets, it would be fantastic to have a discussion on how multi-link subnets might be avoided in the future (if that is even possible). I have to say after your last reference to the AUTOCONF RFC, I still have doubts a /128 prefix solves the problems we are having (though interested in seeing if I am wrong.....) I for one am in favor of having a *technical* discussion on the topic on the ROLL reflector. I also think this topic applies to MANET as well. I did not see any discussion on this thread that was not focused on a relevant technical topic. Hopefully, the WG chairs/vice-chairs will reconsider. Don On 7/25/13 10:52 AM, "Ulrich Herberg" wrote: >Hi, > >Several people in the ROLL WG, amongst others Rob Caigie and Don >Sturek, were interested in the topic of multi-link subnets and the >related multicast scope for MPL / for IPv6 in general [1]. > >This is an important technical topic and deserves due discussion on >this mailing list and 6man. > >I think that both discussions (multi-link subnet and IPv6 multicast >scope 0x03) are closely related; because using "subnet" for a scope >that is meant to be network-wide would imply using (even mandating) >multi-link subnets, which I think is a bad idea. So in order to >explain why I think that the "subnet" scope is a bad idea, I needed to >explain why multi-link subnets are a bad idea. > >I am, however, for the time being prohibited from continued >participation on this technical matter. The ROLL WG chairs sent me a >formal warning saying that: > > o my "comments about multi-hop subnets are not welcome on the ROLL list" > > o I should "refrain repeating them yet again, it is disruptive to the >conversation, and confuses many people." > > o this was a formal warning "as per RFC2418/BCP25, and taking >RFC3683/BPC83 and RFC3934/BCP94 into account, (particularly BCP93 >section 1, paragraph 3) and BCP94 section 2, paragraph 2." > >I am very sad to see that technical arguments are ejected from the >discussion by the ROLL Working Group Chairs if these comments are not >in line with their personal objectives. > >I have sent an appeal to the IESG regarding this formal warning, >according to RFC2026, Section 6.5., "Process Failures", as I believe >that an open exchange of technical arguments is key to the work in any >IETF working group - and that issuing formal warnings simply to >suppress dissenting technical arguments is not beneficial to the IETF, >its participants, and its protocol designs. > > >[1] http://www.ietf.org/mail-archive/web/roll/current/msg07951.html > >Best regards >Ulrich > >On Wed, Jul 24, 2013 at 8:32 AM, Ulrich Herberg >wrote: >> I have pointed out two documents in my earlier email that explain in >> long detail why I believe that multi-hop subnets are a really bad >> idea. The AUTOCONF RFC 5889 presents an architecture for avoiding all >> these problems by using /128 prefixes. In that regards, a subnet wide >> flooding would be fairly uninteresting, as it would not go beyond a >> single router. >> >> Regards >> Ulrich >> >> On Wed, Jul 24, 2013 at 7:58 AM, Michael Richardson >> wrote: >>> >>> I would still like an explanation of why "subnet" is the wrong term. >>> >>> When would scope-3 would be used such that it would not correspond to >>>the set >>> of links on which a "/64" (or other size) is used? >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Thu Jul 25 12:41:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E6621F8618; Thu, 25 Jul 2013 12:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOyR1KWZzbnc; Thu, 25 Jul 2013 12:41:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id DE7E521F84E3; Thu, 25 Jul 2013 12:41:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0A16E20256; Thu, 25 Jul 2013 16:47:22 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1A6EE63A88; Thu, 25 Jul 2013 15:40:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 06DEC63A7C; Thu, 25 Jul 2013 15:40:15 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Dissenting technical arguments unwelcome In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 19:41:45 -0000 --=-=-= Ulrich, thank for starting a new thread on this topic as I asked. I am looking forward to understanding how we can do mesh-over networking without creating multi-link subnets. It might just be that we need to always auto-configure /128 addresses on the interfaces, and use /128 routes everywhere. That's what my code does in order to implement multi-link subnets. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfF/HIqHRg3pndX9AQIISgP8D2WR/UEctWENGdovrrChXjDjk3Mw/jQK sxn806m27c8X5Sm2U7AflWKQ1NvIwnL/6e+mg4dgCxbWWBQ0/o4EMhAsYZiJTtaq REUF7l5cYgJiVG+gjevE9ASMZSCeb4PAcwZ1luBbjk4ayJFMLDtgRP7qhLFNyAN6 1Vqacey4I90= =l5sm -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Thu Jul 25 13:11:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9A021F9339 for ; Thu, 25 Jul 2013 13:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Icy5Mf+u6zgD for ; Thu, 25 Jul 2013 13:11:40 -0700 (PDT) Received: from nm8-vm8.access.bullet.mail.gq1.yahoo.com (nm8-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.216]) by ietfa.amsl.com (Postfix) with ESMTP id 71D1821F8749 for <6man@ietf.org>; Thu, 25 Jul 2013 13:11:39 -0700 (PDT) Received: from [216.39.60.171] by nm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:11:37 -0000 Received: from [98.138.84.174] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:11:37 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 20:11:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374783097; bh=fhnG4R7ypCo6+FQT3VPd/FMm6S1S04hRmZ4hwDsQ1+Q=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=nEP2extSDr6Em6ERM2zxetmhhZRCKg2QhObDriL7ctC4Idicph4Gf5OEo1slDbLwJ3AxIxrtoBD9UcN4AJcaf9nIq4n16mbOiYeoogpP6+BZM4pZMTwL8JrXXg+VD/UOqeAYLTxuSx1WMHCJMgcJgVGK+dFb0BC5kmFw+PU9n8o= X-Yahoo-Newman-Id: 401612.78339.bm@smtp108.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ebK_Q8kVM1nAnV8o2BOvzYpy9bezgMB5d0ZNpO3B.9SVRDv lPaJhXnbdQchyGOCYbm_3J2qTZK__XzTGCN0uKk1Z46bVUlcxBoA09tBH4BM NcdydENW0NO4xwiWkWuF3YOqzq975c4uG0ya6sB0siVLLcix8zaa7bY8tGYn dg7uCLehO6HpjLBAXjYSJj0AMuytqLxFqL123ijtE3_UWTRPl4Cl63iIHZa2 9lkJkufLLBo9Fu4W1wyZJ9u4bO0b_k4HgjMkFjug9dF.RyuURYQvOGmHwXRH wyKdVyNOJdlXagmRDLR1xYLozk5v5U1gloYIaC.Um2vo.lP4V3GTLjFWtcdW gJ9yk8HOloq.dndC47X8H3urqq9ocI3H9j0.e09Ekb6.pLfDDcM3XvZqLou0 8ZHScDKKl2kpCBlJ2e4wBW..grxWW_ajYGrJUTNyPqqLr83Mght5MWU_z3LQ UgvAps3mgOgANH.qt_oHr4t7L72H_O5wskQ552oDahZ6Uy5fB_nb00O.SUTz cRlZCQWOs47CCwB4Zuok- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp108.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 13:11:37 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 13:09:05 -0700 Subject: Re: Multi-Link Subnets via /128 From: Don Sturek To: Michael Richardson , Routing Over Low power and Lossy networks Message-ID: Thread-Topic: Multi-Link Subnets via /128 In-Reply-To: <23549.1374781215@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:11:45 -0000 Note I changed the title on the thread...... My problem with RFC 5889 (http://tools.ietf.org/html/rfc5889) is that it solves the problem simply by saying "don't allocate link locals". The issue I have is that it precludes the use of mDNS (which operate off of link locals). Some questions: 1) Would you recommend then the allocation of ULA's with a /128 (as opposed to globals). There are a lot of applications that really only need to communicate within a residence and don't really have a need in having all devices using globals 2) If we use ULA's, there does not seem to be guidance around which interfaces to perform prefix delegation on and which should not (specifically, I am thinking of rules that a border router would use as to where to issue PIOs in a RPL sense) 3) And of course if there ended up being more than one border router, there is also not guidance on how to combine or proxy ULA prefixes (maybe this topic could be a Homenet solution....) In case anyone is wondering, our initial application deployment using ZigBee IP was Smart Energy Profile 2.0 (SEP 2.0). There was a requirement to perform service discovery without a centralized repository (since it was a multivendor deployment where no device manufacturer wanted responsibility for a centralized DNS). mDNS (extended to use ULAs) was our choice. It would seem with a /128, we would still need the same extensions to mDNS. We plan to support Wi-Fi, HomePlug Power Line Carrier and ZigBee IP in a combined network topology within the home. Don On 7/25/13 12:40 PM, "Michael Richardson" wrote: > > >Ulrich, thank for starting a new thread on this topic as I asked. > >I am looking forward to understanding how we can do mesh-over networking >without creating multi-link subnets. > >It might just be that we need to always auto-configure /128 addresses on >the >interfaces, and use /128 routes everywhere. >That's what my code does in order to implement multi-link subnets. > >-- >Michael Richardson , Sandelman Software Works > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Thu Jul 25 13:12:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D292F21F936F; Thu, 25 Jul 2013 13:12: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 qaMOPX7WBYbB; Thu, 25 Jul 2013 13:12:16 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id AF53621F9346; Thu, 25 Jul 2013 13:12:15 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6PKC7VN019500; Thu, 25 Jul 2013 21:12:07 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r6PKC7VN019500 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1374783127; bh=BOAf2BlHtRpeD3i7YDjbcqeVhGQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=z5zeGdaEAmo69UgXtTzd5kXPhaL2drV0uTYmvbEdtYSPrlo+HB3mAKo3miDYpPriP YtdkRqWuO4aTLoA/2ddn0PuJII8+Z15QZVIDE+7jzSuHJmJdlpf7A+oygBWsV97G0G 50scel5fudK9PyyrdgCeEjGuVYLU0NJnq3ZlJ+A4= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p6OLC70544563261bH ret-id none; Thu, 25 Jul 2013 21:12:07 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6PKBgWV005555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 21:11:43 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [Roll] Dissenting technical arguments unwelcome (was: Re: trickle-mcast-04 - Clarify scope value of 3 - subnet-local) From: Tim Chown In-Reply-To: Date: Thu, 25 Jul 2013 21:11:45 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1896F191-4448-41AF-BC56-E643371BCC4E@ecs.soton.ac.uk> To: Don Sturek X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p6OLC7054456326100; tid=p6OLC70544563261bH; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r6PKC7VN019500 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:12:16 -0000 On 25 Jul 2013, at 19:03, Don Sturek wrote: > Hi Ulrich, >=20 > Let me say as an implementer of ROLL RPL (and Trickle Multicast) the = topic > of multi-link subnets and the general topic of multicast address scope > continues to be a major concern. For example, we needed to extend = mDNS to > cover site specific addressing for this reason as well as need to = define > another draft describing ULA prefix delegation rules and forwarding = rules > for border routers (yet to be done). Hi, It would be great to get requirements for this - hopefully this can be = raised in the dnssdext BoF next week, and contributed into the = draft-lynn-mdnsext-requirements-02 work by Kerry and Stuart. Currently = the dnssdext charter includes this use case. Tim= From d.sturek@att.net Thu Jul 25 13:35:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A276021F944C for ; Thu, 25 Jul 2013 13:35:22 -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 zUVVi4iJDuAj for ; Thu, 25 Jul 2013 13:35:17 -0700 (PDT) Received: from nm1-vm7.access.bullet.mail.gq1.yahoo.com (nm1-vm7.access.bullet.mail.gq1.yahoo.com [216.39.63.179]) by ietfa.amsl.com (Postfix) with ESMTP id 46A1E21F9433 for <6man@ietf.org>; Thu, 25 Jul 2013 13:35:16 -0700 (PDT) Received: from [216.39.60.173] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000 Received: from [98.138.104.100] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374784515; bh=gFfL75VOOcFtFnI3SO4TK7carOhKF8DwLxdC3en5d0o=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=yBpXzKWXavTv63XX6T273AojozZa6B7DLjFngMNEFQZgb2/Zm5tYUgeKCZyNFspa64JGgC4ozv3WgMbfXjTNXfDp0h/vMP8cwMDtky4cEp2D2Y7W+W8cZ9wh4xQl9PBF7ClujjZJKE72J2WCS/t8rpFsIHg85kq9O7hxzseQSuI= X-Yahoo-Newman-Id: 759979.79855.bm@smtp120.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: q97k1zcVM1kP9LsDFgSrjW3oE8XDnzWrNHIO5_QVkwvUoEA xr4kwfa6T35RUxumJZe3EYHN.AEKYD8F40FfTTO1Gqzq_tRYSpEWiOt3U5q9 v1_uwDryw7.CBQ3aiGG7CT5y0LhZE11SEQ0BmPnxBxMJKFGfpN.59VhFM5Ui J_2Yez.q6n1baQ8lje8CHQOevoJirLAPQtwl.Q8Qb2bkCU29D6QCtfx9sX3U tMuGQuY.FzyF_CTUdlcAJgLbtmegYyoVkYVaO2BJKNbcqJv5GMtVEtO1R.iY nHHEQXMgXvQoddxCT5H1qWbjY3RPROxtu3HbH5c05pbiWBPM8.Ngac4VAmRU ZGQARRmBv7dCXTQoPNcR2PLJrGFgPL_8qfZ5m23ptRe3jDSxctK6HGAjxW2j BBrgPWFpW5TfwnS2iWypvSSPdZmxYnC1Rjk41YOt_RiBLwtIbsOxbMf0M2eF vLoIW.ep1HAxRIhbJFJ8H0CkF0FAb1YPB8U2byKEPf1Cnq0GKk2FLKMXzc2z bDrfU1HGZOK5QEB3HBcPSi117hNP2q8tyYw_0arYvHixbPB7SPlXPlviuRpS jzc6J.qf3SCVGg779YeimXXNpye_8NjpRsIJ8BMxi.GVWec.5NHsq6wGiM3J Kig-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp120.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 20:35:15 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 13:35:12 -0700 Subject: Discovery requirements for Smart Energy Profile 2.0 (SEP 2.0) From: Don Sturek To: Tim Chown Message-ID: Thread-Topic: Discovery requirements for Smart Energy Profile 2.0 (SEP 2.0) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mdnsext@ietf.org, Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:35:22 -0000 Hi Tim, Don Sturek, chair for the ZigBee Alliance Core Stack Group which developed ZigBee IP in support of Smart Energy Profile 2.0. Here is a synopsis of the requirements: 1) Support Resource Discovery over a topology that includes Wi-Fi, HomePlug AV and GP and ZigBee IP (ZigBee IP is a multi-hop solution using ROLL RPL) connected via border routers 2) No device vendor wanted responsibility for a centralized DNS or uPNP repository that would be guaranteed to exist in all deployment scenarios. Ideally then services (resources) are self describing and locate-able through client directed queries (DNS-SD was a great solution for this) 3) mDNS was a great choice then for discovery, however, due to the use of ROLL RPL (or really any multi-hop route over solution), the use of link locals would not guarantee discovery of all services (resources). Hence, the extension of mDNS with this now outdated draft (captured in the requirements Kerry created for mdnsext I believe): http://tools.ietf.org/html/draft-lynn-dnsext-site-mdns-01 The DNS-SD draft (RFC 6763) was used in our application without change. We would have welcomed the use of mDNS (RFC 6762) but that would not work with ULAs (which we had to use due to the multi-hop subnet) Again, in some settings there could be a box doing DNS (as long as that platform was good with other vendor solutions posting DNS records into it!). In some settings (where say the electricity meter is the only common platform), most utilities don't want responsibility (or the risk) in having untrusted devices posting anything to them. I like the ideas in Homenet around gathering service information into centralized DNS repositories where such a service exists. By the way, if ULA's continue to be the addressing mechanism, then there are a couple of additional issues: 1) In a border router, clear rules on the propagation of ULA prefixes (eg, which interfaces, ideally those that face inward in the site topology and not to the ISP!) 2) What to do if a border router discovers the existance of other ULA prefixes I think these topics were detailed in this old draft presented in V6OPS sometime ago: http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 Don On 7/25/13 1:11 PM, "Tim Chown" wrote: >On 25 Jul 2013, at 19:03, Don Sturek wrote: > >> Hi Ulrich, >> >> Let me say as an implementer of ROLL RPL (and Trickle Multicast) the >>topic >> of multi-link subnets and the general topic of multicast address scope >> continues to be a major concern. For example, we needed to extend mDNS >>to >> cover site specific addressing for this reason as well as need to define >> another draft describing ULA prefix delegation rules and forwarding >>rules >> for border routers (yet to be done). > >Hi, > >It would be great to get requirements for this - hopefully this can be >raised in the dnssdext BoF next week, and contributed into the >draft-lynn-mdnsext-requirements-02 work by Kerry and Stuart. Currently >the dnssdext charter includes this use case. > >Tim From cabo@tzi.org Thu Jul 25 14:33:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0356721F859A; Thu, 25 Jul 2013 14:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 hyU71SimJYpx; Thu, 25 Jul 2013 14:33:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB5321F8528; Thu, 25 Jul 2013 14:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6PLXE7K028674; Thu, 25 Jul 2013 23:33:14 +0200 (CEST) Received: from [192.168.217.105] (p54890BA4.dip0.t-ipconnect.de [84.137.11.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4B1E34F7; Thu, 25 Jul 2013 23:33:14 +0200 (CEST) Subject: Re: Multi-Link Subnets via /128 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 25 Jul 2013 23:33:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C27A5ED-8104-49DB-8320-E9D76FBF8834@tzi.org> References: To: Don Sturek X-Mailer: Apple Mail (2.1508) Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 21:33:26 -0000 On Jul 25, 2013, at 22:09, Don Sturek wrote: > My problem with RFC 5889 (http://tools.ietf.org/html/rfc5889) is that = it > solves the problem simply by saying "don't allocate link locals". = The > issue I have is that it precludes the use of mDNS (which operate off = of > link locals). It would be easy to run mDNS in a larger multicast scope than = link-local. (I'm ignoring scaling limitations here, which are not that relevant in a = home as long as you have enough power for everyone. If you don't, mDNS = wasn't the right answer in the first place.) But first, you would need to run a multicast routing protocol. That appears to be the larger problem with running mDNS in a = multi-subnet network domain. I happen to believe that running a DNS-SD style service discovery = protocol across subnets is significantly easier than running multicast = routing across subnets and then running mDNS on that multicast routing. I'm not sure the RFC 5889 model is creating any problem here that we = didn't already have as soon as we started to do routing. Gr=FC=DFe, Carsten From mcr@sandelman.ca Thu Jul 25 14:37:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2952321F853A; Thu, 25 Jul 2013 14:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OStCvNwusq8f; Thu, 25 Jul 2013 14:37:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 62C2E21F852D; Thu, 25 Jul 2013 14:37:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 35ADE20168; Thu, 25 Jul 2013 18:43:20 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5585163A88; Thu, 25 Jul 2013 17:36:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4357763A7C; Thu, 25 Jul 2013 17:36:13 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks , "6man\@ietf.org" <6man@ietf.org> Subject: Re: Multi-Link Subnets via /128 In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 21:37:44 -0000 --=-=-= Don Sturek wrote: > Note I changed the title on the thread...... Thank you. I would like to know what a multi-link subnet via /128 means. > My problem with RFC 5889 (http://tools.ietf.org/html/rfc5889) is that it > solves the problem simply by saying "don't allocate link locals". The > issue I have is that it precludes the use of mDNS (which operate off of > link locals). 1) mDNS doesn't have to use link locals, it can, and does distribute ULAs and GUAs v6 addresses just fine. 2) sdnsext might well fix mDNS to run across multiple subnets, not just a multi-link subnet. > Some questions: > 1) Would you recommend then the allocation of ULA's with a /128 (as > opposed to globals). There are a lot of applications that really only > need to communicate within a residence and don't really have a need in > having all devices using globals Yes to ULAs or to NCN's GUAs... but I understand the question. > 2) If we use ULA's, there does not seem to be guidance around which > interfaces to perform prefix delegation on and which should not > (specifically, I am thinking of rules that a border router would use as to > where to issue PIOs in a RPL sense) My reading/understanding/coding is that a border router which thinks it is grounded (G=1) should issue PIOs. > 3) And of course if there ended up being more than one border router, > there is also not guidance on how to combine or proxy ULA prefixes (maybe > this topic could be a Homenet solution....) homenet might provide a solution outside of the RPL space for deciding who will be the root ULA provider and how that might get distributed, but that won't help many RPL/LLN deployments. > In case anyone is wondering, our initial application deployment using > ZigBee IP was Smart Energy Profile 2.0 (SEP 2.0). There was a > requirement to perform service discovery without a centralized repository > (since it was a multivendor deployment where no device manufacturer wanted > responsibility for a centralized DNS). mDNS (extended to use ULAs) was > our choice. It would seem with a /128, we would still need the same > extensions to mDNS. We plan to support Wi-Fi, HomePlug Power Line > Carrier and ZigBee IP in a combined network topology within the home. I assume you used trickle-mcast to propogate the mDNS. Across those three links types, did you have a single ULA/64? How did the gateways between the media types know that they were not at a scope-3 boundary? -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfGaSoqHRg3pndX9AQKA3AP/YijmKsq/bw0WsrRxUyMtMruY+wM3u5+P f9UppetogJ0zivt2WEqf5J+xJBEeypskj/k5plDoyBaW1CqLyd6vA9A5UbwdThnW W0KmhjUyvYFFI9fbmso33jCTchZHEz4MJW4fJOHLrLwUfiJ5yyMetOgGp2xg7pd8 xo8N0EbuhUk= =BR6r -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Thu Jul 25 15:02:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E52621F8C20 for ; Thu, 25 Jul 2013 15:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnA8CIL5lf0x for ; Thu, 25 Jul 2013 15:02:51 -0700 (PDT) Received: from nm4-vm9.access.bullet.mail.bf1.yahoo.com (nm4-vm9.access.bullet.mail.bf1.yahoo.com [216.109.114.120]) by ietfa.amsl.com (Postfix) with ESMTP id E481E21F84B1 for <6man@ietf.org>; Thu, 25 Jul 2013 15:02:50 -0700 (PDT) Received: from [66.196.81.163] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2013 22:02:50 -0000 Received: from [98.138.104.96] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2013 22:02:49 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 22:02:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374789769; bh=4hyyY2fkYoIBmqHBb0JEypRjWuYmoNh0DUqF30iprFA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=nDcHJsQveo8qiM/grQqDlisUPobqZwdfiGzhT6CsFV9C5YT0ZtXxvQ1P6p9NODPrG46rFmnSkpQVKPHZ+NvJTRbjFMk7lKBBXwMdYp8D9gCpU5M1bjaP293G7UZ/X2obO1ImOKJz/EVeDKvoQe/pJuE6dwfr5yJaaldPjD5G8gQ= X-Yahoo-Newman-Id: 910617.81377.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: RV9UVEMVM1lom2SscQrawW9DdDS7qSDs.EfEDpX7TULnn2m SmqxoLFkyEzCGei_MfLX8IlUdNecNL7TFrEdqMHaCkedymJElp8aZ4CQ2Syp WOTf.j2NaBXWDwsmhzmWd2jJeYOFfG7wpOire4MPi8ygQ_O786Ujbi96Xss3 uffie.n5_l_a8UFwhOSKp3FVTRlYvSB4yN_jfjE5JPmMogv.04rcduTHdGlR jyCZ7qpUJVYdnA0MPGpIF2Tkkw_J61cxPx5uZedm069Wew7c5ryHt7.WW_sM R6bhZURF_yRjWRyFRAJYjvFZJsOXA4noMIff3VBtgakqgRjLvebZ69p_UBMA t_qb8.lIjc7kzEGq7p7ew3GlK.epT3kHCKYgy_w_6_UCu7PgTJIn26dXPt7V zNc_pYnxdoMIZBhLDdQuCTpxv4LmqkD0J_uYZJlbf3r81ZKHEIkI5BTMdAny 37SROZyng_K6aNnZEh_qI2y7iB_hOlBELWSCoTdl14C_gQesng282ulHJZIf cxGjhtFthIgW_j8BNESA- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp116.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 22:02:49 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 15:01:24 -0700 Subject: Re: Multi-Link Subnets via /128 From: Don Sturek To: Michael Richardson , Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Message-ID: Thread-Topic: Multi-Link Subnets via /128 In-Reply-To: <9271.1374788173@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:02:56 -0000 Hi Michael, We did a good bit of work on the mDNS topic and there are quite a few subtleties in the mDNS draft that are really focused only on correct link local operation. Here are a few (from RFC 6762): 1) Section 3.1 Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB) 2) Section 4 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 or the mDNS IPv6 multicast address FF02::FB. 3) Section 11 All Multicast DNS responses (including responses sent via unicast) SHOULD be sent with IP TTL set to 255. This is recommended to provide backwards-compatibility with older Multicast DNS queriers (implementing a draft version of this document, posted in February 2004) that check the IP TTL on reception to determine whether the packet originated on the local link. These older queriers discard all packets with TTLs other than 255. 4) Also Section 11 A host sending Multicast DNS queries to a link-local destination address (including the 224.0.0.251 and FF02::FB link-local multicast addresses) MUST only accept responses to that query that originate from the local link, and silently discard any other response packets. 5) Again in Section 11 The test for whether a response originated on the local link is done in two ways: * All responses received with a destination address in the IP header that is the mDNS IPv4 link-local multicast address 224.0.0.251 or the mDNS IPv6 link-local multicast address FF02::FB are necessarily deemed to have originated on the local link, regardless of source IP address. This is essential to allow devices to work correctly and reliably in unusual configurations, such as multiple logical IP subnets overlayed on a single link, or in cases of severe misconfiguration, where devices are physically connected to the same link, but are currently misconfigured with completely unrelated IP addresses and subnet masks. * For responses received with a unicast destination address in the IP header, the source IP address in the packet is checked to see if it is an address on a local subnet. An IPv4 source address is determined to be on a local subnet if, for (one of) the address(es) configured on the interface receiving the packet, (I & M) == (P & M), where I and M are the interface address and subnet mask respectively, P is the source IP address from the packet, '&' represents the bitwise logical 'and' operation, and '==' represents a bitwise equality test. An IPv6 source address is determined to be on the local link if, for any of the on-link IPv6 prefixes on the interface receiving the packet (learned via IPv6 router advertisements or otherwise configured on the host), the first 'n' bits of the IPv6 source address match the first 'n' bits of the prefix address, where 'n' is the length of the prefix being considered. Don On 7/25/13 2:36 PM, "Michael Richardson" wrote: > > >Don Sturek wrote: > > > Note I changed the title on the thread...... > >Thank you. >I would like to know what a multi-link subnet via /128 means. > > > My problem with RFC 5889 (http://tools.ietf.org/html/rfc5889) is >that it > > solves the problem simply by saying "don't allocate link locals". >The > > issue I have is that it precludes the use of mDNS (which operate >off of > > link locals). > >1) mDNS doesn't have to use link locals, it can, and does distribute ULAs >and > GUAs v6 addresses just fine. > >2) sdnsext might well fix mDNS to run across multiple subnets, not just > a multi-link subnet. > > > Some questions: > > 1) Would you recommend then the allocation of ULA's with a /128 (as > > opposed to globals). There are a lot of applications that really >only > > need to communicate within a residence and don't really have a need >in > > having all devices using globals > >Yes to ULAs or to NCN's GUAs... but I understand the question. > > > 2) If we use ULA's, there does not seem to be guidance around which > > interfaces to perform prefix delegation on and which should not > > (specifically, I am thinking of rules that a border router would >use as to > > where to issue PIOs in a RPL sense) > >My reading/understanding/coding is that a border router which thinks it is >grounded (G=1) should issue PIOs. > > > 3) And of course if there ended up being more than one border >router, > > there is also not guidance on how to combine or proxy ULA prefixes >(maybe > > this topic could be a Homenet solution....) > >homenet might provide a solution outside of the RPL space for deciding who >will be the root ULA provider and how that might get distributed, but that >won't help many RPL/LLN deployments. > > > In case anyone is wondering, our initial application deployment >using > > ZigBee IP was Smart Energy Profile 2.0 (SEP 2.0). There was a > > requirement to perform service discovery without a centralized >repository > > (since it was a multivendor deployment where no device manufacturer >wanted > > responsibility for a centralized DNS). mDNS (extended to use ULAs) >was > > our choice. It would seem with a /128, we would still need the same > > extensions to mDNS. We plan to support Wi-Fi, HomePlug Power Line > > Carrier and ZigBee IP in a combined network topology within the >home. > >I assume you used trickle-mcast to propogate the mDNS. >Across those three links types, did you have a single ULA/64? >How did the gateways between the media types know that they were not at a >scope-3 boundary? > >-- >Michael Richardson , Sandelman Software Works > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From d.sturek@att.net Thu Jul 25 15:06:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6BA21F922A for ; Thu, 25 Jul 2013 15:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAbLAnyTC6hZ for ; Thu, 25 Jul 2013 15:06:37 -0700 (PDT) Received: from nm24-vm7.access.bullet.mail.bf1.yahoo.com (nm24-vm7.access.bullet.mail.bf1.yahoo.com [216.109.115.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF2A21F91CA for <6man@ietf.org>; Thu, 25 Jul 2013 15:06:37 -0700 (PDT) Received: from [66.196.81.164] by nm24.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2013 22:06:35 -0000 Received: from [98.138.84.174] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2013 22:06:35 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 22:06:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374789995; bh=GHf8utqeWGuPIQv9ph5cccVxWl4nr80/95GU1IHTu2Y=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=0zFEjCDysRDHyDSHpjLAV26Vh5U6TzNeUy5tS7CTYkIhnBPV2xfNB1fNyCAUZklqnSzdLD9MryvDHSOzOGDv5EiAfTYjh5PcwlysjXrzopsKxblCC9LSemoTTAyAyfwB7tp1HOiflZTNtPdDtNRweJQTt5jQn/joWyOPHhrh6eI= X-Yahoo-Newman-Id: 470924.4388.bm@smtp108.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zbXQoX4VM1kVXJuXTXN632.tBKWro_DQFBrjPE0iW8gQ8Vn NnGji012jPMU9Z0da7FcWjqkzAcefQ1P23gx4WR7ekpJgsgUdb.YhQkIM5ez eYjL.uTAA8bj7UEC_OxsVY5D4e.qYVVhUSSQzfvj9y0jPB3wImceQd32BQ_X Fy0BE2UhiIAwRGfhtzQCivOlajZuKpOihX4cxr9zX.gDzOJxXU1.GOXewVxA PNaxN7oCBjtf3KOaNjMBQhMcZMllEMjIrT9HtUzC6Awb847fgfA6YWh6v8ea nVyb5qDIoKNozOdb_m1lt5fAAmHKzg7H7ZAPYRCXYG6h3C_zvRXLG5ZCqlGx E0BF35XK3NX40wZOtdJUtsmxV85jIqhfYkQkRsBBAVdxdU2_tEZfkUYS7BKj A1k0GAI8r9fI.UPKnW0DEG7HFzSI5zm8MI0SnC5s9v2WiyzFc_wbMkB1DFOE hqPChlbxFmV0.9kuGBo3EV_l451EDKrtsaYTg_F9wEClJf7TzFo30cJ82YpX eJdIX2RSH4MepHxqghWexIgRCnstfEm5sL_oPJOoLyLifEt.CNOf7v9STaNi u_3W3PlC2tHzL2hpx8Vw7tS7icomhAgkO X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp108.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 15:06:35 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 15:05:18 -0700 Subject: Re: Multi-Link Subnets via /128 From: Don Sturek To: Carsten Bormann Message-ID: Thread-Topic: Multi-Link Subnets via /128 In-Reply-To: <3C27A5ED-8104-49DB-8320-E9D76FBF8834@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:06:55 -0000 Hi Carsten, Actually, we have done quite a bit of testing using site scoped multicast and the Extended version of mDNS and it seems to work quite well (mainly since we changed little in mDNS and only addressed the issues of using a multicast scope other than link local) Don On 7/25/13 2:33 PM, "Carsten Bormann" wrote: >On Jul 25, 2013, at 22:09, Don Sturek wrote: > >> My problem with RFC 5889 (http://tools.ietf.org/html/rfc5889) is that it >> solves the problem simply by saying "don't allocate link locals". The >> issue I have is that it precludes the use of mDNS (which operate off of >> link locals). > >It would be easy to run mDNS in a larger multicast scope than link-local. >(I'm ignoring scaling limitations here, which are not that relevant in a >home as long as you have enough power for everyone. If you don't, mDNS >wasn't the right answer in the first place.) > >But first, you would need to run a multicast routing protocol. >That appears to be the larger problem with running mDNS in a multi-subnet >network domain. > >I happen to believe that running a DNS-SD style service discovery >protocol across subnets is significantly easier than running multicast >routing across subnets and then running mDNS on that multicast routing. > >I'm not sure the RFC 5889 model is creating any problem here that we >didn't already have as soon as we started to do routing. > >Gr=FC=DFe, Carsten > From mcr@sandelman.ca Thu Jul 25 15:09:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75AD21F84BB; Thu, 25 Jul 2013 15:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zDuxQkoEMnV; Thu, 25 Jul 2013 15:09:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8202221F849C; Thu, 25 Jul 2013 15:09:00 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id B4CDC20168; Thu, 25 Jul 2013 19:14:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C63F0A902A; Thu, 25 Jul 2013 18:07:38 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B233063A7C; Thu, 25 Jul 2013 18:07:38 -0400 (EDT) From: Michael Richardson To: Don Sturek Subject: Re: Multi-Link Subnets via /128 In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:09:05 -0000 --=-=-= Don Sturek wrote: > We did a good bit of work on the mDNS topic and there are quite a few > subtleties in the mDNS draft that are really focused only on correct link > local operation. Here are a few (from RFC 6762): Ah, I understand now, and I agree. I thought you were saying that mDNS replies could not have ULAs in their answer sections. I agree that all of the things you mention have to be adjusted in order to permit mDNS to work over MPL. My question remains: > I would like to know what a multi-link subnet via /128 means. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfGhqIqHRg3pndX9AQLSOQP+N1z+wrU/JqN97d+GP/uMAviep5FnCdq1 H3X8UbpMv0qNjN681yXEyKWrCFjaD4orUopv+h0QTMddlUSSGS9UgojaH1IfhEvR taOX6m/QtPEyxEQSVx9Hy77hHEe1/ZX3giCnyrFsmPfSYlITeb31qLQr4Ro/HS2W kw1nf21/bxc= =WQIn -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Thu Jul 25 15:53:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4821F8F4D for ; Thu, 25 Jul 2013 15:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7QjAR5Fzc2K for ; Thu, 25 Jul 2013 15:53:24 -0700 (PDT) Received: from nm18-vm9.access.bullet.mail.gq1.yahoo.com (nm18-vm9.access.bullet.mail.gq1.yahoo.com [216.39.62.65]) by ietfa.amsl.com (Postfix) with ESMTP id AFB9221F8D8C for <6man@ietf.org>; Thu, 25 Jul 2013 15:53:24 -0700 (PDT) Received: from [216.39.60.169] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 22:53:23 -0000 Received: from [98.138.84.173] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 22:53:23 -0000 Received: from [127.0.0.1] by smtp107.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 22:53:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374792803; bh=jkgJavOHlV3uJU8fneO9nBP84Ev7WAjOP5/0fwGIKCA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=IE6qVPMpKXw1fBKgq/2fqSRI/TbRtMRnAEmMIgg6kPvjzLrAeiaJhr+6dsJCnCbABFrsaZUyfrbniPnV7exA9kX7tW+PgjkDRewSvbtJE2mCBD/V9B0TiN6mgZ/+dB6JRi903kyAZMK9ZjbIDM9nMLMGbG5scxo2w04ZxcxkT2s= X-Yahoo-Newman-Id: 538432.66611.bm@smtp107.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jeajAgoVM1kf2wcZZ00ge8sQQYOvM7uT1UAHmOoOzD1oplE VIlQ208VY.uT59C1wfZa.hGAdrgCzK.zyb7Zq41AphKzjA.nX9T8t9tkhub1 4Uck40Hi0aCR02Q_DFf9.8YFXrAcgtFIbqLF6fggQzTaiJupv_pPBnCuwIqB B9b0kEvqNiYWrvY6VQvgkUpIclY40rcywQWHKe1YAfT.GTVgC2F96LZhRhgI AgB3kJcSYW_Pkl3hEhrOdNfgYIaUwMR4vdCkZ33Ib6RPUnT.3g.erd3b8dto 8S66MogIYXdAlAtY3RxdT13LNB5hlJs6vE4OMErITdl8aw3nidBiOelICSPp nTsFugy.oKQk4oKX0bXD6vsjAhos0SnRFAHo1rPJVtsVABstxmxbaXvFztgw kXMccppxMi4AxJflNVAQpdpCVog1qn4prNSHAWBTERrNiLwXEQ76i.vZbIFq xvIHHhDzeFfc6QKtnNrLVU5_D0R39_LOatneI8e7gslQazK1CQFEgVPnBLac zR7T2z9r_C2T5l.i4_MI- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp107.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 15:53:23 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 15:50:53 -0700 Subject: Re: Multi-Link Subnets via /128 From: Don Sturek To: Michael Richardson Message-ID: Thread-Topic: Multi-Link Subnets via /128 In-Reply-To: <14375.1374790058@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:53:31 -0000 Hi Michael, I mispoke on the last point. Should have read: multi-link subnets versus allocating a /128 Don On 7/25/13 3:07 PM, "Michael Richardson" wrote: > > >Don Sturek wrote: > > We did a good bit of work on the mDNS topic and there are quite a >few > > subtleties in the mDNS draft that are really focused only on >correct link > > local operation. Here are a few (from RFC 6762): > >Ah, I understand now, and I agree. >I thought you were saying that mDNS replies could not have ULAs in their >answer sections. > >I agree that all of the things you mention have to be adjusted in order to >permit mDNS to work over MPL. > >My question remains: > > > I would like to know what a multi-link subnet via /128 means. > > >-- >Michael Richardson , Sandelman Software Works > > From jinmei@isc.org Fri Jul 26 00:54:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424E421F8756; Fri, 26 Jul 2013 00:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.165, 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 wlvXqhOFzA0n; Fri, 26 Jul 2013 00:54:16 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7761B21F87B7; Fri, 26 Jul 2013 00:54:16 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8E8EDC9465; Fri, 26 Jul 2013 07:54:02 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 26 Jul 2013 07:54:02 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 095CD160276; Fri, 26 Jul 2013 07:57:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9kcLICq_2hj4; Fri, 26 Jul 2013 07:57:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8A4F0160275; Fri, 26 Jul 2013 07:57:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id d-2yytHNzKFI; Fri, 26 Jul 2013 07:57:24 +0000 (UTC) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) by zmx1.isc.org (Postfix) with ESMTPSA id 41412160051; Fri, 26 Jul 2013 07:57:24 +0000 (UTC) Date: Fri, 26 Jul 2013 00:53:57 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Ralph Droms (rdroms)" Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA37C0D96@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> <1177.1374683864@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BFCF7@xmb-aln-x04.cisco.com> <3896.1374761225@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37C0D96@xmb-aln-x04.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 07:54:22 -0000 At Thu, 25 Jul 2013 14:46:45 +0000, "Ralph Droms (rdroms)" wrote: > >>> I understand, but perhaps it would be better, if, when another use case comes > >>> along, they write a document explaining why scope-3 is correct and > >>> non-conflicting with the trickle mcast use case. > > > >> I don't agree; in my opinion, it's better to release scope 0x03 from > >> "reserved" state and give guidelines for its use. > > > > I think that we agree about what we want. > > Sorry, I disagree. I simply want to release the scope from "(reserved)" state and write down whatever constraints needed for consistency with other scopes. > > Jinmei-san (if I may make an inference from his e-mail) supports writing this definition into and made the helpful suggestion to add the MPL use case as an example, which I support. I didn't have a strong opinion about which one is better: A: keep the definition of scope-3 generic (+ possibly show the MPL case as an example), or B: limit the definition to the MPL case for now (+ possibly extend it in future as we find more specific cases) My comment was that assuming the choice of keeping it generic is given, it would still be helpful if we give a specific example case. But, on thinking about it now, I think I have a leaning to approach A, because the concept of address scope itself is generic while the MPL case seems too specific. And, as long as the 6man-multicast-scopes document shows a specific example (so the definition won't be too vague) and states future cases should be defined in separate RFCs (as it does in the first sentence of Section 2 of the 00 version), it seems to address the concerns that approach B would try to address. Still not a strong opinion anyway, though. -- JINMEI, Tatuya From mcr@sandelman.ca Fri Jul 26 07:13:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE4321F8A50; Fri, 26 Jul 2013 07:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4R0+nrTTsez; Fri, 26 Jul 2013 07:13:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE0821F880F; Fri, 26 Jul 2013 07:13:00 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F23120192; Fri, 26 Jul 2013 11:18:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3135AA902A; Fri, 26 Jul 2013 10:11:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1D5EFB9083; Fri, 26 Jul 2013 10:11:36 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks , 6man@ietf.org Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <51F22938.8050803@gridmerge.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6ab8f10970432e6f2bb367aa0b632dda@trac.tools.ietf.org> <23575.1373577247@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA3793403@xmb-aln-x04.cisco.com> <4874.1373906541@sandelman.ca> <38A9423D-BBD7-48E9-846F-C1360BEFEE85@gmail.com> <51EEC0F2.9010601@gridmerge.com> <1374658706.80014.YahooMailNeo@web142503.mail.bf1.yahoo.com> <18208.1374677909@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BD071@xmb-aln-x04.cisco.com> <1177.1374683864@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37BFCF7@xmb-aln-x04.cisco.com> <3896.1374761225@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA37C0D96@xmb-aln-x04.cisco.com> <51F22938.8050803@gridmerge.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:13:01 -0000 --=-=-= Having had a number of private exchanges with Ralph, I support the document as worded. It was not clear to me before that trickle-mcast will be *expected* to define what it means for the scope to be "defined automatically from the network topology" I thought that further clarification of the use of scope-3 within MPL would be considered an infringment upon 6man's charter. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfKDk4qHRg3pndX9AQJvYAP/QVJDMzMCCh3ZJLw/pvmNV09P+rWUc1bz TvE+a+y8A1tvr/cxAUKfMoHqIDOGLJvJ7umaEoTT6oitAfAwk8uIURbjYmFqU3Nd jrUjXhO1cPfSg5oR3UD0PWfkBQWbAtdq7UfeCPVnMPOuHu+3P1vw0aTHExsX4qd3 /WXvwEZ1CPY= =3L4w -----END PGP SIGNATURE----- --=-=-=-- From emmanuel.baccelli@gmail.com Fri Jul 26 01:50:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C8E21F847C; Fri, 26 Jul 2013 01:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f3xXn3rdrBI; Fri, 26 Jul 2013 01:50:47 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3521F893E; Fri, 26 Jul 2013 01:50:45 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so6698237oah.24 for ; Fri, 26 Jul 2013 01:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=tVUgw7LV/elUiXwNrPiU0LzVCKkxX8HdnNxaYtXDcfQ=; b=MS9k7/jm3zafQmP3QOVcFQpSx370Nz7zZQ+4WqRQijwbw2WIPHKQ90Ye41Exdf1+FL lAilnJ/SjIWRORGbm5tugQBrC7lw2WUiQYgOKWg7pHpu3NgysdjpOpFBSyzdKHXXfxjm f60ozYNYScAK1rSlzOvuO3e5HRDw5PHNk4Aq97IOoAXcPaKV1tNRC4rF0MfKXBYsH4Mo xQbfktEfYg59DKB0ob5cC4VOZyuD4C89HL0ZY8tklERCk4fHTui9qki8ah3MD3cEJ4X1 73c9dc4nA19qAuQoc8bWJHChIRMQuQIersVfnjGH+l7Yc7JOfnqgQDb5zWlEKifthK/S 1Yvg== X-Received: by 10.182.176.34 with SMTP id cf2mr40726752obc.45.1374828645511; Fri, 26 Jul 2013 01:50:45 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.82.133 with HTTP; Fri, 26 Jul 2013 01:50:25 -0700 (PDT) In-Reply-To: <23549.1374781215@sandelman.ca> References: <23549.1374781215@sandelman.ca> From: Emmanuel Baccelli Date: Fri, 26 Jul 2013 10:50:25 +0200 X-Google-Sender-Auth: Y6d_l4PKpGleSKZEtKvWBnGGALA Message-ID: Subject: Re: [Roll] Dissenting technical arguments unwelcome To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=e89a8ff1cf820af8e204e2663d33 X-Mailman-Approved-At: Fri, 26 Jul 2013 10:13:20 -0700 Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:50:47 -0000 --e89a8ff1cf820af8e204e2663d33 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, actually, MANET protocols have been working for years to provide mesh-over routing, without multi-link subnets. To understand better the "link" properties you have to deal with, you could take a look at this draft http://tools.ietf.org/html/draft-baccelli-manet-multihop-communication-02 As Ulrich mentioned, the conclusion of AUTOCONF was that IP links as we know them do *not* make sense in a spontaneous wireless multi-hop environment. This conclusion was documented in RFC 5889, which essentially bans the use of subnet prefixes in this environment. And without subnet prefixes, what is the purpose of an IP link? Not much... Best, Emmanuel On Thu, Jul 25, 2013 at 9:40 PM, Michael Richardson wrote: > > Ulrich, thank for starting a new thread on this topic as I asked. > > I am looking forward to understanding how we can do mesh-over networking > without creating multi-link subnets. > > It might just be that we need to always auto-configure /128 addresses on > the > interfaces, and use /128 routes everywhere. > That's what my code does in order to implement multi-link subnets. > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --e89a8ff1cf820af8e204e2663d33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,

actually, MANET protocols h= ave been working for years to provide mesh-over routing, without multi-link= subnets.

To understand better the &qu= ot;link" properties you have to deal with, you could take a look at th= is draft http://tools.ietf.org/html/draft-baccelli-manet-multiho= p-communication-02

As Ulrich mentioned, the conclusion of AUTO= CONF was that IP links as we know them do *not* make sense in a spontaneous= wireless multi-hop environment.

This conclusion was documented in RFC 5889, which essentially bans the use = of subnet prefixes in this environment. And without subnet prefixes, what i= s the purpose of an IP link? Not much...

Best,

Emmanuel




On Thu, Jul 25, 2013 at 9:40 PM, Michael Richardson <= mcr+ietf@sandelman.ca> wrote:

Ulrich, thank for starting a new thread on this topic as I asked.

I am looking forward to understanding how we can do mesh-over networking without creating multi-link subnets.

It might just be that we need to always auto-configure /128 addresses on th= e
interfaces, and use /128 routes everywhere.
That's what my code does in order to implement multi-link subnets.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works



_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--e89a8ff1cf820af8e204e2663d33-- From Richard.Kelsey@silabs.com Fri Jul 26 06:55:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61FA21F9929; Fri, 26 Jul 2013 06:55:15 -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 9jcPzLMUgli6; Fri, 26 Jul 2013 06:55:09 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70721F979E; Fri, 26 Jul 2013 06:55:09 -0700 (PDT) Received: from mail206-db8-R.bigfish.com (10.174.8.247) by DB8EHSOBE010.bigfish.com (10.174.4.73) with Microsoft SMTP Server id 14.1.225.22; Fri, 26 Jul 2013 13:55:08 +0000 Received: from mail206-db8 (localhost [127.0.0.1]) by mail206-db8-R.bigfish.com (Postfix) with ESMTP id E4BAE2E0404; Fri, 26 Jul 2013 13:55:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.53; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0712HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: PS-4(zz9371IfadId79ah1432I217bIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail206-db8: domain of silabs.com designates 157.56.238.53 as permitted sender) client-ip=157.56.238.53; envelope-from=Richard.Kelsey@silabs.com; helo=BY2PRD0712HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail206-db8 (localhost.localdomain [127.0.0.1]) by mail206-db8 (MessageSwitch) id 1374846906442076_5477; Fri, 26 Jul 2013 13:55:06 +0000 (UTC) Received: from DB8EHSMHS005.bigfish.com (unknown [10.174.8.254]) by mail206-db8.bigfish.com (Postfix) with ESMTP id 5D94C20046; Fri, 26 Jul 2013 13:55:06 +0000 (UTC) Received: from BY2PRD0712HT002.namprd07.prod.outlook.com (157.56.238.53) by DB8EHSMHS005.bigfish.com (10.174.4.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 26 Jul 2013 13:55:03 +0000 Received: from BY2PRD0712MB672.namprd07.prod.outlook.com ([169.254.9.196]) by BY2PRD0712HT002.namprd07.prod.outlook.com ([10.255.246.35]) with mapi id 14.16.0329.000; Fri, 26 Jul 2013 13:55:03 +0000 From: Richard Kelsey To: Routing Over Low power and Lossy networks Subject: RE: [Roll] Dissenting technical arguments unwelcome Thread-Topic: [Roll] Dissenting technical arguments unwelcome Thread-Index: AQHOiW8hRTZW/S68x06bEju446IrDpl2p3iAgABT8b4= Date: Fri, 26 Jul 2013 13:55:02 +0000 Message-ID: References: <23549.1374781215@sandelman.ca>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.48.253.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: silabs.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Fri, 26 Jul 2013 10:13:20 -0700 Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 13:55:16 -0000 From: Emmanuel Baccelli [Emmanuel.Baccelli@inria.fr] Sent: Friday, July 26, 2013 4:50 AM > As Ulrich mentioned, the conclusion of AUTOCONF was that IP links as > we know them do *not* make sense in a spontaneous wireless multi-hop > environment. > = > This conclusion was documented in RFC 5889, which essentially bans > the use of subnet prefixes in this environment. And without subnet > prefixes, what is the purpose of an IP link? Not much... Hi Emmanuel, While I generally agree with what RFC 5889 says, its focus is on autoconfiguration. For example, the statement o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they can not be used to reliably identify routers. is true only if restricted to autoconfiguration mechanisms. To the extent that RFC 5889, which is informational, bans anything, it bans using autoconfiguration to configure addresses with subnet prefixes in this sort of network. It says nothing one way or the other about using, say, DHCPv6 or 6LoWPAN ND to do so. The whole multi-link subnet discussion is difficult because the term 'subnet' has different implications in different contexts. For example, RFC 5889 says: Subnet prefix configuration on such interfaces must thus not make any promises in terms of direct (one hop) IP connectivity to IP addresses other than that of the interface itself. This suggests the following principle: o no two such interfaces in the network should be configured with the same subnet prefix. An equally valid principle would have been: o subnet prefixes should not be used for on-link determination for such interfaces. Which you prefer depends on how much you consider on-link determination to be a fundamental aspect of subnet prefixes. For autoconfiguration it is a fundamental aspect; for routing, perhaps not. I think it makes sense to follow RFC 5889's recommendation and assign only /128 subnet prefixes to interfaces in an ad-hoc radio network. I also think it makes sense to arrange for those subnet prefixes to share a single /64 prefix and to use that fact at the routing layer. Whether or not this is a multi-link subnet depends on who you ask. -Richard Kelsey This message (including any attachments) is intended only for the use of th= e individual or entity to which it is addressed and may contain information= that is non-public, proprietary, privileged, confidential, and exempt from= disclosure under applicable law or may constitute as attorney work product= . If you are not the intended recipient, you are hereby notified that any = use, dissemination, distribution, or copying of this communication is stric= tly prohibited. If you have received this communication in error, notify us= immediately by telephone and destroy this message if a facsimile or (ii) = delete this message immediately if this is an electronic communication. = Thank you. From d.sturek@att.net Fri Jul 26 10:26:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F3921F9B11 for ; Fri, 26 Jul 2013 10:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUo-mzdlGm+K for ; Fri, 26 Jul 2013 10:26:32 -0700 (PDT) Received: from nm9-vm3.access.bullet.mail.bf1.yahoo.com (nm9-vm3.access.bullet.mail.bf1.yahoo.com [216.109.114.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7FF21F9B0D for <6man@ietf.org>; Fri, 26 Jul 2013 10:26:31 -0700 (PDT) Received: from [66.196.81.165] by nm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jul 2013 17:26:30 -0000 Received: from [98.139.221.56] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jul 2013 17:26:30 -0000 Received: from [127.0.0.1] by smtp109.sbc.mail.bf1.yahoo.com with NNFMP; 26 Jul 2013 17:26:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374859590; bh=/QtaI59lGbY314eGgXst5h0br7lafPVZZ+fh1zONYS8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=rhSXFMm8Mi9GLWPPyLa/2O09MSVOMrEVGx3T+VEHCv4LdqsAwAKVN/kQDxqitedNna0faiw+RxejcgD8GGHBJaAW2tKEZLKsyS6byyciBmXJo+JJuXp2WT53IZoxIPn/dsyS+IjA8Bx/Y/ENAAsmm8BLuy1w9v1BzpX8ciXL2Wg= X-Yahoo-Newman-Id: 350524.13993.bm@smtp109.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: s84kIosVM1lA.JAfNc2odWdcjX8lt2aciSVC_XLbXVdxQx0 b3Wg9hVvmiLrzoa0sthANMhr5yeI.yFXYDZdPDrfWVSlvHRj0w5dMSJBcERY 991RrfWA_utLGT98Y59sXTbTds.uLuEtACCq3cypXcr2Y7Jp3XIFm.a4Lj6F KT0EN4RlgweQnYReb4qmPiVKI3yeEySlHeiI2l2SUQ.UqV.7I7HLnPljkljL jdaRnd1gsChCQIJmQHEnhnr5Oy2lAGw0Z5us2pKcY61y9UFToazR4dFul8hV 9y3xz6KucwnLhzL.XvAeXMMar3ysZT94m84RIYHC0NWDTsOHyonSPIdsJkra i.snupb7YJWZukuv0IAfM_E1K2cTzZujaD892SBmHU3NjgtOwgsOS.KYaE_2 AHQmheRqkl2R0fVIc2yd.05.f5J77d5u3OnMUklszdERZ3cZ.xRZAcvc7GRK nOiHrXNKBaewBmtuQmQ_Al7yXtpSClp9oeJqm4DrCZyA05AsXmpAbUHlGR2S x9YR1Q6eEaJSFwQNe X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.129] (d.sturek@66.27.60.174 with login) by smtp109.sbc.mail.bf1.yahoo.com with SMTP; 26 Jul 2013 10:26:30 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Fri, 26 Jul 2013 10:25:15 -0700 Subject: Re: [Roll] Dissenting technical arguments unwelcome From: Don Sturek To: Emmanuel Baccelli , Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] Dissenting technical arguments unwelcome In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3457679189_257412" Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 17:26:37 -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_3457679189_257412 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Emmanuel, I think if route over protocols are to adhere to RFC 5889, much more work needs to go into making ULAs useful. For our project we used: 6LoWPAN (RFC 4944), 6LoWPAN-ND (RFC 6775), ROLL RPL (RFC 650), mDNS (RFC 6762) with some extensions to use ULAs (among others) and I can say that simply not using link locals with RFC 5889 would not yield a robust IoT solution (at least this is my opinion having worked on this for 4 years now) Don From: Emmanuel Baccelli Date: Friday, July 26, 2013 1:50 AM To: Routing Over Low power and Lossy networks Cc: "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] Dissenting technical arguments unwelcome Hi Michael, actually, MANET protocols have been working for years to provide mesh-over routing, without multi-link subnets. To understand better the "link" properties you have to deal with, you could take a look at this draft http://tools.ietf.org/html/draft-baccelli-manet-multihop-communication-02 As Ulrich mentioned, the conclusion of AUTOCONF was that IP links as we know them do *not* make sense in a spontaneous wireless multi-hop environment. This conclusion was documented in RFC 5889, which essentially bans the use of subnet prefixes in this environment. And without subnet prefixes, what is the purpose of an IP link? Not much... Best, Emmanuel On Thu, Jul 25, 2013 at 9:40 PM, Michael Richardson wrote: > > Ulrich, thank for starting a new thread on this topic as I asked. > > I am looking forward to understanding how we can do mesh-over networking > without creating multi-link subnets. > > It might just be that we need to always auto-configure /128 addresses on the > interfaces, and use /128 routes everywhere. > That's what my code does in order to implement multi-link subnets. > > -- > Michael Richardson >, > Sandelman Software Works > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --B_3457679189_257412 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Emmanuel,
I think if route over protocols are to adhere to RFC 5889, much = more work needs to go into making ULAs useful.

For = our project we used:    6LoWPAN (RFC 4944), 6LoWPAN-ND (RFC 6775),= ROLL RPL (RFC 650), mDNS (RFC 6762) with some extensions to use ULAs (among= others) and I can say that simply not using link locals with RFC 5889 would= not yield a robust IoT solution (at least this is my opinion having worked = on this for 4 years now)

Don



From: Emmanu= el Baccelli <Emmanuel.Baccell= i@inria.fr>
Date: Friday, J= uly 26, 2013 1:50 AM
To: Routing O= ver Low power and Lossy networks <roll@iet= f.org>
Cc: "6man@ietf.org" <6man@i= etf.org>
Subject: Re: [Roll= ] Dissenting technical arguments unwelcome

Hi Michael,


<= div class=3D"gmail_quote">On Thu, Jul 25, 2013 at 9:40 PM, Michael Richardson = <m= cr+ietf@sandelman.ca> wrote:

= Ulrich, thank for starting a new thread on this topic as I asked.

I am looking forward to understanding how we can do mesh-over networking without creating multi-link subnets.

It might just be that we need to always auto-configure /128 addresses on th= e
interfaces, and use /128 routes everywhere.
That's what my code does in order to implement multi-link subnets.

--
Michael Richardson <mcr+IETF@sa= ndelman.ca>, Sandelman Software Works



________________= _______________________________
Roll mailing list
Roll@ietf.org
https://w= ww.ietf.org/mailman/listinfo/roll


-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --B_3457679189_257412-- From bob.hinden@gmail.com Sun Jul 28 02:53:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF3C21F9C70 for ; Sun, 28 Jul 2013 02:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAeOAj0MEj8C for ; Sun, 28 Jul 2013 02:53:34 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC121F92B8 for ; Sun, 28 Jul 2013 02:53:31 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hq12so552499wib.14 for ; Sun, 28 Jul 2013 02:53:28 -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 :cc:to:mime-version:x-mailer; bh=GA/fywOO8kL/d06H9yWxz+93llZZx2rAWUvXBXQDXU0=; b=dZl1eOpaiuLfpOby+XMcs2DkmLLZrG2s1UsJVTy/ThOK3EdPsyGfsAb3tz+bEr2N6n 7DSBXehlHbk48JaAYfbG8QwWk8M/K5FLhw8bEWT21qlugSwZs6xjiIU8D5USp0cq8yez J8AwzlBTZbY0cqWzDpQjOzQ6ocJplWikGjG/zo97pdCdWobBQwWLFYFS5ZkvqKS0Q+2/ 1eFEHm8r+rEAIdniM7EZOov1bVwAndaXmYMYvSnRwuGCGNbYSiXWbY/ABPAfnLRa2Uoa CErfQMYwpIPzJ8g+VzIV6Z9220rasyQxUX4cMNIZ8VNMcXJCGCbdXI0oNRJBDTT/9SES Ax2A== X-Received: by 10.194.9.101 with SMTP id y5mr39670033wja.86.1375005208290; Sun, 28 Jul 2013 02:53:28 -0700 (PDT) Received: from ?IPv6:2001:df8::96:bcc1:127c:6575:8263? ([2001:df8:0:96:bcc1:127c:6575:8263]) by mx.google.com with ESMTPSA id li9sm15292050wic.2.2013.07.28.02.53.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 02:53:27 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Need Jabber Scribe and Minute Taker Date: Sun, 28 Jul 2013 11:53:26 +0200 Message-Id: <6238AB38-C46D-454F-967A-481CB87DB059@gmail.com> To: IPv6 IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 09:53:40 -0000 Welcome to Berlin, We still need a jabber scribe and minute taker for the 6man session on = Monday afternoon. Thanks, Bob & Ole From fernando@gont.com.ar Sun Jul 28 05:56:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E4D21F9D5A for ; Sun, 28 Jul 2013 05:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46nQXnDyHlD6 for ; Sun, 28 Jul 2013 05:56:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id A249C21F9D67 for ; Sun, 28 Jul 2013 05:56:49 -0700 (PDT) Received: from p3e9d372d.dip0.t-ipconnect.de ([62.157.55.45] helo=[192.168.101.225]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V3QWl-0002Sd-Az; Sun, 28 Jul 2013 14:56:47 +0200 Message-ID: <51F5150E.6020706@gont.com.ar> Date: Sun, 28 Jul 2013 14:56:46 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bob Hinden Subject: Re: Need Jabber Scribe and Minute Taker References: <6238AB38-C46D-454F-967A-481CB87DB059@gmail.com> In-Reply-To: <6238AB38-C46D-454F-967A-481CB87DB059@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 12:56:54 -0000 Hi, Bob, On 07/28/2013 11:53 AM, Bob Hinden wrote: > > We still need a jabber scribe and minute taker for the 6man session on Monday afternoon. I can take the minutes (albeit with a high reliance on the meeting recordings, since I'll be presenting and participating and, being a non-native English speaker, at times it gets hard to dynamically adapt :-) to the different accents). 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 bob.hinden@gmail.com Sun Jul 28 13:32:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4B21F9E44 for ; Sun, 28 Jul 2013 13:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4n9vXtZdEkX for ; Sun, 28 Jul 2013 13:32:33 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA3321F9E36 for ; Sun, 28 Jul 2013 13:32:32 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi8so452108wib.15 for ; Sun, 28 Jul 2013 13:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=bLu9H3blVyMe5OHrhJmhox58mzBSTmLUCihCPkZr8IU=; b=ZaDwdeqa+zHETpFB/nDvc5mlI4+fq82MmdoRnvaLlAkMMRMQ6+rEv7p/dWD04nQOl1 s3nYDIDg0WqD2cO50Y3pPg3OcQEyZG+cLY7BP096W9/JqU5RnzbaDt8dbQD9YVabtMcI 0w9/2jTfTdJZAWCJ9Pdx4CuograQM9zg7xhAVAhThPxZhJ1SEe8XPIJ1XponTMQ3MAF6 ou95gPm/Q2pr1VOgXXYyFhNfgyLqsD+/iIHZkPdIBlEcKewcJJOFjHNvloLvdAaLHarD ljNkEWSii/JT7rduYTkxKCle18SuHjCMDpYj3KW9J+IAbKLwIzP4aQw5hLJNr1S0IY2k lCDA== X-Received: by 10.194.9.101 with SMTP id y5mr40840656wja.86.1375043551081; Sun, 28 Jul 2013 13:32:31 -0700 (PDT) Received: from ?IPv6:2001:df8::64:c94:514:b2f1:a0d8? ([2001:df8:0:64:c94:514:b2f1:a0d8]) by mx.google.com with ESMTPSA id a6sm18313680wib.10.2013.07.28.13.32.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 13:32:28 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Need Jabber Scribe and Minute Taker From: Bob Hinden In-Reply-To: <51F5150E.6020706@gont.com.ar> Date: Sun, 28 Jul 2013 22:32:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F3DAF98-3E2F-43D3-95AE-E3E97BEF3E6D@gmail.com> References: <6238AB38-C46D-454F-967A-481CB87DB059@gmail.com> <51F5150E.6020706@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1508) Cc: IPv6 IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 20:32:33 -0000 Fernando, Thanks very much, it's very appreciated. Bob On Jul 28, 2013, at 2:56 PM, Fernando Gont wrote: > Hi, Bob, >=20 > On 07/28/2013 11:53 AM, Bob Hinden wrote: >>=20 >> We still need a jabber scribe and minute taker for the 6man session = on Monday afternoon. >=20 > I can take the minutes (albeit with a high reliance on the meeting > recordings, since I'll be presenting and participating and, being a > non-native English speaker, at times it gets hard to dynamically adapt > :-) to the different accents). >=20 > Cheers, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 From ietf@rozanak.com Mon Jul 29 04:25:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D5021F968B; Mon, 29 Jul 2013 04:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VDImv9b+4Ba; Mon, 29 Jul 2013 04:25:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id ACCF521F994C; Mon, 29 Jul 2013 04:24:59 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LmrMC-1UROwF28y4-00hZ7L; Mon, 29 Jul 2013 07:24:53 -0400 From: "Hosnieh Rafiee" To: , Subject: Meeting? Date: Mon, 29 Jul 2013 13:24:42 +0200 Message-ID: <000a01ce8c4e$3dc15060$b943f120$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CE8C5F.014BF520" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6MTiJceFbGaFm2S2KLOwlj8/xI7Q== Content-Language: en-us X-Provags-ID: V02:K0:sV7F02nh/giPdNYZ+Y7BP3MRijxsFmYFrbxT+DEzDDM HTlchdmXYW9bJjukEFehHntweJhBijxT4thyh+Azk7KAMYi9JJ Xq4sguqAHQV12VR3hg0TlgWb80Q4QJ8etS5trm1OJwRclyw2Bq 3rGK/HpXZORi/1DHf5HZXjPWa+n2qQfhkrqmrPhG/p1IG/9CH9 /okZUkC2+DsX4biLaWk+sdF2JoygZEXPgBcpK5QP6+q6xfToY5 ilvthnQ4yYElYNfRIYBAexaXYhMVNxt0RaFyfC01vyj+5S+kjh 0kh+gb/F9AZRk7K85cIagGonH2VetKAsoyhKviUWytUvZ008qZ DeB8Z0beQ3DEnBS1T8F8= Cc: Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:25:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000B_01CE8C5F.014BF520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to know whether you are available in IETF to meet and discuss about SSAS (http://tools.ietf.org/html/draft-rafiee-6man-ssas ). I created some slides for 6man however I am in "if the time permits" so that I am not sure I will be given a time slot to present it. Also if I have time slot, there is not much time for discussion. We think it is so important to clarify the purpose . You can see brief information about this draft here: http://tools.ietf.org/agenda/87/slides/slides-87-6man-6.pdf thanks, Best, Hosnieh ------=_NextPart_000_000B_01CE8C5F.014BF520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I would like = to know whether you are available in IETF to meet and discuss about SSAS = (http://tools.i= etf.org/html/draft-rafiee-6man-ssas ). I created some slides for = 6man however I am in “if the time permits” so that I am not = sure I will be given a time slot to present it. Also if I have time = slot, there is not much time for discussion. We think it is so important = to clarify the purpose . You can see brief information about this draft = here:

http= ://tools.ietf.org/agenda/87/slides/slides-87-6man-6.pdf

 

 

thanks,

Best,

Hosnieh

 

 

 

 

 

 

------=_NextPart_000_000B_01CE8C5F.014BF520-- From roland.bless@kit.edu Mon Jul 29 06:41:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF4221F9F9D for ; Mon, 29 Jul 2013 06:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euInK+QxH4mG for ; Mon, 29 Jul 2013 06:41:22 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6573121F9E80 for ; Mon, 29 Jul 2013 06:41:14 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1V3nh9-0004Pl-FP for ; Mon, 29 Jul 2013 15:41:13 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 57BE1A80701 for ; Mon, 29 Jul 2013 15:41:03 +0200 (CEST) Message-ID: <51F670EF.2070809@kit.edu> Date: Mon, 29 Jul 2013 15:41:03 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: 6man Subject: Re: 6MAN WG Last Call: References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1375105273.407177000 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:41:29 -0000 Hi, On 19.07.2013 00:11, Bob Hinden wrote: > http://tools.ietf.org/html/draft-ietf-6man-ug-01 > > as a Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the author. This last call will end on 1 August 2013. Support to advance. Minor comment: I found the last statements in section 4 slightly confusing: There is no algorithm for determining whether this case has arisen, rather than a genuine MAC address collision. Implementers should carefully consider the consequences of continuing IPv6 operation on the interface in this unlikely situation. 1.) DAD should actually detect that collision 2.) Continuing IPv6 operation with different addresses may be fine, but I don't see any reason to continue operation with the colliding address (or wasn't that what you meant?). Regards, Roland From ietf@rozanak.com Mon Jul 29 07:16:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FD311E80EC for ; Mon, 29 Jul 2013 07:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9+cL+pT6+4M for ; Mon, 29 Jul 2013 07:16:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C4DE221F8934 for ; Mon, 29 Jul 2013 07:16:34 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MWkmh-1UaoBo3lBj-00XQrH; Mon, 29 Jul 2013 10:16:33 -0400 From: "Hosnieh Rafiee" To: Subject: draft ra-privacy - please send me your comments Date: Mon, 29 Jul 2013 16:16:27 +0200 Message-ID: <000f01ce8c66$3955f310$ac01d930$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CE8C76.FCDFAD70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6MZfCrl3SfEtzDRrCzE15gmN+vxA== Content-Language: en-us X-Provags-ID: V02:K0:iNYirMptrqz21oObRRn+MjDIBkQ6WxA11d4T83UZw6e d463hJp2P91VwgPEZD2zgd4ar/gmVI+9owN00qhZQMRD2UCcSN 5gn+ejWfuz+gm3aTHf1LUEqz142GqjP5YC/GL0pdojA3ak/3Zs G4ODDcI2k9xYOwNusuHSnEUF5Hvr6TscpqEwasV1h7uyc6I0qn QCUQM880+AeJrWrBDIBazyq6x+jaRFUHaTonaDu5eATy3fMEci E6x6d5rAmGyPMTNPIPRYTRwa8N6shbV+VhjP1YV15ytytYTFa6 iPj0JplLtTUFn8qvRK4o+XDixUsurUTPMTPNV4VVy7IiTNchEx +FVOJwk7vGlvgfI/Vjn4= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:16:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0010_01CE8C76.FCDFAD70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Would you please send us your comments so that I can answer them or consider them. There was not time to respond all of them or to use the comments improving the draft. Thank you, Best, Hosnieh ------=_NextPart_000_0010_01CE8C76.FCDFAD70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Would you = please send us your comments so that I can answer them or consider them. = There was not time to respond all of them or to use the comments = improving the draft.

 

Thank = you,

Best,

Hosnieh

------=_NextPart_000_0010_01CE8C76.FCDFAD70-- From fred@cisco.com Mon Jul 29 07:33:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567C921F9BC4 for ; Mon, 29 Jul 2013 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DedTG+tb5kwj for ; Mon, 29 Jul 2013 07:33:22 -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 E0F3721F9E43 for ; Mon, 29 Jul 2013 07:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=489; q=dns/txt; s=iport; t=1375108370; x=1376317970; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mildcqd5V1LnllmoxZjcUTPBGn1o4nTrJIrz1lkKQUA=; b=kocuir7hTc2eTevmoz6invToAAtJeaHej3lHhkPDIIQjk6BHnd1FNVmb 8nfzMLoyXted5I0X85hCZg86rSSwlq7jxUMIXTeC7qCXE3vi8aIJU7LXb ZmIYUJe5FTvK0WS80o4YSO5DehMdzs2Tt13a62n1igt4//dzwUu44ATdI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAPx79lGtJXG+/2dsb2JhbABbgwaBBb1YgRcWdIImAQQ6UQEqFEInBBuICJgDoDSPTINQbwOMQIdIimyKN4MUgio X-IronPort-AV: E=Sophos;i="4.89,770,1367971200"; d="scan'208";a="240826872" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jul 2013 14:32:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6TEWk8d020926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Jul 2013 14:32:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 09:32:45 -0500 From: "Fred Baker (fred)" To: IPv6 Maintanence Subject: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjGh+iYfnka6nOUeBop7mpmo4Zg== Date: Mon, 29 Jul 2013 14:32:45 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.196.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:33:36 -0000 At the mike a moment ago, I referred to an existing formal definition of "d= eprecate". For the record, the reference is to RFC 1158, which reads: 3.1. Deprecated Objects In order to better prepare implementors for future changes in the MIB, a new term "deprecated" may be used when describing an object. A deprecated object in the MIB is one which must be supported, but one which will most likely be removed from the next version of the MIB (e.g., MIB-III).= From jouni.nospam@gmail.com Mon Jul 29 10:37:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C7C11E80E0 for ; Mon, 29 Jul 2013 10:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmcUku8Kcqvi for ; Mon, 29 Jul 2013 10:37:06 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8022221F9956 for ; Mon, 29 Jul 2013 10:36:34 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so1611422pbc.9 for ; Mon, 29 Jul 2013 10:36:11 -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:message-id:date :to:mime-version:x-mailer; bh=JEoSvHSKo0xSyUysQxwLMHHJZJ0DR1TcbtMflsIp1v0=; b=nznFUaTxHfv6PCXOaEq8BUka9UXO7s5iJtUNO2PxK4tws8X9D0JJVM2tazw4PlR7Xs RBVcRQpd5zsnQ4Uc9wLctT0KIANVUhC24/cIrsGb7/pcTHE/TTiFza2ACBrWN9PICC5R Iil04Bd1Nxyt2V1zzpnP4vYzXGcgthyZD1DeIpNGez49aieM5437N0mbPyKeqCHNE5br Qb3J7V5xW/BaUkgUo9Kyk3lTKT7hFnwo1tOXwYgrxZaxTs1e2yorAsHD2BEfRH8WodKJ jbgMcFAtM5lV9JmKmOG5CuQ0K3AvWauo9EvHDjKJUUB4JWKTFR5bNA1vFfFCkcRVhySq XIrw== X-Received: by 10.66.155.36 with SMTP id vt4mr30684808pab.93.1375119371080; Mon, 29 Jul 2013 10:36:11 -0700 (PDT) Received: from ?IPv6:2001:df8::80:81e:f417:1651:ba26? ([2001:df8:0:80:81e:f417:1651:ba26]) by mx.google.com with ESMTPSA id r7sm21973008pao.18.2013.07.29.10.36.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 10:36:10 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: comments on draft-chakrabarti-nordmark-6man-efficient-nd-02 Message-Id: <7A443800-AD78-4B9A-B566-F994CA29314B@gmail.com> Date: Mon, 29 Jul 2013 20:36:06 +0300 To: IPv6 IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:37:10 -0000 X-List-Received-Date: Mon, 29 Jul 2013 17:37:10 -0000 Hi, Just to restate what I said on the microphone. Section 7.1. says: When the ARO is used by hosts an SLLA option MUST be included and the address that is to be registered MUST be the IPv6 source address of the Neighbor Solicitation message. What about link that do not have link-layer addresses? This specifically caught my attention since the draft uses 3GPP as a motivational use case (see Annex A.5.). Those links do not have link layer addresses. I think this part needs to be corrected/clarified.. Also, in Annex A.5. it says: Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays silent about periodic RA. Though the informational drafts and It is correct that the referenced documents are silent (they do not require or prohibit) about periodic RAs. However, 3GPP TS29.061, i.e. stage-3 that deals with the implementation level details, defines in sub-clause 11.2.1.3.4 values for MaxRtrAdvInterval (recommendation is 21600s i.e. 6h) and MinRtrAdvInterval. Also, stage-3 even uses language such as: "After the GGSN has sent a Create PDP Context Response message to the SGSN, it shall start sending Router Advertisements periodically on the new MS-GGSN link established by the PDP Context". This needs to be corrected in the draft. - Jouni From bob.hinden@gmail.com Mon Jul 29 09:49:42 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803A121E8097 for ; Mon, 29 Jul 2013 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 ohvpFGQjfswy for ; Mon, 29 Jul 2013 09:49:30 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 674BF21E80AC for ; Mon, 29 Jul 2013 09:47:41 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hq12so1745909wib.8 for ; Mon, 29 Jul 2013 09:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pTh45BBUkmHW5k8lXjLKSoaEwht1pnifTDP3SXoh1Is=; b=r0mfVSOHEbYXm8enGtfKdv/mp86kaW+S4P9mqEQBBSmcAtcoY6FjpbcYtaPL4+7PWh h4KIdq+ltJn76HXpn3w2NLDZvVjYwnISvp/FimprDiCkWnLVisqb38a2+KXmW3uhNVre pZgu8+lTpLjpZ+xIxaj0uw4zMq7AWJ7h+YRqum4Dkmml+jciCN3CUkwJH5eYvowaLExZ 2QWZdgcJZ8bezqAaCf5Li+mcKvqFFoj8zrwcL1lb5WAMhjDrU5T54sGO+Svxq4P5P3WK CIuWHUf82Eo/+f+dbNJwvIHpcYFYkPbw0hXvCf3fAcu/4nda7PbHKL66FDlPc1C/7Gj2 HvbQ== X-Received: by 10.180.82.196 with SMTP id k4mr7965278wiy.0.1375116459142; Mon, 29 Jul 2013 09:47:39 -0700 (PDT) Received: from dhcp-24bc.meeting.ietf.org (dhcp-24bc.meeting.ietf.org. [130.129.36.188]) by mx.google.com with ESMTPSA id ev19sm23752163wid.2.2013.07.29.09.47.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 09:47:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: draft ra-privacy - please send me your comments From: Bob Hinden In-Reply-To: <000f01ce8c66$3955f310$ac01d930$@rozanak.com> Date: Mon, 29 Jul 2013 18:47:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49BF4168-78E7-4B4F-963A-5C041E303986@gmail.com> References: <000f01ce8c66$3955f310$ac01d930$@rozanak.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1508) Cc: ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 16:49:46 -0000 Hosnieh, You can watch/listen to the comments again from the Meetecho recording. = It will be available at: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions Bob On Jul 29, 2013, at 4:16 PM, Hosnieh Rafiee wrote: > Hello, > =20 > Would you please send us your comments so that I can answer them or = consider them. There was not time to respond all of them or to use the = comments improving the draft. > =20 > Thank you, > Best, > Hosnieh > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Mon Jul 29 13:51:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9469711E8131 for ; Mon, 29 Jul 2013 13:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 p3nktjj0fLLW for ; Mon, 29 Jul 2013 13:51:16 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BEEB711E8147 for ; Mon, 29 Jul 2013 13:51:02 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 3so4873693pdj.33 for ; Mon, 29 Jul 2013 13:51: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=sqINNXfvh/xcyc563z5rMu2UGBCiZddc8JwPCEwAJiQ=; b=R9D3mIq/leF77lKZLczRtYfjWiXCKgTq3YJh8X1ezpVx/xB8qrWZI33VPKG82eXR4V nkvGEDem9qh8GeHc4gFqPUJOUwEbpeq70yNM9hn9twc/pFPigjY299Dz6Ak1w73uYHep vx9kRIl04ziPQdTYrjJ/aN1wdLiOIvUpbqbO0UD+is8kreai79n3RdtCj6z8sWxu/sbD X/ZHY14etTY7jHQ5itBax3QSF9dv10U5oN6UfMoLKptUyxdCnLAWYlZZy0nbW91y5Osy ZilWmGOJn9HwNHQdgJaVORoQTlARIyX9KwK43nYeuScxy5CSx5Yyas0UuhrsYj2MXIoU rLJg== X-Received: by 10.68.180.1 with SMTP id dk1mr71017528pbc.174.1375131062453; Mon, 29 Jul 2013 13:51:02 -0700 (PDT) Received: from [192.168.178.23] (225.199.69.111.dynamic.snap.net.nz. [111.69.199.225]) by mx.google.com with ESMTPSA id ue9sm22683812pab.7.2013.07.29.13.51.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 13:51:01 -0700 (PDT) Message-ID: <51F6D5B1.2010208@gmail.com> Date: Tue, 30 Jul 2013 08:50:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roland Bless Subject: Re: 6MAN WG Last Call: References: <51F670EF.2070809@kit.edu> In-Reply-To: <51F670EF.2070809@kit.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:51:18 -0000 Roland, On 30/07/2013 01:41, Roland Bless wrote: > Hi, > On 19.07.2013 00:11, Bob Hinden wrote: >> http://tools.ietf.org/html/draft-ietf-6man-ug-01 >> >> as a Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the author. This last call will end on 1 August 2013. > > Support to advance. > > Minor comment: > I found the last statements in section 4 slightly confusing: > There is no algorithm > for determining whether this case has arisen, rather than a genuine > MAC address collision. Implementers should carefully consider the > consequences of continuing IPv6 operation on the interface in this > unlikely situation. > > 1.) DAD should actually detect that collision Yes, but it cannot detect the cause. > 2.) Continuing IPv6 operation with different addresses may be fine, but > I don't see any reason to continue operation with the colliding > address (or wasn't that what you meant?). You are correct and the text is confusing - see the earlier comments from Tatuya explaining the intention of RFC 4862. Brian > > Regards, > Roland > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From randy@psg.com Mon Jul 29 20:19:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A922011E81A9 for ; Mon, 29 Jul 2013 20:19:32 -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.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9qG0GRc5l21 for ; Mon, 29 Jul 2013 20:19:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id 79E9421F99A6 for ; Mon, 29 Jul 2013 20:19:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1V40T4-0003P2-9R; Tue, 30 Jul 2013 03:19:22 +0000 Date: Tue, 30 Jul 2013 05:19:21 +0200 Message-ID: From: Randy Bush To: "Fred Baker (fred)" Subject: Re: "Deprecate" In-Reply-To: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Maintanence X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 03:19:32 -0000 > At the mike a moment ago, I referred to an existing formal definition > of "deprecate". welll, you keep saying it is a formal definition, implying that it applies to all uses of the term. but, in fact, the reference is merely how it is used in some snmp glorp. otoh, the draft under abuse, could indeed be more specific. randy From ietf@rozanak.com Mon Jul 29 22:12:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686CE21F9FF2 for ; Mon, 29 Jul 2013 22:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCkVlwf-UTXY for ; Mon, 29 Jul 2013 22:12:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 697E421F9F80 for ; Mon, 29 Jul 2013 22:12:51 -0700 (PDT) Received: from kopoli (g225090058.adsl.alicedsl.de [92.225.90.58]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lhw5K-1UHHAI3gCw-00nBlp; Tue, 30 Jul 2013 01:12:46 -0400 From: "Hosnieh Rafiee" To: "Fernando Gont" , "Dave Thaler" , "'Keith Moore'" Subject: ra-privacy: my responses to comments Date: Tue, 30 Jul 2013 07:12:34 +0200 Message-ID: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CE8CF4.2EF5E9A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6M42Zv8rHi+G3WSOykdHu+MG/EzQ== Content-Language: en-us X-Provags-ID: V02:K0:/oD4Ts6ZRxrYmZ32jDANOOXY8cSRrfNGVAN7jg41tJY +RH2ndkWXXLwpHOUV2EFj/g6a1wnXCacg4yu6FxmftSQPyj7yS JZcnWnsEShb+5TkgiyyxZks5tU4vC/hHhSWgFCb/oxrQayuoFs XEoAft0BLTdQ0VsbWCMNHMZJxW70HSWWP9HQFWqJzP1rqmbL20 QQCfOAMqT1i9iRDZBkjUmgt1hZ62JX77cMk1ch3jXhFAg+imVR dH68Rxv0Su+/gbwtKdnSv3LsLWxw28pKyCFHVM11NK5QMLjI9o O8PBBLLAWA/6b7stI3Rr0V0tZdCD38qd/Tbd6qxoMbnoXWvfor oU4LZ/QLnDmHPXBY6JA0= Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 05:12:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0016_01CE8CF4.2EF5E9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, Many thanks to the people who commented on my draft. Here are my responses. There was not enough time to respond to all comments and it was difficult to discern and follow the comments one by one from the audio tape. I had to listen to the audio repeatedly before I could put the context of the comment together with the subject of the slide. To clarify, I used public addresses because other people on the mailing list used this term. --------------------------------- Response to comments related to Lifetime of the IID: @Fernando: Concerns: we will have thousands of IIDs if we want to generate a new IID for each application Answer: There are some variables to be considered when maintaining the lifetime of the IID. One such variable is the maximum number of IIDs. The maximum number of applications per IID and the maximum lifetime of the IID. If the IID expires, it will keep its current connections but will not be able to be used for new connections. If a node starts an application x, then it checks whether or not any IIDs are available whose lifetime has not yet expired. If there is/are, then it sorts them based on their lifetime and assign it/them to the IID with the longest lifetime. If there is no IID available and the maximum number of IIDs has been reached, then increase the maximum number of applications (variable keeps this amount) for a specific IID with the longest lifetime. If there is no IID available, but the maximum number of IIDs is NOT reached, then generate a new IID and assign this application to it. For more information please refer to the draft. @Keith Moore: Concerns: Some applications can just use a different address for every new application while other applications cannot, such as peer to peer, because they would encounter a problem. Answer: I assume that it is dependent on the implementation. This means, for instance, that we can assume that we would have 1 IID for Internet explorer and 1 IID for all sessions that were opened by one peer to peer application. It is possible for me to clarify it in the draft by explaining how to assign a new application to a new IID , just as I have explained with these two examples. @Dave Thaler: Concerns: Why we did not mention application layer? Is it because we will have a large number of addresses? Answer: If you do not have some kind of variable to control the lifetime, the maximum number of IIDs and the maximum number of application per IID (as I explained a part of that algorithm to Fernando), then your concern is valid. But if we consider the use of the algorithm mentioned in the draft. then It is not valid. There was not enough time to discuss the whole application layer algorithm in the 6man (as I had to spend 3 to 5 minutes just explaining it). If you are still having concerns, please share them here. Concerns: The large numbers of sessions and everyone requiring a separate neighbor discovery multicast address so this blows your multicast [...] So, the bottom line is it is not scalable. Answer: True and not true, This is because it depends on how you set the maximum number of IIDs. If you set its default value in your network to something like 5 or 10 or, an in general, a small number, then this will never happen. I guess this is an issue with network policy as in my draft I considered setting the default values by use of the option in the router advertisement which can be set by the admins of each network. Concerns: This lifetime issue should be in another draft and considered in a separate document. Answer: If the others feel this way, then I will do it. The reason it appears in this document is becauses because I wanted to address the problem of cutting the connection when the lifetime of an IID has expired. Concerns: Slide 5, we should use large stable storage. Answer: It is a wording issue. I guess we already discussed this offline. Instead of "already assigned" http://tools.ietf.org/html/rfc4941#section-3.2.1 step 4, we need to clarify it as defined here http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04#section-4 @ I could not understand the name :( : In this proposal the number of addresses in a host increase dramatically. So I feel that if we are specifying that kind of mechanism, the we should also specify what happens if the network cannot accommodate them. If you have so many addresses, in some cases you won't have connectivity. There are too many addresses to be able to protect the neighbor discovery cache. Answer: I would improve the document and try to address this as well. However, I do not presume that this will happen, based on the responses I received from the other people here. -------------------------------------------------- The term public addresses: @Keith Moore: Concerns: All IPv6 addresses are public addresses and should be available. Not chosen a good term. I just obtained that term from from the mailing list. Check this old list : http://www.ietf.org/mail-archive/web/ipv6/current/msg17792.html A public address is one intended to be resolvable from higher-layer IDs such as DNS names. If this is wrong or I misunderstood the meaning , then I will change it to "DNS addresses" or another term. What I knew before: Global addresses = Router prefix + IID Local Addresses = local prefix + IID What I understood: Public addresses = router prefix + IID and has DNS records (like a domain) ------------------------------------------ Security and Network Policy @ I could not understand the name :( : Question about this section of slide "if a user visit a website and harms by a cookie then we need to change the IID". Do you think this is security mechanism to do this? I do not consider to have a policy for the network. Answer: I meant http cookies or server side cookies. Because client side cookies can be harmful if there is a script from a website that might access the other cookies in your computer. This was just one reason to change the IID addresses within and outside of the network. There is nothing mentioned about this directly in the draft. I probably didn't express this idea correctly so you had a misconception of what I was trying to say. If there are any more issues that I need to concern please leave your comment here. Thank you, Best, Hosnieh ------=_NextPart_000_0016_01CE8CF4.2EF5E9A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi =  All,

 

Many thanks to  the people who commented on my = draft.

Here are my responses. There = was not enough time to respond to all comments and it was difficult to = discern and follow the comments one by one from the audio tape. I had to = listen to the audio repeatedly before I could put the context of the = comment together with the subject of the slide.

 

To clarify, = I used public addresses because other people on the mailing list used = this term.

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

Response to comments related to Lifetime of the = IID:

@Fernando:

Concerns: we will have thousands of IIDs if we want to = generate a new IID for each application

 

Answer:

There are = some variables to be considered when maintaining the lifetime of the = IID. One  such variable is the maximum number of IIDs. The maximum = number of applications per IID and the maximum lifetime of the IID. If = the IID expires, it will keep its current connections but will not be = able to be used for new connections. If a node starts an application x, = then it checks whether or not any IIDs are available whose lifetime has = not yet expired. If there is/are, then it sorts them based on their = lifetime and assign it/them to the IID with the longest lifetime. =

If there is no IID available and the = maximum number of IIDs has been reached, then increase the maximum = number of applications (variable keeps this amount) for a specific IID = with the longest lifetime.

If there = is no IID available, but the maximum number of IIDs is NOT reached, then = generate a new IID and assign this application to it. For more = information please refer to the draft.

 

@Keith =
Moore:

Concerns: = Some applications can just use a different address for every new = application while other applications cannot, such as peer to peer, = because they would encounter a problem.

 = ;

Answer: =

I assume = that it is dependent on the implementation. This means, for instance, = that we can assume that we would have 1 IID for Internet explorer and 1 = IID for all sessions that were opened by one peer to peer application. = It is possible for me to clarify it in the draft by explaining how to = assign a new application to a new IID , just as I have explained with = these two examples.

 = ;

@Dave = Thaler:

Concerns: = Why we did not mention application layer? Is it because we will have a = large number of addresses?

 = ;

Answer: = If you do not have some kind of variable to control the lifetime, the = maximum number of IIDs and the maximum number of application per IID (as = I explained a part of that algorithm to Fernando), then your concern is = valid. But if we consider the use of the algorithm mentioned in the = draft. then It is not valid. There was not enough time to discuss the = whole application layer algorithm in the 6man (as I had to spend 3 to 5 = minutes just explaining it). If you are still  having concerns, = please share them here.

 = ;

Concerns: = The large numbers of sessions and everyone requiring a separate neighbor = discovery multicast address so this blows your multicast [...] So, the = bottom line is it is not scalable.

 = ;

Answer: = True and not true, This is because it depends on how you set the maximum = number of IIDs. If you set its default value in your network to = something like 5 or 10 or, an in general, a small number, then this will = never happen. I guess this is an issue with network policy as in my = draft I considered setting the default values by use of the option in = the router advertisement which can be set by the admins of each = network.

 = ;

Concerns: = This lifetime issue should be in another draft and considered in a = separate document.

 = ;

Answer: = If the others feel this way, then I will do it.  The reason it = appears in this document is becauses because I wanted to address the = problem of cutting the connection when the lifetime of an IID has = expired.

 

Concerns: = Slide 5, we should use large stable = storage.

 = ;

Answer: = It is a wording issue. I guess we already discussed this offline. = Instead of “already assigned” http://tools.ie= tf.org/html/rfc4941#section-3.2.1 step 4, we need to clarify it as = defined here

http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04#section-4=

 

@ I could not understand the name  :(  : =  In this proposal the number of addresses in a host increase = dramatically. So I feel that if we are specifying that kind of = mechanism, the we should also specify what happens if the network cannot =  accommodate them. If you have so many addresses, in some cases you = won’t have connectivity. There are too many addresses to be able = to protect the neighbor discovery cache.

 

Answer: I = would improve the document and try to address this as well. However, I = do not presume that this will happen, based on the responses I received = from the other people here.

 

--------------------------------------------------=

The term public = addresses:

@Keith = Moore:

Concerns: = All IPv6 addresses are public addresses and should be available. Not = chosen a good term.

 = ;

I just = obtained that term from from the mailing list. Check this old list : = http://www.ietf.org/mail-archive/web/ipv6/current/msg17792.html = 

A public address is one intended to be =
resolvable from higher-layer IDs such as DNS =
names.
If this is wrong or I =
misunderstood the meaning , then I will change it to “DNS =
addresses” or another term. =
 
What I knew =
before:
Global addresses =3D Router =
prefix + IID
Local Addresses =3D local =
prefix + IID
What I =
understood:
Public addresses =3D router =
prefix + IID  and has  DNS records (like a =
domain)
 
----------------------------=
--------------
Security and Network =
Policy
@ I could =
not understand the name  :(   : Question about this section of =
slide “if a user visit a website and harms by a cookie then we =
need to change the IID”. Do you think this is security mechanism =
to do this? I do not consider to have a policy for the =
network.
 
Answer: I meant http cookies or server side cookies. =
Because client side cookies can be harmful if there is a script from a =
website that might access the other cookies in your computer.  This =
was just one reason to change the IID addresses within and outside of =
the network. There is nothing mentioned about this directly in the =
draft. I probably didn't express this idea correctly so you had a =
misconception of what I was trying to say.  =

 
 
If there are any more issues that I need to =
concern please leave your comment here.
 
Thank =
you,
Best,
Hosnieh
 
 
------=_NextPart_000_0016_01CE8CF4.2EF5E9A0-- From bob.hinden@gmail.com Mon Jul 29 23:17:27 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A7421F9D45 for ; Mon, 29 Jul 2013 23:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 0hv3nvBpxLY8 for ; Mon, 29 Jul 2013 23:17:26 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2B421F9BC9 for ; Mon, 29 Jul 2013 23:17:26 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id d49so956358eek.34 for ; Mon, 29 Jul 2013 23:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0yLMnQCSacbrKPHXOEXOfYxtRF24nmi5cEFZrTt2zsU=; b=QjYOpIWMbRzfpGPW00fuuC8mxmQf4o89RvPl/7cQYvYu2QubmazJCY46195vnWX+vp zQjsoSYnu50ijELFB+zdMSTTsC9qt48cjEQukj52xZ08XMcMKthP8k83zHG+zP22fxrQ YZ070MkMJuFjp6Q3gp1kMPdu62gyfK8pQTbJrl86xadWTYzECeTa0n3Ukpcyyis5HKQX yc51kddNZMhCykqDjypDhXsN84/omhVxi2LDCwDQd27EuqE/IZ2j3NbIvSRjygEofOJh JAu6JOwtkSDXXZ5LulFAxRO92QVaUxtRs44MUrBFshD63ebog+AuS4cAA9GEWxOHqQOX Tr1g== X-Received: by 10.14.9.70 with SMTP id 46mr54672167ees.44.1375165045441; Mon, 29 Jul 2013 23:17:25 -0700 (PDT) Received: from dhcp-40f1.meeting.ietf.org (dhcp-40f1.meeting.ietf.org. [130.129.64.241]) by mx.google.com with ESMTPSA id j2sm31302099eep.6.2013.07.29.23.17.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 23:17:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: "Deprecate" From: Bob Hinden In-Reply-To: Date: Tue, 30 Jul 2013 08:17:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1508) Cc: IPv6 Maintanence , Bob Hinden , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:17:27 -0000 On Jul 30, 2013, at 5:19 AM, Randy Bush wrote: >> At the mike a moment ago, I referred to an existing formal definition >> of "deprecate". >=20 > welll, you keep saying it is a formal definition, implying that it > applies to all uses of the term. but, in fact, the reference is = merely > how it is used in some snmp glorp. A example of deprecation that is close to what we are discussing = regarding fragmentation can be found in: RFC3879 Deprecating Site Local Addresses 4. Deprecation This document formally deprecates the IPv6 site-local unicast prefix defined in [RFC3513], i.e., 1111111011 binary or FEC0::/10. The special behavior of this prefix MUST no longer be supported in new implementations. The prefix MUST NOT be reassigned for other use except by a future IETF standards action. Future versions of the addressing architecture [RFC3513] will include this information. However, router implementations SHOULD be configured to prevent routing of this prefix by default. Bob >=20 > otoh, the draft under abuse, could indeed be more specific. >=20 > randy > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From randy@psg.com Mon Jul 29 23:53:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C3D11E81BB for ; Mon, 29 Jul 2013 23:53:13 -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.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYGGo6RT+8LC for ; Mon, 29 Jul 2013 23:53:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id B861D21F9BC3 for ; Mon, 29 Jul 2013 23:53:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1V43nl-00054L-OI; Tue, 30 Jul 2013 06:52:58 +0000 Date: Tue, 30 Jul 2013 08:52:57 +0200 Message-ID: From: Randy Bush To: Bob Hinden Subject: Re: "Deprecate" In-Reply-To: <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Maintanence , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:53:25 -0000 > A example of deprecation that is close to what we are discussing > regarding fragmentation can be found in: > > This document formally deprecates the IPv6 site-local unicast prefix > defined in [RFC3513], i.e., 1111111011 binary or FEC0::/10. The > special behavior of this prefix MUST no longer be supported in new > implementations. hmmm. i am gonna put my foot in the cow pie. i think what we want here is something close to o future implementations SHOULD not generate frags (note that SHOULD != MUST) o expect to receive frags for a long time randy From zhou.sujing@zte.com.cn Tue Jul 30 01:22:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6162521F96A7; Tue, 30 Jul 2013 01:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyz-epBIQvIT; Tue, 30 Jul 2013 01:21:51 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B33A921F92A5; Tue, 30 Jul 2013 01:21:20 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id D0D6F31D3D; Tue, 30 Jul 2013 16:20:40 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 869C9CE9240; Tue, 30 Jul 2013 16:20:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r6U8KhtC036678; Tue, 30 Jul 2013 16:20:43 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> To: "Hosnieh Rafiee" Subject: Re: ra-privacy: my responses to comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 30 Jul 2013 16:20:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-30 16:20:29, Serialize complete at 2013-07-30 16:20:29 Content-Type: multipart/alternative; boundary="=_alternative 002DF01A48257BB8_=" X-MAIL: mse01.zte.com.cn r6U8KhtC036678 Cc: ipv6-bounces@ietf.org, ipv6@ietf.org, Fernando Gont , Dave Thaler , 'Keith Moore' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:22:11 -0000 This is a multipart message in MIME format. --=_alternative 002DF01A48257BB8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFJhZmllZSwNCiAgICBJIGRvbid0IHRoaW5rIHVzaW5nIENHQSBieSByZXBsYWNpbmcgdGhl IHB1YmxpYyBrZXkgd2l0aCBhIHRpbWVzdGFtcCANCm9yIG90aGVyIHJhbmRvbSBzdHJpbmcgaXMg YSAiaGlnaGVyIHJhbmRvbXphdGlvbiIgYWRkcmVzcyBnZW5lcmF0aW9uIA0KbWV0aG9kLg0KSGFz aCBpcyBvbmx5IG9uZSB0ZWNobmlxdWUgb2YgZ2VuZXJhdGluZyBhIHJhbmRvbSBsaWtlIHN0cmlu ZywgbWF5IG5vdCBiZSANCnRoZSBiZXN0IG9uZSBhbW9uZyB0aG9zZSBzcGVjaWZpZWQgaW4gUkZD NDA4Ni4NCg0KDQoNCg0KDQppcHY2LWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTA3LTMwIDEz OjEyOjM0Og0KDQo+IEhpICBBbGwsDQo+IA0KPiBNYW55IHRoYW5rcyB0byAgdGhlIHBlb3BsZSB3 aG8gY29tbWVudGVkIG9uIG15IGRyYWZ0LiANCj4gSGVyZSBhcmUgbXkgcmVzcG9uc2VzLiBUaGVy ZSB3YXMgbm90IGVub3VnaCB0aW1lIHRvIHJlc3BvbmQgdG8gYWxsIA0KPiBjb21tZW50cyBhbmQg aXQgd2FzIGRpZmZpY3VsdCB0byBkaXNjZXJuIGFuZCBmb2xsb3cgdGhlIGNvbW1lbnRzIG9uZQ0K PiBieSBvbmUgZnJvbSB0aGUgYXVkaW8gdGFwZS4gSSBoYWQgdG8gbGlzdGVuIHRvIHRoZSBhdWRp byByZXBlYXRlZGx5IA0KPiBiZWZvcmUgSSBjb3VsZCBwdXQgdGhlIGNvbnRleHQgb2YgdGhlIGNv bW1lbnQgdG9nZXRoZXIgd2l0aCB0aGUgDQo+IHN1YmplY3Qgb2YgdGhlIHNsaWRlLiANCj4gDQo+ IFRvIGNsYXJpZnksIEkgdXNlZCBwdWJsaWMgYWRkcmVzc2VzIGJlY2F1c2Ugb3RoZXIgcGVvcGxl IG9uIHRoZSANCj4gbWFpbGluZyBsaXN0IHVzZWQgdGhpcyB0ZXJtLiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFJlc3BvbnNlIHRvIGNvbW1lbnRzIHJlbGF0ZWQgdG8g TGlmZXRpbWUgb2YgdGhlIElJRDoNCj4gQEZlcm5hbmRvOiANCj4gQ29uY2VybnM6IHdlIHdpbGwg aGF2ZSB0aG91c2FuZHMgb2YgSUlEcyBpZiB3ZSB3YW50IHRvIGdlbmVyYXRlIGEgDQo+IG5ldyBJ SUQgZm9yIGVhY2ggYXBwbGljYXRpb24NCj4gDQo+IEFuc3dlcjoNCj4gVGhlcmUgYXJlIHNvbWUg dmFyaWFibGVzIHRvIGJlIGNvbnNpZGVyZWQgd2hlbiBtYWludGFpbmluZyB0aGUgDQo+IGxpZmV0 aW1lIG9mIHRoZSBJSUQuIE9uZSAgc3VjaCB2YXJpYWJsZSBpcyB0aGUgbWF4aW11bSBudW1iZXIg b2YgDQo+IElJRHMuIFRoZSBtYXhpbXVtIG51bWJlciBvZiBhcHBsaWNhdGlvbnMgcGVyIElJRCBh bmQgdGhlIG1heGltdW0gDQo+IGxpZmV0aW1lIG9mIHRoZSBJSUQuIElmIHRoZSBJSUQgZXhwaXJl cywgaXQgd2lsbCBrZWVwIGl0cyBjdXJyZW50IA0KPiBjb25uZWN0aW9ucyBidXQgd2lsbCBub3Qg YmUgYWJsZSB0byBiZSB1c2VkIGZvciBuZXcgY29ubmVjdGlvbnMuIElmIA0KPiBhIG5vZGUgc3Rh cnRzIGFuIGFwcGxpY2F0aW9uIHgsIHRoZW4gaXQgY2hlY2tzIHdoZXRoZXIgb3Igbm90IGFueSAN Cj4gSUlEcyBhcmUgYXZhaWxhYmxlIHdob3NlIGxpZmV0aW1lIGhhcyBub3QgeWV0IGV4cGlyZWQu IElmIHRoZXJlIA0KPiBpcy9hcmUsIHRoZW4gaXQgc29ydHMgdGhlbSBiYXNlZCBvbiB0aGVpciBs aWZldGltZSBhbmQgYXNzaWduIA0KPiBpdC90aGVtIHRvIHRoZSBJSUQgd2l0aCB0aGUgbG9uZ2Vz dCBsaWZldGltZS4gDQo+IElmIHRoZXJlIGlzIG5vIElJRCBhdmFpbGFibGUgYW5kIHRoZSBtYXhp bXVtIG51bWJlciBvZiBJSURzIGhhcyBiZWVuDQo+IHJlYWNoZWQsIHRoZW4gaW5jcmVhc2UgdGhl IG1heGltdW0gbnVtYmVyIG9mIGFwcGxpY2F0aW9ucyAodmFyaWFibGUgDQo+IGtlZXBzIHRoaXMg YW1vdW50KSBmb3IgYSBzcGVjaWZpYyBJSUQgd2l0aCB0aGUgbG9uZ2VzdCBsaWZldGltZS4NCj4g SWYgdGhlcmUgaXMgbm8gSUlEIGF2YWlsYWJsZSwgYnV0IHRoZSBtYXhpbXVtIG51bWJlciBvZiBJ SURzIGlzIE5PVCANCj4gcmVhY2hlZCwgdGhlbiBnZW5lcmF0ZSBhIG5ldyBJSUQgYW5kIGFzc2ln biB0aGlzIGFwcGxpY2F0aW9uIHRvIGl0LiANCj4gRm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNl IHJlZmVyIHRvIHRoZSBkcmFmdC4NCj4gDQo+IEBLZWl0aCBNb29yZTogDQo+IENvbmNlcm5zOiBT b21lIGFwcGxpY2F0aW9ucyBjYW4ganVzdCB1c2UgYSBkaWZmZXJlbnQgYWRkcmVzcyBmb3IgDQo+ IGV2ZXJ5IG5ldyBhcHBsaWNhdGlvbiB3aGlsZSBvdGhlciBhcHBsaWNhdGlvbnMgY2Fubm90LCBz dWNoIGFzIHBlZXIgDQo+IHRvIHBlZXIsIGJlY2F1c2UgdGhleSB3b3VsZCBlbmNvdW50ZXIgYSBw cm9ibGVtLg0KPiANCj4gQW5zd2VyOiANCj4gSSBhc3N1bWUgdGhhdCBpdCBpcyBkZXBlbmRlbnQg b24gdGhlIGltcGxlbWVudGF0aW9uLiBUaGlzIG1lYW5zLCBmb3INCj4gaW5zdGFuY2UsIHRoYXQg d2UgY2FuIGFzc3VtZSB0aGF0IHdlIHdvdWxkIGhhdmUgMSBJSUQgZm9yIEludGVybmV0IA0KPiBl eHBsb3JlciBhbmQgMSBJSUQgZm9yIGFsbCBzZXNzaW9ucyB0aGF0IHdlcmUgb3BlbmVkIGJ5IG9u ZSBwZWVyIHRvIA0KPiBwZWVyIGFwcGxpY2F0aW9uLiBJdCBpcyBwb3NzaWJsZSBmb3IgbWUgdG8g Y2xhcmlmeSBpdCBpbiB0aGUgZHJhZnQgDQo+IGJ5IGV4cGxhaW5pbmcgaG93IHRvIGFzc2lnbiBh IG5ldyBhcHBsaWNhdGlvbiB0byBhIG5ldyBJSUQgLCBqdXN0IGFzDQo+IEkgaGF2ZSBleHBsYWlu ZWQgd2l0aCB0aGVzZSB0d28gZXhhbXBsZXMuDQo+IA0KPiBARGF2ZSBUaGFsZXI6DQo+IENvbmNl cm5zOiBXaHkgd2UgZGlkIG5vdCBtZW50aW9uIGFwcGxpY2F0aW9uIGxheWVyPyBJcyBpdCBiZWNh dXNlIHdlDQo+IHdpbGwgaGF2ZSBhIGxhcmdlIG51bWJlciBvZiBhZGRyZXNzZXM/DQo+IA0KPiBB bnN3ZXI6IElmIHlvdSBkbyBub3QgaGF2ZSBzb21lIGtpbmQgb2YgdmFyaWFibGUgdG8gY29udHJv bCB0aGUgDQo+IGxpZmV0aW1lLCB0aGUgbWF4aW11bSBudW1iZXIgb2YgSUlEcyBhbmQgdGhlIG1h eGltdW0gbnVtYmVyIG9mIA0KPiBhcHBsaWNhdGlvbiBwZXIgSUlEIChhcyBJIGV4cGxhaW5lZCBh IHBhcnQgb2YgdGhhdCBhbGdvcml0aG0gdG8gDQo+IEZlcm5hbmRvKSwgdGhlbiB5b3VyIGNvbmNl cm4gaXMgdmFsaWQuIEJ1dCBpZiB3ZSBjb25zaWRlciB0aGUgdXNlIG9mDQo+IHRoZSBhbGdvcml0 aG0gbWVudGlvbmVkIGluIHRoZSBkcmFmdC4gdGhlbiBJdCBpcyBub3QgdmFsaWQuIFRoZXJlIA0K PiB3YXMgbm90IGVub3VnaCB0aW1lIHRvIGRpc2N1c3MgdGhlIHdob2xlIGFwcGxpY2F0aW9uIGxh eWVyIGFsZ29yaXRobQ0KPiBpbiB0aGUgNm1hbiAoYXMgSSBoYWQgdG8gc3BlbmQgMyB0byA1IG1p bnV0ZXMganVzdCBleHBsYWluaW5nIGl0KS4gDQo+IElmIHlvdSBhcmUgc3RpbGwgIGhhdmluZyBj b25jZXJucywgcGxlYXNlIHNoYXJlIHRoZW0gaGVyZS4gDQo+IA0KPiBDb25jZXJuczogVGhlIGxh cmdlIG51bWJlcnMgb2Ygc2Vzc2lvbnMgYW5kIGV2ZXJ5b25lIHJlcXVpcmluZyBhIA0KPiBzZXBh cmF0ZSBuZWlnaGJvciBkaXNjb3ZlcnkgbXVsdGljYXN0IGFkZHJlc3Mgc28gdGhpcyBibG93cyB5 b3VyIA0KPiBtdWx0aWNhc3QgWy4uLl0gU28sIHRoZSBib3R0b20gbGluZSBpcyBpdCBpcyBub3Qg c2NhbGFibGUuDQo+IA0KPiBBbnN3ZXI6IFRydWUgYW5kIG5vdCB0cnVlLCBUaGlzIGlzIGJlY2F1 c2UgaXQgZGVwZW5kcyBvbiBob3cgeW91IHNldA0KPiB0aGUgbWF4aW11bSBudW1iZXIgb2YgSUlE cy4gSWYgeW91IHNldCBpdHMgZGVmYXVsdCB2YWx1ZSBpbiB5b3VyIA0KPiBuZXR3b3JrIHRvIHNv bWV0aGluZyBsaWtlIDUgb3IgMTAgb3IsIGFuIGluIGdlbmVyYWwsIGEgc21hbGwgbnVtYmVyLA0K PiB0aGVuIHRoaXMgd2lsbCBuZXZlciBoYXBwZW4uIEkgZ3Vlc3MgdGhpcyBpcyBhbiBpc3N1ZSB3 aXRoIG5ldHdvcmsgDQo+IHBvbGljeSBhcyBpbiBteSBkcmFmdCBJIGNvbnNpZGVyZWQgc2V0dGlu ZyB0aGUgZGVmYXVsdCB2YWx1ZXMgYnkgdXNlDQo+IG9mIHRoZSBvcHRpb24gaW4gdGhlIHJvdXRl ciBhZHZlcnRpc2VtZW50IHdoaWNoIGNhbiBiZSBzZXQgYnkgdGhlIA0KPiBhZG1pbnMgb2YgZWFj aCBuZXR3b3JrLg0KPiANCj4gQ29uY2VybnM6IFRoaXMgbGlmZXRpbWUgaXNzdWUgc2hvdWxkIGJl IGluIGFub3RoZXIgZHJhZnQgYW5kIA0KPiBjb25zaWRlcmVkIGluIGEgc2VwYXJhdGUgZG9jdW1l bnQuDQo+IA0KPiBBbnN3ZXI6IElmIHRoZSBvdGhlcnMgZmVlbCB0aGlzIHdheSwgdGhlbiBJIHdp bGwgZG8gaXQuICBUaGUgcmVhc29uIA0KPiBpdCBhcHBlYXJzIGluIHRoaXMgZG9jdW1lbnQgaXMg YmVjYXVzZXMgYmVjYXVzZSBJIHdhbnRlZCB0byBhZGRyZXNzIA0KPiB0aGUgcHJvYmxlbSBvZiBj dXR0aW5nIHRoZSBjb25uZWN0aW9uIHdoZW4gdGhlIGxpZmV0aW1lIG9mIGFuIElJRCANCj4gaGFz IGV4cGlyZWQuIA0KPiANCj4gQ29uY2VybnM6IFNsaWRlIDUsIHdlIHNob3VsZCB1c2UgbGFyZ2Ug c3RhYmxlIHN0b3JhZ2UuDQo+IA0KPiBBbnN3ZXI6IEl0IGlzIGEgd29yZGluZyBpc3N1ZS4gSSBn dWVzcyB3ZSBhbHJlYWR5IGRpc2N1c3NlZCB0aGlzIA0KPiBvZmZsaW5lLiBJbnN0ZWFkIG9mIKGw YWxyZWFkeSBhc3NpZ25lZKGxIGh0dHA6Ly90b29scy5pZXRmLg0KPiBvcmcvaHRtbC9yZmM0OTQx I3NlY3Rpb24tMy4yLjEgc3RlcCA0LCB3ZSBuZWVkIHRvIGNsYXJpZnkgaXQgYXMgZGVmaW5lZCAN CmhlcmUNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFmaWVlLTZtYW4tcmEt cHJpdmFjeS0wNCNzZWN0aW9uLTQNCj4gDQo+IEAgSSBjb3VsZCBub3QgdW5kZXJzdGFuZCB0aGUg bmFtZSAgOiggIDogIEluIHRoaXMgcHJvcG9zYWwgdGhlIA0KPiBudW1iZXIgb2YgYWRkcmVzc2Vz IGluIGEgaG9zdCBpbmNyZWFzZSBkcmFtYXRpY2FsbHkuIFNvIEkgZmVlbCB0aGF0IA0KPiBpZiB3 ZSBhcmUgc3BlY2lmeWluZyB0aGF0IGtpbmQgb2YgbWVjaGFuaXNtLCB0aGUgd2Ugc2hvdWxkIGFs c28gDQo+IHNwZWNpZnkgd2hhdCBoYXBwZW5zIGlmIHRoZSBuZXR3b3JrIGNhbm5vdCAgYWNjb21t b2RhdGUgdGhlbS4gSWYgeW91DQo+IGhhdmUgc28gbWFueSBhZGRyZXNzZXMsIGluIHNvbWUgY2Fz ZXMgeW91IHdvbqGvdCBoYXZlIGNvbm5lY3Rpdml0eS4gDQo+IFRoZXJlIGFyZSB0b28gbWFueSBh ZGRyZXNzZXMgdG8gYmUgYWJsZSB0byBwcm90ZWN0IHRoZSBuZWlnaGJvciANCj4gZGlzY292ZXJ5 IGNhY2hlLg0KPiANCj4gQW5zd2VyOiBJIHdvdWxkIGltcHJvdmUgdGhlIGRvY3VtZW50IGFuZCB0 cnkgdG8gYWRkcmVzcyB0aGlzIGFzIA0KPiB3ZWxsLiBIb3dldmVyLCBJIGRvIG5vdCBwcmVzdW1l IHRoYXQgdGhpcyB3aWxsIGhhcHBlbiwgYmFzZWQgb24gdGhlIA0KPiByZXNwb25zZXMgSSByZWNl aXZlZCBmcm9tIHRoZSBvdGhlciBwZW9wbGUgaGVyZS4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGUgdGVybSBwdWJsaWMgYWRk cmVzc2VzOg0KPiBAS2VpdGggTW9vcmU6IA0KPiBDb25jZXJuczogQWxsIElQdjYgYWRkcmVzc2Vz IGFyZSBwdWJsaWMgYWRkcmVzc2VzIGFuZCBzaG91bGQgYmUgDQo+IGF2YWlsYWJsZS4gTm90IGNo b3NlbiBhIGdvb2QgdGVybS4NCj4gDQo+IEkganVzdCBvYnRhaW5lZCB0aGF0IHRlcm0gZnJvbSBm cm9tIHRoZSBtYWlsaW5nIGxpc3QuIENoZWNrIHRoaXMgb2xkIA0KbGlzdCA6IA0KPiBodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXB2Ni9jdXJyZW50L21zZzE3NzkyLmh0bWwg DQo+IEEgcHVibGljIGFkZHJlc3MgaXMgb25lIGludGVuZGVkIHRvIGJlIHJlc29sdmFibGUgZnJv bSBoaWdoZXItbGF5ZXIgDQo+IElEcyBzdWNoIGFzIEROUyBuYW1lcy4NCj4gSWYgdGhpcyBpcyB3 cm9uZyBvciBJIG1pc3VuZGVyc3Rvb2QgdGhlIG1lYW5pbmcgLCB0aGVuIEkgd2lsbCBjaGFuZ2UN Cj4gaXQgdG8gobBETlMgYWRkcmVzc2VzobEgb3IgYW5vdGhlciB0ZXJtLiANCj4gV2hhdCBJIGtu ZXcgYmVmb3JlOg0KPiBHbG9iYWwgYWRkcmVzc2VzID0gUm91dGVyIHByZWZpeCArIElJRA0KPiBM b2NhbCBBZGRyZXNzZXMgPSBsb2NhbCBwcmVmaXggKyBJSUQNCj4gV2hhdCBJIHVuZGVyc3Rvb2Q6 DQo+IFB1YmxpYyBhZGRyZXNzZXMgPSByb3V0ZXIgcHJlZml4ICsgSUlEICBhbmQgaGFzICBETlMg cmVjb3JkcyAobGlrZSBhIA0KZG9tYWluKQ0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IFNlY3VyaXR5IGFuZCBOZXR3b3JrIFBvbGljeQ0KPiBAIEkg Y291bGQgbm90IHVuZGVyc3RhbmQgdGhlIG5hbWUgIDooICAgOiBRdWVzdGlvbiBhYm91dCB0aGlz IA0KPiBzZWN0aW9uIG9mIHNsaWRlIKGwaWYgYSB1c2VyIHZpc2l0IGEgd2Vic2l0ZSBhbmQgaGFy bXMgYnkgYSBjb29raWUgDQo+IHRoZW4gd2UgbmVlZCB0byBjaGFuZ2UgdGhlIElJRKGxLiBEbyB5 b3UgdGhpbmsgdGhpcyBpcyBzZWN1cml0eSANCj4gbWVjaGFuaXNtIHRvIGRvIHRoaXM/IEkgZG8g bm90IGNvbnNpZGVyIHRvIGhhdmUgYSBwb2xpY3kgZm9yIHRoZSANCm5ldHdvcmsuDQo+IA0KPiBB bnN3ZXI6IEkgbWVhbnQgaHR0cCBjb29raWVzIG9yIHNlcnZlciBzaWRlIGNvb2tpZXMuIEJlY2F1 c2UgY2xpZW50IA0KPiBzaWRlIGNvb2tpZXMgY2FuIGJlIGhhcm1mdWwgaWYgdGhlcmUgaXMgYSBz Y3JpcHQgZnJvbSBhIHdlYnNpdGUgdGhhdA0KPiBtaWdodCBhY2Nlc3MgdGhlIG90aGVyIGNvb2tp ZXMgaW4geW91ciBjb21wdXRlci4gIFRoaXMgd2FzIGp1c3Qgb25lIA0KPiByZWFzb24gdG8gY2hh bmdlIHRoZSBJSUQgYWRkcmVzc2VzIHdpdGhpbiBhbmQgb3V0c2lkZSBvZiB0aGUgDQo+IG5ldHdv cmsuIFRoZXJlIGlzIG5vdGhpbmcgbWVudGlvbmVkIGFib3V0IHRoaXMgZGlyZWN0bHkgaW4gdGhl IA0KPiBkcmFmdC4gSSBwcm9iYWJseSBkaWRuJ3QgZXhwcmVzcyB0aGlzIGlkZWEgY29ycmVjdGx5 IHNvIHlvdSBoYWQgYSANCj4gbWlzY29uY2VwdGlvbiBvZiB3aGF0IEkgd2FzIHRyeWluZyB0byBz YXkuIA0KPiANCj4gDQo+IElmIHRoZXJlIGFyZSBhbnkgbW9yZSBpc3N1ZXMgdGhhdCBJIG5lZWQg dG8gY29uY2VybiBwbGVhc2UgbGVhdmUgDQo+IHlvdXIgY29tbWVudCBoZXJlLg0KPiANCj4gVGhh bmsgeW91LA0KPiBCZXN0LA0KPiBIb3NuaWVoDQo+IA0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJ UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5p c3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= --=_alternative 002DF01A48257BB8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSYWZpZWUsPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IEkgZG9uJ3Qg dGhpbmsgdXNpbmcgQ0dBDQpieSByZXBsYWNpbmcgdGhlIHB1YmxpYyBrZXkgd2l0aCBhIHRpbWVz dGFtcCBvciBvdGhlciByYW5kb20gc3RyaW5nIGlzDQphICZxdW90O2hpZ2hlciByYW5kb216YXRp b24mcXVvdDsgYWRkcmVzcyBnZW5lcmF0aW9uIG1ldGhvZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhhc2ggaXMgb25seSBvbmUgdGVjaG5pcXVlIG9mIGdlbmVy YXRpbmcNCmEgcmFuZG9tIGxpa2Ugc3RyaW5nLCBtYXkgbm90IGJlIHRoZSBiZXN0IG9uZSBhbW9u ZyB0aG9zZSBzcGVjaWZpZWQgaW4NClJGQzQwODYuPGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRy Pg0KPHRkPjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPmlwdjYtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTMtMDctMzAg MTM6MTI6MzQ6PGJyPg0KPGJyPg0KJmd0OyBIaSAmbmJzcDtBbGwsPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBNYW55IHRoYW5rcyB0byAmbmJzcDt0aGUgcGVvcGxlIHdobyBjb21tZW50ZWQN Cm9uIG15IGRyYWZ0LiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSGVy ZSBhcmUgbXkgcmVzcG9uc2VzLiBUaGVyZSB3YXMgbm90IGVub3VnaCB0aW1lDQp0byByZXNwb25k IHRvIGFsbCA8YnI+DQomZ3Q7IGNvbW1lbnRzIGFuZCBpdCB3YXMgZGlmZmljdWx0IHRvIGRpc2Nl cm4gYW5kIGZvbGxvdyB0aGUgY29tbWVudHMgb25lPGJyPg0KJmd0OyBieSBvbmUgZnJvbSB0aGUg YXVkaW8gdGFwZS4gSSBoYWQgdG8gbGlzdGVuIHRvIHRoZSBhdWRpbyByZXBlYXRlZGx5DQo8YnI+ DQomZ3Q7IGJlZm9yZSBJIGNvdWxkIHB1dCB0aGUgY29udGV4dCBvZiB0aGUgY29tbWVudCB0b2dl dGhlciB3aXRoIHRoZSA8YnI+DQomZ3Q7IHN1YmplY3Qgb2YgdGhlIHNsaWRlLiA8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IFRvIGNsYXJpZnksIEkgdXNlZCBwdWJsaWMgYWRkcmVzc2VzIGJl Y2F1c2Ugb3RoZXINCnBlb3BsZSBvbiB0aGUgPGJyPg0KJmd0OyBtYWlsaW5nIGxpc3QgdXNlZCB0 aGlzIHRlcm0uIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgUmVzcG9uc2UgdG8gY29tbWVudHMgcmVsYXRlZCB0byBMaWZldGltZSBvZiB0aGUN CklJRDo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQEZlcm5hbmRvOiA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQ29uY2VybnM6IHdlIHdpbGwg aGF2ZSB0aG91c2FuZHMgb2YgSUlEcyBpZiB3ZQ0Kd2FudCB0byBnZW5lcmF0ZSBhIDxicj4NCiZn dDsgbmV3IElJRCBmb3IgZWFjaCBhcHBsaWNhdGlvbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgQW5zd2VyOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGVyZSBh cmUgc29tZSB2YXJpYWJsZXMgdG8gYmUgY29uc2lkZXJlZCB3aGVuDQptYWludGFpbmluZyB0aGUg PGJyPg0KJmd0OyBsaWZldGltZSBvZiB0aGUgSUlELiBPbmUgJm5ic3A7c3VjaCB2YXJpYWJsZSBp cyB0aGUgbWF4aW11bSBudW1iZXINCm9mIDxicj4NCiZndDsgSUlEcy4gVGhlIG1heGltdW0gbnVt YmVyIG9mIGFwcGxpY2F0aW9ucyBwZXIgSUlEIGFuZCB0aGUgbWF4aW11bSA8YnI+DQomZ3Q7IGxp ZmV0aW1lIG9mIHRoZSBJSUQuIElmIHRoZSBJSUQgZXhwaXJlcywgaXQgd2lsbCBrZWVwIGl0cyBj dXJyZW50DQo8YnI+DQomZ3Q7IGNvbm5lY3Rpb25zIGJ1dCB3aWxsIG5vdCBiZSBhYmxlIHRvIGJl IHVzZWQgZm9yIG5ldyBjb25uZWN0aW9ucy4gSWYNCjxicj4NCiZndDsgYSBub2RlIHN0YXJ0cyBh biBhcHBsaWNhdGlvbiB4LCB0aGVuIGl0IGNoZWNrcyB3aGV0aGVyIG9yIG5vdCBhbnkNCjxicj4N CiZndDsgSUlEcyBhcmUgYXZhaWxhYmxlIHdob3NlIGxpZmV0aW1lIGhhcyBub3QgeWV0IGV4cGly ZWQuIElmIHRoZXJlIDxicj4NCiZndDsgaXMvYXJlLCB0aGVuIGl0IHNvcnRzIHRoZW0gYmFzZWQg b24gdGhlaXIgbGlmZXRpbWUgYW5kIGFzc2lnbiA8YnI+DQomZ3Q7IGl0L3RoZW0gdG8gdGhlIElJ RCB3aXRoIHRoZSBsb25nZXN0IGxpZmV0aW1lLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgSWYgdGhlcmUgaXMgbm8gSUlEIGF2YWlsYWJsZSBhbmQgdGhlIG1heGltdW0N Cm51bWJlciBvZiBJSURzIGhhcyBiZWVuPGJyPg0KJmd0OyByZWFjaGVkLCB0aGVuIGluY3JlYXNl IHRoZSBtYXhpbXVtIG51bWJlciBvZiBhcHBsaWNhdGlvbnMgKHZhcmlhYmxlDQo8YnI+DQomZ3Q7 IGtlZXBzIHRoaXMgYW1vdW50KSBmb3IgYSBzcGVjaWZpYyBJSUQgd2l0aCB0aGUgbG9uZ2VzdCBs aWZldGltZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSWYgdGhlcmUg aXMgbm8gSUlEIGF2YWlsYWJsZSwgYnV0IHRoZSBtYXhpbXVtDQpudW1iZXIgb2YgSUlEcyBpcyBO T1QgPGJyPg0KJmd0OyByZWFjaGVkLCB0aGVuIGdlbmVyYXRlIGEgbmV3IElJRCBhbmQgYXNzaWdu IHRoaXMgYXBwbGljYXRpb24gdG8gaXQuDQo8YnI+DQomZ3Q7IEZvciBtb3JlIGluZm9ybWF0aW9u IHBsZWFzZSByZWZlciB0byB0aGUgZHJhZnQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBA S2VpdGggTW9vcmU6IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDb25j ZXJuczogU29tZSBhcHBsaWNhdGlvbnMgY2FuIGp1c3QgdXNlIGEgZGlmZmVyZW50DQphZGRyZXNz IGZvciA8YnI+DQomZ3Q7IGV2ZXJ5IG5ldyBhcHBsaWNhdGlvbiB3aGlsZSBvdGhlciBhcHBsaWNh dGlvbnMgY2Fubm90LCBzdWNoIGFzIHBlZXINCjxicj4NCiZndDsgdG8gcGVlciwgYmVjYXVzZSB0 aGV5IHdvdWxkIGVuY291bnRlciBhIHByb2JsZW0uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBBbnN3ZXI6IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJIGFzc3Vt ZSB0aGF0IGl0IGlzIGRlcGVuZGVudCBvbiB0aGUgaW1wbGVtZW50YXRpb24uDQpUaGlzIG1lYW5z LCBmb3I8YnI+DQomZ3Q7IGluc3RhbmNlLCB0aGF0IHdlIGNhbiBhc3N1bWUgdGhhdCB3ZSB3b3Vs ZCBoYXZlIDEgSUlEIGZvciBJbnRlcm5ldA0KPGJyPg0KJmd0OyBleHBsb3JlciBhbmQgMSBJSUQg Zm9yIGFsbCBzZXNzaW9ucyB0aGF0IHdlcmUgb3BlbmVkIGJ5IG9uZSBwZWVyIHRvDQo8YnI+DQom Z3Q7IHBlZXIgYXBwbGljYXRpb24uIEl0IGlzIHBvc3NpYmxlIGZvciBtZSB0byBjbGFyaWZ5IGl0 IGluIHRoZSBkcmFmdA0KPGJyPg0KJmd0OyBieSBleHBsYWluaW5nIGhvdyB0byBhc3NpZ24gYSBu ZXcgYXBwbGljYXRpb24gdG8gYSBuZXcgSUlEICwganVzdA0KYXM8YnI+DQomZ3Q7IEkgaGF2ZSBl eHBsYWluZWQgd2l0aCB0aGVzZSB0d28gZXhhbXBsZXMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyBARGF2ZSBUaGFsZXI6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IENvbmNlcm5zOiBXaHkgd2UgZGlkIG5vdCBtZW50aW9uIGFwcGxpY2F0aW9uDQpsYXllcj8gSXMg aXQgYmVjYXVzZSB3ZTxicj4NCiZndDsgd2lsbCBoYXZlIGEgbGFyZ2UgbnVtYmVyIG9mIGFkZHJl c3Nlcz88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFuc3dlcjogSWYgeW91IGRvIG5vdCBo YXZlIHNvbWUga2luZCBvZiB2YXJpYWJsZQ0KdG8gY29udHJvbCB0aGUgPGJyPg0KJmd0OyBsaWZl dGltZSwgdGhlIG1heGltdW0gbnVtYmVyIG9mIElJRHMgYW5kIHRoZSBtYXhpbXVtIG51bWJlciBv ZiA8YnI+DQomZ3Q7IGFwcGxpY2F0aW9uIHBlciBJSUQgKGFzIEkgZXhwbGFpbmVkIGEgcGFydCBv ZiB0aGF0IGFsZ29yaXRobSB0byA8YnI+DQomZ3Q7IEZlcm5hbmRvKSwgdGhlbiB5b3VyIGNvbmNl cm4gaXMgdmFsaWQuIEJ1dCBpZiB3ZSBjb25zaWRlciB0aGUgdXNlDQpvZjxicj4NCiZndDsgdGhl IGFsZ29yaXRobSBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiB0aGVuIEl0IGlzIG5vdCB2YWxpZC4g VGhlcmUNCjxicj4NCiZndDsgd2FzIG5vdCBlbm91Z2ggdGltZSB0byBkaXNjdXNzIHRoZSB3aG9s ZSBhcHBsaWNhdGlvbiBsYXllciBhbGdvcml0aG08YnI+DQomZ3Q7IGluIHRoZSA2bWFuIChhcyBJ IGhhZCB0byBzcGVuZCAzIHRvIDUgbWludXRlcyBqdXN0IGV4cGxhaW5pbmcgaXQpLg0KPGJyPg0K Jmd0OyBJZiB5b3UgYXJlIHN0aWxsICZuYnNwO2hhdmluZyBjb25jZXJucywgcGxlYXNlIHNoYXJl IHRoZW0gaGVyZS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDb25jZXJuczogVGhlIGxh cmdlIG51bWJlcnMgb2Ygc2Vzc2lvbnMgYW5kIGV2ZXJ5b25lDQpyZXF1aXJpbmcgYSA8YnI+DQom Z3Q7IHNlcGFyYXRlIG5laWdoYm9yIGRpc2NvdmVyeSBtdWx0aWNhc3QgYWRkcmVzcyBzbyB0aGlz IGJsb3dzIHlvdXIgPGJyPg0KJmd0OyBtdWx0aWNhc3QgWy4uLl0gU28sIHRoZSBib3R0b20gbGlu ZSBpcyBpdCBpcyBub3Qgc2NhbGFibGUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBBbnN3 ZXI6IFRydWUgYW5kIG5vdCB0cnVlLCBUaGlzIGlzIGJlY2F1c2UgaXQNCmRlcGVuZHMgb24gaG93 IHlvdSBzZXQ8YnI+DQomZ3Q7IHRoZSBtYXhpbXVtIG51bWJlciBvZiBJSURzLiBJZiB5b3Ugc2V0 IGl0cyBkZWZhdWx0IHZhbHVlIGluIHlvdXIgPGJyPg0KJmd0OyBuZXR3b3JrIHRvIHNvbWV0aGlu ZyBsaWtlIDUgb3IgMTAgb3IsIGFuIGluIGdlbmVyYWwsIGEgc21hbGwgbnVtYmVyLDxicj4NCiZn dDsgdGhlbiB0aGlzIHdpbGwgbmV2ZXIgaGFwcGVuLiBJIGd1ZXNzIHRoaXMgaXMgYW4gaXNzdWUg d2l0aCBuZXR3b3JrDQo8YnI+DQomZ3Q7IHBvbGljeSBhcyBpbiBteSBkcmFmdCBJIGNvbnNpZGVy ZWQgc2V0dGluZyB0aGUgZGVmYXVsdCB2YWx1ZXMgYnkgdXNlPGJyPg0KJmd0OyBvZiB0aGUgb3B0 aW9uIGluIHRoZSByb3V0ZXIgYWR2ZXJ0aXNlbWVudCB3aGljaCBjYW4gYmUgc2V0IGJ5IHRoZQ0K PGJyPg0KJmd0OyBhZG1pbnMgb2YgZWFjaCBuZXR3b3JrLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgQ29uY2VybnM6IFRoaXMgbGlmZXRpbWUgaXNzdWUgc2hvdWxkIGJlIGluIGFub3RoZXIN CmRyYWZ0IGFuZCA8YnI+DQomZ3Q7IGNvbnNpZGVyZWQgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudC48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFuc3dlcjogSWYgdGhlIG90aGVycyBmZWVsIHRo aXMgd2F5LCB0aGVuIEkgd2lsbA0KZG8gaXQuICZuYnNwO1RoZSByZWFzb24gPGJyPg0KJmd0OyBp dCBhcHBlYXJzIGluIHRoaXMgZG9jdW1lbnQgaXMgYmVjYXVzZXMgYmVjYXVzZSBJIHdhbnRlZCB0 byBhZGRyZXNzDQo8YnI+DQomZ3Q7IHRoZSBwcm9ibGVtIG9mIGN1dHRpbmcgdGhlIGNvbm5lY3Rp b24gd2hlbiB0aGUgbGlmZXRpbWUgb2YgYW4gSUlEDQo8YnI+DQomZ3Q7IGhhcyBleHBpcmVkLiA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IENvbmNlcm5zOiBTbGlkZSA1LCB3ZSBzaG91bGQg dXNlIGxhcmdlIHN0YWJsZQ0Kc3RvcmFnZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFu c3dlcjogSXQgaXMgYSB3b3JkaW5nIGlzc3VlLiBJIGd1ZXNzIHdlIGFscmVhZHkNCmRpc2N1c3Nl ZCB0aGlzIDxicj4NCiZndDsgb2ZmbGluZS4gSW5zdGVhZCBvZiChsGFscmVhZHkgYXNzaWduZWSh sSBodHRwOi8vdG9vbHMuaWV0Zi48YnI+DQomZ3Q7IG9yZy9odG1sL3JmYzQ5NDEjc2VjdGlvbi0z LjIuMSBzdGVwIDQsIHdlIG5lZWQgdG8gY2xhcmlmeSBpdCBhcyBkZWZpbmVkDQpoZXJlPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJhZmllZS02bWFuLXJhLXByaXZhY3ktMDQjc2VjdGlvbi00PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyBAIEkgY291bGQgbm90IHVuZGVyc3RhbmQgdGhlIG5hbWUgJm5ic3A7 OiggJm5ic3A7Og0KJm5ic3A7SW4gdGhpcyBwcm9wb3NhbCB0aGUgPGJyPg0KJmd0OyBudW1iZXIg b2YgYWRkcmVzc2VzIGluIGEgaG9zdCBpbmNyZWFzZSBkcmFtYXRpY2FsbHkuIFNvIEkgZmVlbCB0 aGF0DQo8YnI+DQomZ3Q7IGlmIHdlIGFyZSBzcGVjaWZ5aW5nIHRoYXQga2luZCBvZiBtZWNoYW5p c20sIHRoZSB3ZSBzaG91bGQgYWxzbyA8YnI+DQomZ3Q7IHNwZWNpZnkgd2hhdCBoYXBwZW5zIGlm IHRoZSBuZXR3b3JrIGNhbm5vdCAmbmJzcDthY2NvbW1vZGF0ZSB0aGVtLg0KSWYgeW91PGJyPg0K Jmd0OyBoYXZlIHNvIG1hbnkgYWRkcmVzc2VzLCBpbiBzb21lIGNhc2VzIHlvdSB3b26hr3QgaGF2 ZSBjb25uZWN0aXZpdHkuDQo8YnI+DQomZ3Q7IFRoZXJlIGFyZSB0b28gbWFueSBhZGRyZXNzZXMg dG8gYmUgYWJsZSB0byBwcm90ZWN0IHRoZSBuZWlnaGJvciA8YnI+DQomZ3Q7IGRpc2NvdmVyeSBj YWNoZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFuc3dlcjogSSB3b3VsZCBpbXByb3Zl IHRoZSBkb2N1bWVudCBhbmQgdHJ5DQp0byBhZGRyZXNzIHRoaXMgYXMgPGJyPg0KJmd0OyB3ZWxs LiBIb3dldmVyLCBJIGRvIG5vdCBwcmVzdW1lIHRoYXQgdGhpcyB3aWxsIGhhcHBlbiwgYmFzZWQg b24gdGhlDQo8YnI+DQomZ3Q7IHJlc3BvbnNlcyBJIHJlY2VpdmVkIGZyb20gdGhlIG90aGVyIHBl b3BsZSBoZXJlLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IFRoZSB0ZXJtIHB1YmxpYyBhZGRyZXNzZXM6PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEBLZWl0aCBNb29yZTogPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IENvbmNlcm5zOiBBbGwgSVB2NiBhZGRyZXNzZXMgYXJlIHB1 YmxpYyBhZGRyZXNzZXMNCmFuZCBzaG91bGQgYmUgPGJyPg0KJmd0OyBhdmFpbGFibGUuIE5vdCBj aG9zZW4gYSBnb29kIHRlcm0uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJIGp1c3Qgb2J0 YWluZWQgdGhhdCB0ZXJtIGZyb20gZnJvbSB0aGUgbWFpbGluZw0KbGlzdC4gQ2hlY2sgdGhpcyBv bGQgbGlzdCA6IDxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2lwdjYvY3VycmVudC9tc2cxNzc5Mi5odG1sIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBBIHB1YmxpYyBhZGRyZXNzIGlzIG9uZSBpbnRlbmRlZCB0byBiZSByZXNvbHZh YmxlDQpmcm9tIGhpZ2hlci1sYXllciA8YnI+DQomZ3Q7IElEcyBzdWNoIGFzIEROUyBuYW1lcy48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSWYgdGhpcyBpcyB3cm9uZyBv ciBJIG1pc3VuZGVyc3Rvb2QgdGhlIG1lYW5pbmcNCiwgdGhlbiBJIHdpbGwgY2hhbmdlPGJyPg0K Jmd0OyBpdCB0byChsEROUyBhZGRyZXNzZXOhsSBvciBhbm90aGVyIHRlcm0uICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBXaGF0IEkga25ldyBiZWZvcmU6PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEdsb2JhbCBhZGRyZXNzZXMgPSBS b3V0ZXIgcHJlZml4ICsgSUlEPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IExvY2FsIEFkZHJlc3NlcyA9IGxvY2FsIHByZWZpeCArIElJRDwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyBXaGF0IEkgdW5kZXJzdG9vZDo8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgUHVibGljIGFkZHJlc3NlcyA9IHJvdXRlciBwcmVmaXggKyBJ SUQgJm5ic3A7YW5kDQpoYXMgJm5ic3A7RE5TIHJlY29yZHMgKGxpa2UgYSBkb21haW4pPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU2VjdXJpdHkg YW5kIE5ldHdvcmsgUG9saWN5PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IEAgSSBjb3VsZCBub3QgdW5kZXJzdGFuZCB0aGUgbmFtZSAmbmJzcDs6KCAmbmJzcDsNCjogUXVl c3Rpb24gYWJvdXQgdGhpcyA8YnI+DQomZ3Q7IHNlY3Rpb24gb2Ygc2xpZGUgobBpZiBhIHVzZXIg dmlzaXQgYSB3ZWJzaXRlIGFuZCBoYXJtcyBieSBhIGNvb2tpZQ0KPGJyPg0KJmd0OyB0aGVuIHdl IG5lZWQgdG8gY2hhbmdlIHRoZSBJSUShsS4gRG8geW91IHRoaW5rIHRoaXMgaXMgc2VjdXJpdHkg PGJyPg0KJmd0OyBtZWNoYW5pc20gdG8gZG8gdGhpcz8gSSBkbyBub3QgY29uc2lkZXIgdG8gaGF2 ZSBhIHBvbGljeSBmb3IgdGhlIG5ldHdvcmsuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBB bnN3ZXI6IEkgbWVhbnQgaHR0cCBjb29raWVzIG9yIHNlcnZlciBzaWRlIGNvb2tpZXMuDQpCZWNh dXNlIGNsaWVudCA8YnI+DQomZ3Q7IHNpZGUgY29va2llcyBjYW4gYmUgaGFybWZ1bCBpZiB0aGVy ZSBpcyBhIHNjcmlwdCBmcm9tIGEgd2Vic2l0ZSB0aGF0PGJyPg0KJmd0OyBtaWdodCBhY2Nlc3Mg dGhlIG90aGVyIGNvb2tpZXMgaW4geW91ciBjb21wdXRlci4gJm5ic3A7VGhpcyB3YXMganVzdA0K b25lIDxicj4NCiZndDsgcmVhc29uIHRvIGNoYW5nZSB0aGUgSUlEIGFkZHJlc3NlcyB3aXRoaW4g YW5kIG91dHNpZGUgb2YgdGhlIDxicj4NCiZndDsgbmV0d29yay4gVGhlcmUgaXMgbm90aGluZyBt ZW50aW9uZWQgYWJvdXQgdGhpcyBkaXJlY3RseSBpbiB0aGUgPGJyPg0KJmd0OyBkcmFmdC4gSSBw cm9iYWJseSBkaWRuJ3QgZXhwcmVzcyB0aGlzIGlkZWEgY29ycmVjdGx5IHNvIHlvdSBoYWQgYQ0K PGJyPg0KJmd0OyBtaXNjb25jZXB0aW9uIG9mIHdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheS4gJm5i c3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSWYgdGhlcmUgYXJlIGFueSBtb3JlIGlzc3VlcyB0aGF0IEkg bmVlZCB0byBjb25jZXJuDQpwbGVhc2UgbGVhdmUgPGJyPg0KJmd0OyB5b3VyIGNvbW1lbnQgaGVy ZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoYW5rIHlvdSw8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQmVzdCw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgSG9zbmllaDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgaXB2NkBpZXRmLm9yZzxicj4NCiZndDsgQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Njxicj4NCiZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 002DF01A48257BB8_=-- From ietf@rozanak.com Tue Jul 30 01:35:52 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3694011E81BC; Tue, 30 Jul 2013 01:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzzwKVTb1Cu6; Tue, 30 Jul 2013 01:35:41 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6B521E80D5; Tue, 30 Jul 2013 01:33:20 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQzYs-1Ue7y80qdi-00U5CY; Tue, 30 Jul 2013 04:33:13 -0400 From: "Hosnieh Rafiee" To: References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> In-Reply-To: Subject: RE: ra-privacy: my responses to comments Date: Tue, 30 Jul 2013 10:33:01 +0200 Message-ID: <006e01ce8cff$6ce243c0$46a6cb40$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbpD6MO/5fm7DvoJdtKWPZlQSrJZlitArQ Content-Language: en-us X-Provags-ID: V02:K0:2NhRPvpx1uaSm7ZG718ZD7mTwWYUJqJkTMLrUk085xd +WMYiKY9W+h4cQt7mSLMOo1SCBkkm48Aj7Cnjm3QI7SyAl39dX 2mRPMhoatiofZAjkqJfQmVZRXvbF3pxIpANBuPLVH+ejRnrX7p w00EB2A16LoKa2akBMA83aewKr1dErPVzC/dQQQiWCBrN9lyN9 mmSAJ0Zs7j4OiMvggZx4oxc1KS4XU4he+2iOU3LoZd46B47q+o zPZF/vl1WAtnhU8Qp/dK8EWXdctkCzZZZ+JWo+YRHulxv6ug+f gpPAAAtegNd21j+dpYocUzWOibeVxSZmzJ3nh/bhHVjQN73Mnk 19ghJR45c+NEGpW5E2Uw= Cc: ipv6-bounces@ietf.org, ipv6@ietf.org, 'Fernando Gont' , 'Dave Thaler' , 'Keith Moore' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:35:54 -0000 Hi Zhou, Thanks for the comment. >=A0 =A0 I don't think using CGA by replacing the public key with a = timestamp or other random string is a "higher randomzation" address generation = method.=20 >Hash is only one technique of generating a random like string, may not = be the best one among those specified in RFC4086. I think it is misconception. One problem that I tried to address in my = draft (as a update to RFC 4941) is that the RFC might use RFC 4086 (no forcing = to use it). This means there might be no good randomization. In one section then the RFC discussed about DHCPv6 and CGA. I only explained how to use = CGA if the security is not a concern by having a highly randomized approach. = I compared my approach with the approach already exist in the document and assume the case where there is no force to use RFC 4086.=20 Thanks, Regards, Hosnieh > -------------------------------------------------------------------- From rbonica@juniper.net Tue Jul 30 01:37:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71AB11E81CC for ; Tue, 30 Jul 2013 01:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.967 X-Spam-Level: X-Spam-Status: No, score=-99.967 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9pXqKjYs2Zj for ; Tue, 30 Jul 2013 01:37:33 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F621F8C71 for ; Tue, 30 Jul 2013 01:34:15 -0700 (PDT) Received: from mail71-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE023.bigfish.com (10.174.4.86) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 08:34:15 +0000 Received: from mail71-db8 (localhost [127.0.0.1]) by mail71-db8-R.bigfish.com (Postfix) with ESMTP id F26D6B00144 for ; Tue, 30 Jul 2013 08:34:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail71-db8: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=rbonica@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail71-db8 (localhost.localdomain [127.0.0.1]) by mail71-db8 (MessageSwitch) id 1375173252519515_22929; Tue, 30 Jul 2013 08:34:12 +0000 (UTC) Received: from DB8EHSMHS008.bigfish.com (unknown [10.174.8.245]) by mail71-db8.bigfish.com (Postfix) with ESMTP id 7AE09200048 for ; Tue, 30 Jul 2013 08:34:12 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.51) by DB8EHSMHS008.bigfish.com (10.174.4.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 08:34:12 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 01:34:10 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Tue, 30 Jul 2013 01:34:10 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 01:38:18 -0700 Received: from mail43-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 08:34:08 +0000 Received: from mail43-ch1 (localhost [127.0.0.1]) by mail43-ch1-R.bigfish.com (Postfix) with ESMTP id 8B58380205 for ; Tue, 30 Jul 2013 08:34:08 +0000 (UTC) Received: from mail43-ch1 (localhost.localdomain [127.0.0.1]) by mail43-ch1 (MessageSwitch) id 1375173246853311_25631; Tue, 30 Jul 2013 08:34:06 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail43-ch1.bigfish.com (Postfix) with ESMTP id C1EBB20047; Tue, 30 Jul 2013 08:34:06 +0000 (UTC) Received: from BY2PRD0511HT003.namprd05.prod.outlook.com (157.56.237.149) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 08:34:06 +0000 Received: from BY2PRD0511MB428.namprd05.prod.outlook.com ([169.254.5.84]) by BY2PRD0511HT003.namprd05.prod.outlook.com ([10.255.129.38]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 08:34:05 +0000 From: Ronald Bonica To: Randy Bush , Bob Hinden Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjGh+iYfnka6nOUeBop7mpmo4Zpl8jlmAgAAxvQCAAAnxgIAAEp3w Date: Tue, 30 Jul 2013 08:34:04 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%PSG.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: IPv6 Maintanence , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:37:44 -0000 Folks, I think that we heard the following at yesterday's meeting: Title =3D=3D=3D=3D=3D The document should be renamed "IPv6 Fragmentation Considered Ineffective" Deprecation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All instances of the word "deprecate" should be removed from the document. = Therefore: -- The document should not request any IANA actions -- The document doesn't UDPDATE 2460 -- The document doesn't need to be PS. BCP is good enough Recommendation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Recommendation section should be renamed "Conclusion". It should includ= e the following statements: - The IETF SHOULD NOT standardize an new protocols that rely on IPv6 fragme= ntation ---*New* applications and transport layer protocols SHOULD support effectiv= e PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is unreliable --*New* applications or transport layer protocols that cannot support effec= tive PMTUD MUST NOT in any circumstances send IPv6 packets that exceed the = IPv6 minimum MTU of 1280 bytes. - Legacy applications and transport layer protocols will continue to genera= te fragments --- In the interest of backwards compatibility, IPv6 stacks and forwarding = nodes MUST continue to support inbound fragmented IPv6 packets as specified= in [RFC2460]. - Implementers and operators need to be aware that on many paths through th= e Internet, IPv6 fragmentation will fail. Legacy applications and transport= layer protocols that do not conform to the previous paragraph can expect c= onnectivity failures as a result. --- Therefore, if a legacy protocol is capable of breaking its dependence o= n IPv6 fragmentation, it should consider doing so. Did I miss anything? Ron >=20 > hmmm. i am gonna put my foot in the cow pie. > i think what we want here is something close to > o future implementations SHOULD not generate frags > (note that SHOULD !=3D MUST) > o expect to receive frags for a long time >=20 > randy From fgont@si6networks.com Tue Jul 30 01:41:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F28A21E80E1 for ; Tue, 30 Jul 2013 01:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6SwyVI2m+c2 for ; Tue, 30 Jul 2013 01:41:09 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9321E80D5 for ; Tue, 30 Jul 2013 01:39:04 -0700 (PDT) Received: from [2001:df8:0:64:74fa:84a8:e593:8f89] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V45SK-0008VR-NY; Tue, 30 Jul 2013 10:38:56 +0200 Message-ID: <51F77B9F.50606@si6networks.com> Date: Tue, 30 Jul 2013 10:38:55 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Randy Bush Subject: Re: "Deprecate" References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Maintanence , Bob Hinden , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:41:10 -0000 On 07/30/2013 08:52 AM, Randy Bush wrote: > > hmmm. i am gonna put my foot in the cow pie. > i think what we want here is something close to > o future implementations SHOULD not generate frags > (note that SHOULD != MUST) > o expect to receive frags for a long time My understanding was that the goal was: * New applications should avoid fragmentation where possible * Hosts must still be able to fragment and reassemble * Beware that some networks filter fragments i.e., we're not arguing about removing any functionality from nodes (whether current or new implementations), nor we're advising networks to drop fragments. -- i.e., something along the lines of what we did in RFC 6093 for the TCP urgent mechanism. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fred@cisco.com Tue Jul 30 01:43:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810FE21E80DE for ; Tue, 30 Jul 2013 01:43:01 -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 5Q65YyOtY0rU for ; Tue, 30 Jul 2013 01:42:56 -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 1F90F21E80DD for ; Tue, 30 Jul 2013 01:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2889; q=dns/txt; s=iport; t=1375173728; x=1376383328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mhLNPgK2NC/IQAVJSq9yOp21QBpULLSgZ/InGsZ5pVA=; b=kx+ranKmMHuFeM1ZWJUkhujuNG+0wKQglNf5oanAE7iqdTX2wowAURIn IxeXYH/dVs8RSmOJjleKorfrbgXaoBQx3StXq7+4tCz4kZhwTIb8A1yZ1 +iR+gNbOVWi16DHcA3acdSRNSALesEKzX4PxB2QkhthXwMhz8NKi/Ei3j k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALJ791GtJXHB/2dsb2JhbABbgwY1UL4OgRsWdIIkAQEBAwE6PwULAgEIDhQUEDIlAgQOBQiIAga4c49LAjEHgxhvA4xAjEiFbIo3gxSBaAc7 X-IronPort-AV: E=Sophos;i="4.89,776,1367971200"; d="scan'208";a="241151638" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 30 Jul 2013 08:42:07 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6U8g7sj018048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 08:42:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 03:42:07 -0500 From: "Fred Baker (fred)" To: Ronald Bonica Subject: Re: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjGh+iYfnka6nOUeBop7mpmo4Zpl84iuAgAAxvACAAAnygIAAHEAAgAACOgA= Date: Tue, 30 Jul 2013 08:42:06 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.74.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <7AAD44BDA2414F4D9D926416C64E6DA6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Maintanence , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:43:02 -0000 I mostly agree. Some fuzz. On Jul 30, 2013, at 10:34 AM, Ronald Bonica wrote: > Folks, >=20 > I think that we heard the following at yesterday's meeting: >=20 > Title > =3D=3D=3D=3D=3D > The document should be renamed "IPv6 Fragmentation Considered Ineffective= " "Ineffective" has to be modified by "for some specific purpose". Is it inef= fective at getting packets through end to end? Ineffective at getting throu= gh firewalls? What? > Deprecation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > All instances of the word "deprecate" should be removed from the document= . Therefore: > -- The document should not request any IANA actions > -- The document doesn't UDPDATE 2460 > -- The document doesn't need to be PS. BCP is good enough >=20 >=20 > Recommendation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The Recommendation section should be renamed "Conclusion". It should incl= ude the following statements: >=20 > - The IETF SHOULD NOT standardize an new protocols that rely on IPv6 frag= mentation > ---*New* applications and transport layer protocols SHOULD support effect= ive PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is unreliable > --*New* applications or transport layer protocols that cannot support eff= ective PMTUD MUST NOT in any circumstances send IPv6 packets that exceed th= e IPv6 minimum MTU of 1280 bytes. I'm a little concerned by this. I understand it, I think, but ... So, then the IETF should not standardize RTP or any protocol (voice, video,= ...) that uses it, because RTP relies on its application to manage frame s= ize, and we can't say specifically what the codec will do? s/RTP/UDP/? > - Legacy applications and transport layer protocols will continue to gene= rate fragments > --- In the interest of backwards compatibility, IPv6 stacks and forwardin= g nodes MUST continue to support inbound fragmented IPv6 packets as specifi= ed in [RFC2460]. >=20 > - Implementers and operators need to be aware that on many paths through = the Internet, IPv6 fragmentation will fail. Legacy applications and transpo= rt layer protocols that do not conform to the previous paragraph can expect= connectivity failures as a result. > --- Therefore, if a legacy protocol is capable of breaking its dependence= on IPv6 fragmentation, it should consider doing so. That I agree with. > Did I miss anything? >=20 > Ron >=20 >=20 >>=20 >> hmmm. i am gonna put my foot in the cow pie. >> i think what we want here is something close to >> o future implementations SHOULD not generate frags >> (note that SHOULD !=3D MUST) >> o expect to receive frags for a long time >>=20 >> randy >=20 >=20 >=20 ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies From fgont@si6networks.com Tue Jul 30 01:55:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68AF11E81C9 for ; Tue, 30 Jul 2013 01: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 1j8xKq8-lHza for ; Tue, 30 Jul 2013 01:55:23 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4C49C21F9E89 for ; Tue, 30 Jul 2013 01:54:10 -0700 (PDT) Received: from [2001:df8:0:64:74fa:84a8:e593:8f89] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V45gz-0000RF-Bh; Tue, 30 Jul 2013 10:54:05 +0200 Message-ID: <51F77E1B.4090107@si6networks.com> Date: Tue, 30 Jul 2013 10:49:31 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ronald Bonica Subject: Re: "Deprecate" References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Maintanence , Bob Hinden , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:55:26 -0000 Hi, Ron, > - Legacy applications and transport layer protocols will continue to > generate fragments --- In the interest of backwards compatibility, > IPv6 stacks and forwarding nodes MUST continue to support inbound > fragmented IPv6 packets as specified in [RFC2460]. I'm not sure I'd use RFC2119 language, since support for fragmentation is std track -- hence recommending something in this respect would be more std track than bcp. Besides, if you mention support for reassembly, you should also mention support for fragmentation. Otherwise, I fully agree with your proposed way forward. 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 Tue Jul 30 02:07:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3E11E80DF for ; Tue, 30 Jul 2013 02:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.217 X-Spam-Level: X-Spam-Status: No, score=-100.217 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTWSbLcBhXSV for ; Tue, 30 Jul 2013 02:06:37 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 084BA21E80E8 for ; Tue, 30 Jul 2013 02:03:04 -0700 (PDT) Received: from mail51-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE022.bigfish.com (10.3.207.144) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 09:02:56 +0000 Received: from mail51-am1 (localhost [127.0.0.1]) by mail51-am1-R.bigfish.com (Postfix) with ESMTP id 883BF120178 for ; Tue, 30 Jul 2013 09:02:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zz62a3I9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail51-am1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=rbonica@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail51-am1 (localhost.localdomain [127.0.0.1]) by mail51-am1 (MessageSwitch) id 1375174974400296_27864; Tue, 30 Jul 2013 09:02:54 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.238]) by mail51-am1.bigfish.com (Postfix) with ESMTP id 5E0543E0047 for ; Tue, 30 Jul 2013 09:02:54 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.51) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 09:02:54 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 02:02:52 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Tue, 30 Jul 2013 02:02:51 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 02:07:00 -0700 Received: from mail4-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 09:02:50 +0000 Received: from mail4-co1 (localhost [127.0.0.1]) by mail4-co1-R.bigfish.com (Postfix) with ESMTP id C043BE034E for ; Tue, 30 Jul 2013 09:02:50 +0000 (UTC) Received: from mail4-co1 (localhost.localdomain [127.0.0.1]) by mail4-co1 (MessageSwitch) id 1375174969457287_22010; Tue, 30 Jul 2013 09:02:49 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.245]) by mail4-co1.bigfish.com (Postfix) with ESMTP id 5B78144004A; Tue, 30 Jul 2013 09:02:49 +0000 (UTC) Received: from BY2PRD0511HT001.namprd05.prod.outlook.com (157.56.237.149) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 09:02:47 +0000 Received: from BY2PRD0511MB428.namprd05.prod.outlook.com ([169.254.5.84]) by BY2PRD0511HT001.namprd05.prod.outlook.com ([10.255.129.36]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 09:02:47 +0000 From: Ronald Bonica To: Fernando Gont Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjGh+iYfnka6nOUeBop7mpmo4Zpl8jlmAgAAxvQCAAAnxgIAAEp3wgAAN9ICAAAN7oA== Date: Tue, 30 Jul 2013 09:02:46 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2512713530@BY2PRD0511MB428.namprd05.prod.outlook.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod <51F77E1B.4090107@si6networks.com> In-Reply-To: <51F77E1B.4090107@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%SI6NETWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PSG.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: IPv6 Maintanence , Bob Hinden , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:07:37 -0000 Sure! s/MUST/will/ ron > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Tuesday, July 30, 2013 10:50 AM > To: Ronald Bonica > Cc: Randy Bush; Bob Hinden; IPv6 Maintanence; Fred Baker (fred) > Subject: Re: "Deprecate" >=20 > Hi, Ron, >=20 > > - Legacy applications and transport layer protocols will continue to > > generate fragments --- In the interest of backwards compatibility, > > IPv6 stacks and forwarding nodes MUST continue to support inbound > > fragmented IPv6 packets as specified in [RFC2460]. >=20 > I'm not sure I'd use RFC2119 language, since support for fragmentation > is std track -- hence recommending something in this respect would be > more std track than bcp. >=20 > Besides, if you mention support for reassembly, you should also mention > support for fragmentation. >=20 > Otherwise, I fully agree with your proposed way forward. >=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 >=20 >=20 >=20 From rbonica@juniper.net Tue Jul 30 02:24:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9865821F93F3 for ; Tue, 30 Jul 2013 02:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.8 X-Spam-Level: X-Spam-Status: No, score=-99.8 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWDZYBpJ81ah for ; Tue, 30 Jul 2013 02:24:20 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5726721E808A for ; Tue, 30 Jul 2013 02:21:56 -0700 (PDT) Received: from mail172-db8-R.bigfish.com (10.174.8.237) by DB8EHSOBE040.bigfish.com (10.174.4.103) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 09:21:54 +0000 Received: from mail172-db8 (localhost [127.0.0.1]) by mail172-db8-R.bigfish.com (Postfix) with ESMTP id 5210EA800F0 for ; Tue, 30 Jul 2013 09:21:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zz98dI9371I542I1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h177df4h17326ah1de096h1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail172-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=rbonica@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail172-db8 (localhost.localdomain [127.0.0.1]) by mail172-db8 (MessageSwitch) id 1375176113209008_21472; Tue, 30 Jul 2013 09:21:53 +0000 (UTC) Received: from DB8EHSMHS031.bigfish.com (unknown [10.174.8.250]) by mail172-db8.bigfish.com (Postfix) with ESMTP id 2C815100045 for ; Tue, 30 Jul 2013 09:21:53 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.50) by DB8EHSMHS031.bigfish.com (10.174.4.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 09:21:52 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 02:21:46 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Tue, 30 Jul 2013 02:21:45 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.181) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 02:34:43 -0700 Received: from mail3-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 09:21:44 +0000 Received: from mail3-ch1 (localhost [127.0.0.1]) by mail3-ch1-R.bigfish.com (Postfix) with ESMTP id 4A255E00F9 for ; Tue, 30 Jul 2013 09:21:44 +0000 (UTC) Received: from mail3-ch1 (localhost.localdomain [127.0.0.1]) by mail3-ch1 (MessageSwitch) id 1375176102191658_13177; Tue, 30 Jul 2013 09:21:42 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail3-ch1.bigfish.com (Postfix) with ESMTP id 28CD23C005B; Tue, 30 Jul 2013 09:21:42 +0000 (UTC) Received: from BY2PRD0511HT004.namprd05.prod.outlook.com (157.56.237.149) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 09:21:40 +0000 Received: from BY2PRD0511MB428.namprd05.prod.outlook.com ([169.254.5.84]) by BY2PRD0511HT004.namprd05.prod.outlook.com ([10.255.129.39]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 09:21:39 +0000 From: Ronald Bonica To: "Fred Baker (fred)" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjGh+iYfnka6nOUeBop7mpmo4Zpl8jlmAgAAxvQCAAAnxgIAAEp3wgAAL4gCAAAmo8A== Date: Tue, 30 Jul 2013 09:21:39 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE251271361B@BY2PRD0511MB428.namprd05.prod.outlook.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PSG.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: IPv6 Maintanence , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:24:26 -0000 Inline..... > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Tuesday, July 30, 2013 10:42 AM > To: Ronald Bonica > Cc: Randy Bush; Bob Hinden; IPv6 Maintanence > Subject: Re: "Deprecate" >=20 > I mostly agree. Some fuzz. >=20 > On Jul 30, 2013, at 10:34 AM, Ronald Bonica > wrote: >=20 > > Folks, > > > > I think that we heard the following at yesterday's meeting: > > > > Title > > =3D=3D=3D=3D=3D > > The document should be renamed "IPv6 Fragmentation Considered > Ineffective" >=20 > "Ineffective" has to be modified by "for some specific purpose". Is it > ineffective at getting packets through end to end? Ineffective at > getting through firewalls? What? >=20 How about "IPv6 Fragmentation Considered Ineffective for End-to-end Transpo= rt"? > > Deprecation > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > All instances of the word "deprecate" should be removed from the > document. Therefore: > > -- The document should not request any IANA actions > > -- The document doesn't UDPDATE 2460 > > -- The document doesn't need to be PS. BCP is good enough > > > > > > Recommendation > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Recommendation section should be renamed "Conclusion". It should > include the following statements: > > > > - The IETF SHOULD NOT standardize an new protocols that rely on IPv6 > > fragmentation > > ---*New* applications and transport layer protocols SHOULD support > > effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is > > unreliable > > --*New* applications or transport layer protocols that cannot support > effective PMTUD MUST NOT in any circumstances send IPv6 packets that > exceed the IPv6 minimum MTU of 1280 bytes. >=20 > I'm a little concerned by this. I understand it, I think, but ... >=20 > So, then the IETF should not standardize RTP or any protocol (voice, > video, ...) that uses it, because RTP relies on its application to > manage frame size, and we can't say specifically what the codec will > do? s/RTP/UDP/? >=20 Thinking a little more about it, RTP and UDP aren't the real culprits. The = culprits are the applications that run over them. So, we should limit our s= tatement to applications, and not "applications and transport layer protoco= ls". Ron > > - Legacy applications and transport layer protocols will continue to > > generate fragments > > --- In the interest of backwards compatibility, IPv6 stacks and > forwarding nodes MUST continue to support inbound fragmented IPv6 > packets as specified in [RFC2460]. > > > > - Implementers and operators need to be aware that on many paths > through the Internet, IPv6 fragmentation will fail. Legacy applications > and transport layer protocols that do not conform to the previous > paragraph can expect connectivity failures as a result. >=20 > > --- Therefore, if a legacy protocol is capable of breaking its > dependence on IPv6 fragmentation, it should consider doing so. >=20 > That I agree with. >=20 > > Did I miss anything? > > > > Ron > > > > > >> > >> hmmm. i am gonna put my foot in the cow pie. > >> i think what we want here is something close to o future > >> implementations SHOULD not generate frags > >> (note that SHOULD !=3D MUST) > >> o expect to receive frags for a long time > >> > >> randy > > > > > > >=20 > ------------------------------------------------------ > 8 issues in virtual infrastructure > http://dcrocker.net/#fallacies >=20 >=20 From randy@psg.com Tue Jul 30 04:53:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F121E8063 for ; Tue, 30 Jul 2013 04:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0CNPLEBD8bI for ; Tue, 30 Jul 2013 04:53:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id F306021E808A for ; Tue, 30 Jul 2013 04:53:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1V48U8-0007MM-7X; Tue, 30 Jul 2013 11:53:00 +0000 Date: Tue, 30 Jul 2013 13:52:59 +0200 Message-ID: From: Randy Bush To: Ronald Bonica Subject: Re: "Deprecate" In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE251271361B@BY2PRD0511MB428.namprd05.prod.outlook.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE251271361B@BY2PRD0511MB428.namprd05.prod.outlook.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Maintanence X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:53:13 -0000 > How about "IPv6 Fragmentation Considered Ineffective for End-to-end > Transport"? ipv6 fragmentation does not work reliably on the internet and is highly unlikely to do so in your career's lifetime. yes, pmtud is the right thing, but it can not be relied on. get over it. > Thinking a little more about it, RTP and UDP aren't the real culprits. > The culprits are the applications that run over them. So, we should > limit our statement to applications, and not "applications and > transport layer protocols". one wednesdays if they're pink. ip frags are not gonna work reliably no matter what generates them. it's annoying. it's a damned shame. but it's reality. get over it. randy From rdroms@cisco.com Tue Jul 30 07:42:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375EE11E8213 for ; Tue, 30 Jul 2013 07:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 LFDymZwxZNOf for ; Tue, 30 Jul 2013 07:42:33 -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 CDBB611E8210 for <6man@ietf.org>; Tue, 30 Jul 2013 07:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1922; q=dns/txt; s=iport; t=1375195348; x=1376404948; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pnf/EQaDW8ZYGKo7Bqb1BP8y87HQhY815jmIM/xX99g=; b=RlACJC5QKz1ZLftwC0aF0MAZNS2bT6RaxKC6qpGSL8BYMWtyPoefUILS P/6AmWiAozrXNSSRYxd3wKqUa+Xw0UsOgLt+P13Ng3US2U/Txy2fT6dEn 4zMXze1BEOU6gVNX7qDe/sLwI2YDP2JYP6PM1m8esx+5E9PFpQ5BGqAkc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFABbQ91GtJV2b/2dsb2JhbABbgwY1Sga+FIEcFnSCJAEBAQMBOj0SAgEIIhQQMiUCBBMIAYgBBgcFuTuPSwI4gxhxA5kIkCODFIIq X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208";a="241122150" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 30 Jul 2013 14:42:28 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6UEgSEP025631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6man@ietf.org>; Tue, 30 Jul 2013 14:42:28 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.242]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 09:42:28 -0500 From: "Ralph Droms (rdroms)" To: "6man@ietf.org" <6man@ietf.org> Subject: Re: New Version Notification for draft-droms-6man-multicast-scopes-02.txt Thread-Topic: New Version Notification for draft-droms-6man-multicast-scopes-02.txt Thread-Index: AQHOjTKBUSTAre6Md0aSXCSdetOA15l9n3KA Date: Tue, 30 Jul 2013 14:42:28 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA37C9AE4@xmb-aln-x04.cisco.com> References: <20130730143843.19014.69414.idtracker@ietfa.amsl.com> In-Reply-To: <20130730143843.19014.69414.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.144] Content-Type: text/plain; charset="us-ascii" Content-ID: <45FC14514DEDF643B76D0265BC55DC10@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:42:38 -0000 This rev includes the fixes discussed and agreed to in the 6man WG meeting = on 7/29: * Added text to section 1 citing draft-ietf-roll-trickle-mcast as an exampl= e case for the redefinition of scop 3 * Changed the definition of scop 3 to: 3 Realm-Local scope * Added a paragraph, based on the suggestion from Dave Thaler, further defi= ning "Realm-Local scope": Realm-Local scope is the largest scope that is automatically=09 configured, i.e., automatically derived from physical=09 connectivity or other, non-multicast-related configuration. * s/Network-Specific/Realm-Local/ throughout Please review this rev for acceptance as a WG document. - Ralph PS There was an intermediate -01 rev; I needed to publish -02 to change RFC= 6550 to be an Informative Reference. On Jul 30, 2013, at 4:38 PM 7/30/13, wrote: >=20 > A new version of I-D, draft-droms-6man-multicast-scopes-02.txt > has been successfully submitted by Ralph Droms and posted to the > IETF repository. >=20 > Filename: draft-droms-6man-multicast-scopes > Revision: 02 > Title: IPv6 Multicast Address Scopes > Creation date: 2013-07-30 > Group: Individual Submission > Number of pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-droms-6man-mul= ticast-scopes-02.txt > Status: http://datatracker.ietf.org/doc/draft-droms-6man-multica= st-scopes > Htmlized: http://tools.ietf.org/html/draft-droms-6man-multicast-sc= opes-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-droms-6man-mult= icast-scopes-02 >=20 > Abstract: > This document updates the definitions of IPv6 multicast scopes. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From Fred.L.Templin@boeing.com Tue Jul 30 07:46:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A15521F96CA for ; Tue, 30 Jul 2013 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyIWOyLBJUQD for ; Tue, 30 Jul 2013 07:46:51 -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 5264E21E80D8 for ; Tue, 30 Jul 2013 07:46:37 -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 r6UEkaTq001206 for ; Tue, 30 Jul 2013 07:46:36 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6UEkZNw001201 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 30 Jul 2013 07:46:36 -0700 Received: from XCH-BLV-203.nw.nos.boeing.com (10.57.37.65) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 30 Jul 2013 07:46:35 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.176]) with mapi id 14.02.0328.011; Tue, 30 Jul 2013 07:46:35 -0700 From: "Templin, Fred L" To: Ronald Bonica , Randy Bush , "Bob Hinden" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjGh+iYfnka6nOUeBop7mpmo4Zpl8jlmAgAAxvQCAAAnxgIAAEp3wgABroqA= Date: Tue, 30 Jul 2013 14:46:34 +0000 Message-ID: <2134F8430051B64F815C691A62D983180D66E2@XCH-BLV-504.nw.nos.boeing.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: IPv6 Maintanence , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:46:57 -0000 Hi Ron, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, July 30, 2013 1:34 AM > To: Randy Bush; Bob Hinden > Cc: IPv6 Maintanence; Fred Baker (fred) > Subject: RE: "Deprecate" >=20 > Folks, >=20 > I think that we heard the following at yesterday's meeting: >=20 > Title > =3D=3D=3D=3D=3D > The document should be renamed "IPv6 Fragmentation Considered > Ineffective" I disagree with any name of the form "Fragmentation Considered X"; otherwise, I would have called my doc "Fragmentation Considered Useful". The "X Considered Y" naming convention came from Dijkstra's "Go To Considered Harmful", but gotos are still widely used, e.g., in operating system kernel code. Plus, I personally find any use of "X Considered Y" to be a copycat clich=E9. > Deprecation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > All instances of the word "deprecate" should be removed from the > document. Therefore: > -- The document should not request any IANA actions > -- The document doesn't UDPDATE 2460 > -- The document doesn't need to be PS. BCP is good enough >=20 >=20 > Recommendation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The Recommendation section should be renamed "Conclusion". It should > include the following statements: >=20 > - The IETF SHOULD NOT standardize an new protocols that rely on IPv6 > fragmentation > ---*New* applications and transport layer protocols SHOULD support > effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is > unreliable > --*New* applications or transport layer protocols that cannot support > effective PMTUD MUST NOT in any circumstances send IPv6 packets that > exceed the IPv6 minimum MTU of 1280 bytes. >=20 > - Legacy applications and transport layer protocols will continue to > generate fragments > --- In the interest of backwards compatibility, IPv6 stacks and > forwarding nodes MUST continue to support inbound fragmented IPv6 > packets as specified in [RFC2460]. >=20 > - Implementers and operators need to be aware that on many paths > through the Internet, IPv6 fragmentation will fail. Legacy applications > and transport layer protocols that do not conform to the previous > paragraph can expect connectivity failures as a result. > --- Therefore, if a legacy protocol is capable of breaking its > dependence on IPv6 fragmentation, it should consider doing so. >=20 >=20 > Did I miss anything? You missed tunnels. The tunnel has no way of knowing whether the source host is doing RFC4821-style probing, so it has no way of knowing when to drop vs forward. All it knows is that it MUST pass packets of at least 1280 bytes (the IPv6 minMTU), and SHOULD also pass packets of at least 1500 bytes (the minimum size most hosts expect). For that, it needs some form of fragmentation and reassembly, and if you want to deprecate IPv6 fragmentation you need to replace it with something like SEAL. Thanks - Fred fred.l.templin@boeing.com > Ron >=20 >=20 > > > > hmmm. i am gonna put my foot in the cow pie. > > i think what we want here is something close to > > o future implementations SHOULD not generate frags > > (note that SHOULD !=3D MUST) > > o expect to receive frags for a long time > > > > randy >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From mcr@sandelman.ca Tue Jul 30 08:18:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B408221F9D5A for ; Tue, 30 Jul 2013 08:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE4ladVt0kkI for ; Tue, 30 Jul 2013 08:18:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB3021F9DBD for <6man@ietf.org>; Tue, 30 Jul 2013 08:17:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B69142018A; Tue, 30 Jul 2013 12:23:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 219DC63A7C; Tue, 30 Jul 2013 11:16:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0E9F5636AD; Tue, 30 Jul 2013 11:16:33 -0400 (EDT) From: Michael Richardson To: "Ralph Droms \(rdroms\)" Subject: Re: New Version Notification for draft-droms-6man-multicast-scopes-02.txt In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA37C9AE4@xmb-aln-x04.cisco.com> References: <20130730143843.19014.69414.idtracker@ietfa.amsl.com> <4518F39EB578034D8C99A9B7776CDBA37C9AE4@xmb-aln-x04.cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:18:10 -0000 --=-=-= Ralph Droms (rdroms) wrote: > * Added a paragraph, based on the suggestion from Dave Thaler, further defining "Realm-Local scope": > Realm-Local scope is the largest scope that is automatically > configured, i.e., automatically derived from physical > connectivity or other, non-multicast-related configuration. > * s/Network-Specific/Realm-Local/ throughout Thank you. I really was afraid of "network" being too generic, but I held my nose. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUffYzoqHRg3pndX9AQLWtgQAs3Np4mvJZONVnrm7P+l2axRjatMrteVo NkTt3/N66hqw2CkPmaNLJDp9XEoJuL45+DUpRurKNBlR3ofKSRosdaKwjSy4HHwU E2844azRjynyxnWOlPHhYKlmzlxlAy9ijQC1NpPuubs50000cea58Wvxlq9NyFVM IzK2yjyl0gk= =pZEY -----END PGP SIGNATURE----- --=-=-=-- From bob.hinden@gmail.com Tue Jul 30 08:18:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD9221F9DCE for ; Tue, 30 Jul 2013 08:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA9pP0mSthEQ for ; Tue, 30 Jul 2013 08:18:33 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4411621F9D9A for ; Tue, 30 Jul 2013 08:18:33 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so5118326wes.6 for ; Tue, 30 Jul 2013 08:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dobGcWHP+Y8740ytJjYa6YbX69CN1a+w74tI0x2ZXgc=; b=LILKju8FS9YfeJYHUfLytnzZ+vdm8DYDCweNlYQDwc+mg0uktkjMKGfi8C7Y+FMZyI YVl+FPMaW9sWJ/mM07bT0GSFEMYgYPYYZa03EwCW3nA2bZuhXqq4PLE4uarqUK6grfFW 7WaeJJcZMKkdMcVQiXDQcJzuC2M2uo2Wh+yMZkCLF9G83LTrqchrODprOZauvGEc/F/P 8aevbrEift88H8WiVIb7tXCbXfZzF63ZPGflBgIRyuJ5BS6t3tRMh0PjFWfL0dBeH12f 2Z2pQXGKii67Va30zIsKN2ZJ7qh1PTTNRQJVjOTVq6H0KEG72jjm73LvFqmo/fgoNyKw GOHQ== X-Received: by 10.194.243.164 with SMTP id wz4mr46975662wjc.28.1375197509623; Tue, 30 Jul 2013 08:18:29 -0700 (PDT) Received: from ?IPv6:2001:df8::32:3d1a:e4f8:9781:7029? ([2001:df8:0:32:3d1a:e4f8:9781:7029]) by mx.google.com with ESMTPSA id j20sm29177928wie.7.2013.07.30.08.18.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 08:18:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: "Deprecate" From: Bob Hinden In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> Date: Tue, 30 Jul 2013 17:18:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07C36E38-16BA-4833-BD47-56E3238B1FDB@gmail.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1508) Cc: IPv6 Maintanence , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:18:35 -0000 Ron, On Jul 30, 2013, at 10:34 AM, Ronald Bonica wrote: >=20 >=20 > Did I miss anything? >=20 > Ron Yes, I think the draft (especially since is headed toward BCP) should = also include a message that PMTUD is useful and should not be blocked by = routers/firewalls/middleboxes/etc. There are lots of valid reasons to = not want to do IPv6 fragmentation, but there was a lot of discussion = about encouraging the use of PMTUD. Bob From Fred.L.Templin@boeing.com Tue Jul 30 08:44:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365A921F9B19 for ; Tue, 30 Jul 2013 08:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MWgqmOdcSjB for ; Tue, 30 Jul 2013 08:44:32 -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 AF1B011E81FD for ; Tue, 30 Jul 2013 08:44:28 -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 r6UFiQeI007036 for ; Tue, 30 Jul 2013 08:44:26 -0700 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6UFiPJK007032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 30 Jul 2013 08:44:25 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.239]) with mapi id 14.02.0328.011; Tue, 30 Jul 2013 08:44:25 -0700 From: "Templin, Fred L" To: Bob Hinden , Ronald Bonica Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjTgKiYfnka6nOUeBop7mpmo4Zpl9XFSA Date: Tue, 30 Jul 2013 15:44:25 +0000 Message-ID: <2134F8430051B64F815C691A62D983180D782A@XCH-BLV-504.nw.nos.boeing.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <07C36E38-16BA-4833-BD47-56E3238B1FDB@gmail.com> In-Reply-To: <07C36E38-16BA-4833-BD47-56E3238B1FDB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: IPv6 Maintanence X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:44:37 -0000 Hi Bob, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Bob Hinden > Sent: Tuesday, July 30, 2013 8:18 AM > To: Ronald Bonica > Cc: IPv6 Maintanence; Bob Hinden > Subject: Re: "Deprecate" >=20 > Ron, >=20 > On Jul 30, 2013, at 10:34 AM, Ronald Bonica > wrote: > > > > > > Did I miss anything? > > > > Ron >=20 > Yes, I think the draft (especially since is headed toward BCP) should > also include a message that PMTUD is useful and should not be blocked > by routers/firewalls/middleboxes/etc. There are lots of valid reasons > to not want to do IPv6 fragmentation, but there was a lot of discussion > about encouraging the use of PMTUD. That's all good, but there will still be end systems that do not implement PMTUD - neither RFC1981 nor RFC4821. Plus, try as we may there will still be paths over which PTB messages will not be delivered - but I agree that we should still try. Thanks - Fred fred.l.templin@boeing.com =20 > Bob >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jhw@apple.com Tue Jul 30 12:07:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ACF11E822B for ; Tue, 30 Jul 2013 12:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KJXkAX8WjpG for ; Tue, 30 Jul 2013 12:06:55 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 744EA21F9A5F for ; Tue, 30 Jul 2013 12:06:55 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) 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 <0MQR009JMJQXYQ50@mail-out.apple.com> for ipv6@ietf.org; Tue, 30 Jul 2013 12:06:54 -0700 (PDT) X-AuditID: 11807157-b7f1a6d000003e11-a6-51f80ecec44f Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 28.C1.15889.ECE08F15; Tue, 30 Jul 2013 12:06:54 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MQR00ITMJRI0X20@aniseed.apple.com> for ipv6@ietf.org; Tue, 30 Jul 2013 12:06:54 -0700 (PDT) Subject: Re: "Deprecate" From: james woodyatt In-reply-to: <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> Date: Tue, 30 Jul 2013 12:06:53 -0700 Message-id: References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> To: IPv6 Maintanence X-Mailer: Apple Mail (2.1786.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FAsrnuO70egwaq98hYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxovN19kLTrJUrPx0k7mB8RJzFyMnh4SAicSXO5/ZIGwxiQv3 1oPZQgL9TBInHhp2MXIB2dOZJCZOnM8CkmAW0JJYv/M4E4jNK2AgcWnGfrAGYQEJidaPH9lB bDYBFYlvl++C1XAKJEus+3kJzGYRUJW4fWsjM8QcbYkn7y6wQsyxkVgzYxMTxOJJTBJbTwqC 2CJAc358XMkIcZy8xIpH19gmMPLPQnLGLCRnzEIydgEj8ypGgaLUnMRKE73EgoKcVL3k/NxN jOAAKwzfwfhvmdUhRgEORiUeXscL3wOFWBPLiitzDzFKcDArifCenwgU4k1JrKxKLcqPLyrN SS0+xCjNwaIkzjvjC1BKID2xJDU7NbUgtQgmy8TBKdXAeH/ehc8XRL989HhwckuT3SfByu6s a0bpf7/cnnv8rMPlCLuNjMc1RHL2PzJivzIh001siRzHoSn/S2d4fHbMT9ooafRT1VTH5NSR dnlFS9NZUR6bIxJvfz2Sc9ys4ExJ26zyZbGW+2e8aTIyrRA2U3jRPVtjdUuM3zV758Kilg81 SzfciFi3Q4mlOCPRUIu5qDgRAHO1CnUsAgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 19:07:07 -0000 On Jul 30, 2013, at 01:34 , Ronald Bonica wrote: > > --- Therefore, if a legacy protocol is capable of breaking its dependence on IPv6 fragmentation, it should consider doing so. As I read this latest message, it would appear that this sentence I quoted above is the only remaining thing the draft will actually be telling people in my position to do with legacy host stack implementations. How to say this politely? I think this recommendation is, at best... unnecessary. -- james woodyatt core os networking From rbonica@juniper.net Tue Jul 30 14:56:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4529321E80B0 for ; Tue, 30 Jul 2013 14:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.217 X-Spam-Level: X-Spam-Status: No, score=-100.217 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f9qwD5ESkzf for ; Tue, 30 Jul 2013 14:56:06 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4D86711E8141 for ; Tue, 30 Jul 2013 14:56:06 -0700 (PDT) Received: from mail10-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 21:56:05 +0000 Received: from mail10-va3 (localhost [127.0.0.1]) by mail10-va3-R.bigfish.com (Postfix) with ESMTP id 522D91A00B3 for ; Tue, 30 Jul 2013 21:56:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail10-va3: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail10-va3 (localhost.localdomain [127.0.0.1]) by mail10-va3 (MessageSwitch) id 1375221363345765_31524; Tue, 30 Jul 2013 21:56:03 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.253]) by mail10-va3.bigfish.com (Postfix) with ESMTP id 4D9BC3800D4 for ; Tue, 30 Jul 2013 21:56:03 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.53) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 21:56:02 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 14:56:01 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Tue, 30 Jul 2013 14:56:01 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.189) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 15:00:08 -0700 Received: from mail117-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 21:55:59 +0000 Received: from mail117-co1 (localhost [127.0.0.1]) by mail117-co1-R.bigfish.com (Postfix) with ESMTP id C01B2440073 for ; Tue, 30 Jul 2013 21:55:59 +0000 (UTC) Received: from mail117-co1 (localhost.localdomain [127.0.0.1]) by mail117-co1 (MessageSwitch) id 1375221356674396_22176; Tue, 30 Jul 2013 21:55:56 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.239]) by mail117-co1.bigfish.com (Postfix) with ESMTP id 955037C004C; Tue, 30 Jul 2013 21:55:56 +0000 (UTC) Received: from BY2PRD0511HT005.namprd05.prod.outlook.com (157.56.237.149) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 21:55:56 +0000 Received: from BY2PRD0511MB428.namprd05.prod.outlook.com ([169.254.5.84]) by BY2PRD0511HT005.namprd05.prod.outlook.com ([10.255.129.40]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 21:55:50 +0000 From: Ronald Bonica To: "Templin, Fred L" , Randy Bush , Bob Hinden Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjGh+iYfnka6nOUeBop7mpmo4Zpl8jlmAgAAxvQCAAAnxgIAAEp3wgABroqCAAH2iUA== Date: Tue, 30 Jul 2013 21:55:49 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2512713E52@BY2PRD0511MB428.namprd05.prod.outlook.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180D66E2@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180D66E2@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BOEING.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PSG.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: IPv6 Maintanence , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 21:56:13 -0000 Fred, I was thinking of tunnels as legacy applications, but we may need to make t= his explicit. Ron >=20 > You missed tunnels. The tunnel has no way of knowing whether the source > host is doing RFC4821-style probing, so it has no way of knowing when > to drop vs forward. All it knows is that it MUST pass packets of at > least 1280 bytes (the IPv6 minMTU), and SHOULD also pass packets of at > least 1500 bytes (the minimum size most hosts expect). For that, it > needs some form of fragmentation and reassembly, and if you want to > deprecate IPv6 fragmentation you need to replace it with something like > SEAL. >=20 From brian.e.carpenter@gmail.com Tue Jul 30 15:24:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5B821F90C9 for ; Tue, 30 Jul 2013 15:24:14 -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 cAZcFqV-qFJu for ; Tue, 30 Jul 2013 15:24:13 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D804521F8FDC for ; Tue, 30 Jul 2013 15:24:13 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 5so1948424pdd.34 for ; Tue, 30 Jul 2013 15:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=77UvIoRoxR0CmWGQVNMoyP+jmC35Hn9T891v1pYUivo=; b=D9x+4zutOMrdLVAFaZ2d53boJUS21p2TcNMbiA1QDEJlEWlZz1MMDYB2hCJ5pfIiXP KV74rrneTUAAZFSwe34FoBRYxVIhLP2uL10Ox0wQoZp8u0bdDLqbWcfnxWq+PHH/WVy6 KrVlP3gw4fw/6hLCH9le/RzHxCEi8oTNI7B4Cc9Rz+IOytLsYt5UYj0vbBZwvJTbSnAR UuezWNSrOADXXjHMZO6IVRoBlrksbEiLn0zjvIO07LskBjHcSUrWaT6LufBff+aTtAZY sxtcsSz4NjMv7SyUFljSbBznnOoLA/+ZDbDYZZASq0jDvbcpgyUliVmwbKzk4pb5qxQR 1vkw== X-Received: by 10.66.119.143 with SMTP id ku15mr35334440pab.112.1375223053445; Tue, 30 Jul 2013 15:24:13 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id ss8sm337141pab.6.2013.07.30.15.24.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 15:24:12 -0700 (PDT) Message-ID: <51F83D0F.7090503@gmail.com> Date: Wed, 31 Jul 2013 10:24:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" Subject: Re: "Deprecate" References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Maintanence , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 22:24:14 -0000 On 30/07/2013 20:42, Fred Baker (fred) wrote: > I mostly agree. Some fuzz. >=20 > On Jul 30, 2013, at 10:34 AM, Ronald Bonica > wrote: >=20 >> Folks, >> >> I think that we heard the following at yesterday's meeting: >> >> Title >> =3D=3D=3D=3D=3D >> The document should be renamed "IPv6 Fragmentation Considered Ineffect= ive" >=20 > "Ineffective" has to be modified by "for some specific purpose". Is it = ineffective at getting packets through end to end? Ineffective at getting= through firewalls? What? How about "IPv6 Fragmentation is Ineffective for End-to-end Transport"? (i.e. get rid of the clich=C3=A9 "considered" because we are documenting = a fact). =2E.. >> - The IETF SHOULD NOT standardize an new protocols that rely on IPv6 f= ragmentation >> ---*New* applications and transport layer protocols SHOULD support eff= ective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is unreliable >> --*New* applications or transport layer protocols that cannot support = effective PMTUD MUST NOT in any circumstances send IPv6 packets that exce= ed the IPv6 minimum MTU of 1280 bytes. >=20 > I'm a little concerned by this. I understand it, I think, but ... >=20 > So, then the IETF should not standardize RTP or any protocol (voice, vi= deo, ...) that uses it, because RTP relies on its application to manage f= rame size, and we can't say specifically what the codec will do? s/RTP/UD= P/? With the emphasis on "new", I'm not too concerned. We're saying: unless your packetization layer works properly, you lose. Is that so bad? Brian From rbonica@juniper.net Tue Jul 30 15:26:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AEB21E80B4 for ; Tue, 30 Jul 2013 15:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.267 X-Spam-Level: X-Spam-Status: No, score=-100.267 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mjK1l3KCkf8 for ; Tue, 30 Jul 2013 15:26:16 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9488611E81ED for ; Tue, 30 Jul 2013 15:26:15 -0700 (PDT) Received: from mail58-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 22:26:14 +0000 Received: from mail58-am1 (localhost [127.0.0.1]) by mail58-am1-R.bigfish.com (Postfix) with ESMTP id 967AC1402EC for ; Tue, 30 Jul 2013 22:26:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail58-am1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rbonica@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.241.149; KIP:(null); UIP:(null); (null); H:BL2PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail58-am1 (localhost.localdomain [127.0.0.1]) by mail58-am1 (MessageSwitch) id 1375223172666105_5293; Tue, 30 Jul 2013 22:26:12 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.241]) by mail58-am1.bigfish.com (Postfix) with ESMTP id 9E84C2C0048 for ; Tue, 30 Jul 2013 22:26:12 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.52) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 22:26:12 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 15:26:10 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Tue, 30 Jul 2013 15:25:51 -0700 Received: from CO9EHSOBE007.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 15:38:40 -0700 Received: from mail182-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 22:25:41 +0000 Received: from mail182-co9 (localhost [127.0.0.1]) by mail182-co9-R.bigfish.com (Postfix) with ESMTP id E825A840068 for ; Tue, 30 Jul 2013 22:25:41 +0000 (UTC) Received: from mail182-co9 (localhost.localdomain [127.0.0.1]) by mail182-co9 (MessageSwitch) id 1375223140295372_32017; Tue, 30 Jul 2013 22:25:40 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.243]) by mail182-co9.bigfish.com (Postfix) with ESMTP id 3AE83D80047; Tue, 30 Jul 2013 22:25:40 +0000 (UTC) Received: from BL2PRD0511HT002.namprd05.prod.outlook.com (157.56.241.149) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 22:25:39 +0000 Received: from BL2PRD0511MB421.namprd05.prod.outlook.com ([169.254.10.115]) by BL2PRD0511HT002.namprd05.prod.outlook.com ([10.255.131.37]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 22:25:36 +0000 From: Ronald Bonica To: james woodyatt , IPv6 Maintanence Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjGh+iYfnka6nOUeBop7mpmo4Zpl8jlmAgAAxvQCAAAnxgIAAEp3wgAC6coCAADXz0A== Date: Tue, 30 Jul 2013 22:25:35 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2512715631@BL2PRD0511MB421.namprd05.prod.outlook.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%APPLE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 22:26:22 -0000 James, I disagree. Aside from the advice that you quote below, the draft does two = things: - It admits that there is an operational problem - It instructs the IETF not to make the problem worse by standardizing yet = more applications that rely upon fragmentation. Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > james woodyatt > Sent: Tuesday, July 30, 2013 9:07 PM > To: IPv6 Maintanence > Subject: Re: "Deprecate" >=20 > On Jul 30, 2013, at 01:34 , Ronald Bonica wrote: > > > > --- Therefore, if a legacy protocol is capable of breaking its > dependence on IPv6 fragmentation, it should consider doing so. >=20 > As I read this latest message, it would appear that this sentence I > quoted above is the only remaining thing the draft will actually be > telling people in my position to do with legacy host stack > implementations. >=20 > How to say this politely? I think this recommendation is, at best... > unnecessary. >=20 >=20 > -- > james woodyatt > core os networking >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From heard@pobox.com Tue Jul 30 15:40:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA8421E80B4 for ; Tue, 30 Jul 2013 15:40:27 -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 cS49bPHgAIrw for ; Tue, 30 Jul 2013 15:40:19 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id C348C11E80E2 for ; Tue, 30 Jul 2013 15:40:18 -0700 (PDT) Received: (qmail 29517 invoked from network); 30 Jul 2013 15:40:14 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jul 2013 15:40:14 -0700 Date: Tue, 30 Jul 2013 15:40:14 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: RE: "Deprecate" In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE251271361B@BY2PRD0511MB428.namprd05.prod.outlook.com> Message-ID: References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE251271361B@BY2PRD0511MB428.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 22:40:28 -0000 On Tue, 30 Jul 2013, Ronald Bonica wrote: > Thinking a little more about it, RTP and UDP aren't the real > culprits. The culprits are the applications that run over them. > So, we should limit our statement to applications, and not > "applications and transport layer protocols". I don't agree, at least not if the principal reason why IP fragments get dropped is that they lack the L4 header (or at least that the non-initial fragments do) and thereby break stateless ACLs. The problem is that UDP and its kin such as UDP-lite and DCCP lack transport-layer segmentation, such as is present in TCP, and are thereby force their clients to rely on IP fragmentation to provide this service. So yes, these transport protocols are the culprits. The idea that immediately comes to mind is to design _replacements_ transport protocols for UDP and kin that contain a transport layer segmentation mechanism. These would be for use by applications that can't get by without such a mechanism; existing applications that don't need to rely on IP fragmentation can continue to use UDP and kin. The replacement for UDP might have a header that looks something like this: 0 15 16 31 +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Length | Segment Offset |Res|M| +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | data octets ... +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... (Other and perhaps better possibilities exist, of course.) Having said that, I immediately imagine screaming that such a thing could not possibly be deployed, because operators will filter anything that they don't know or have an immediate use for, and so it would never get any traction. Well, maybe so, but something has to give. The operations folks have complained that IP fragmentation is awful, they have to filter fragments because it defeats their stateless ACLs. OK; let's agree that's a defect that needs to be fixed. But if you don't want the fix to break other important stuff (e.g., DNSSEC, as metioned in Section 3.1 of draft-bonica-6man-frag-deprecate-02), you need a replacement for IP fragmentation (or an augmentation, such as in http://www.ietf.org/mail-archive/web/ipv6/current/msg18389.html by Mark Andrews). Maybe I just lack imagination, but I can't see any fix that does not involve SOME change in operator behavior. //cmh From dougb@dougbarton.us Tue Jul 30 15:41:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B5021E80ED for ; Tue, 30 Jul 2013 15:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9JK4RQIwHvL for ; Tue, 30 Jul 2013 15:41:43 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0E221E80E3 for ; Tue, 30 Jul 2013 15:41:43 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:54b9:794e:89c1:cbb8] (unknown [IPv6:2001:470:d:5e7:54b9:794e:89c1:cbb8]) by dougbarton.us (Postfix) with ESMTPSA id 5E62922B7E for ; Tue, 30 Jul 2013 22:41:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1375224102; bh=jAKpQrZpYVfYxtHrKmbfq/VB4CbwYu3rVN3GiSs7IeA=; h=Date:From:To:Subject:References:In-Reply-To; b=dEaXKv7caHB7M7s+Bi+GYrP7y6HWQLGD4gdi1tdMjYHre2+CbdvQl4hC5BIAzqaO3 otQAeTIhX492sFK8KNtc0MybgcIZS77feqaTJT7sSKWm09fqgzx1uHK0V8OfY4WPgZ lbe/ot9DWg1lEm6W6UkLQascJl/nt15G1NTNQVIM= Message-ID: <51F84124.80807@dougbarton.us> Date: Tue, 30 Jul 2013 15:41:40 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: "Deprecate" References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180D66E2@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713E52@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2512713E52@BY2PRD0511MB428.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 22:41:47 -0000 On 07/30/2013 02:55 PM, Ronald Bonica wrote: > I was thinking of tunnels as legacy applications Yeah, please stop doing that. :) While some of the transitional technologies like 6to4 or proto 41 tunnels will fade away more over time, there is no Internet future where tunnels do not play a critical role. We need to be realistic about that, and plan accordingly. Doug From jhw@apple.com Tue Jul 30 17:01:42 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2D321E8112 for ; Tue, 30 Jul 2013 17:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyCb4hjH5JJI for ; Tue, 30 Jul 2013 17:01:35 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA7B21E810F for ; Tue, 30 Jul 2013 17:01:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQR00FR3XDIDU72@mail-out.apple.com> for ipv6@ietf.org; Tue, 30 Jul 2013 17:01:20 -0700 (PDT) X-AuditID: 11807158-b7f326d000001696-3d-51f853d0ddaa Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id A2.40.05782.0D358F15; Tue, 30 Jul 2013 17:01:20 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MQR0066RXE7S220@aniseed.apple.com> for ipv6@ietf.org; Tue, 30 Jul 2013 17:01:19 -0700 (PDT) Subject: Re: "Deprecate" From: james woodyatt In-reply-to: <2CF4CB03E2AA464BA0982EC92A02CE2512715631@BL2PRD0511MB421.namprd05.prod.outlook.com> Date: Tue, 30 Jul 2013 17:01:19 -0700 Message-id: <44C69D85-EA12-422E-A1DC-7F1EE8133721@apple.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE2512715631@BL2PRD0511MB421.namprd05.prod.outlook.com> To: IPv6 Maintanence X-Mailer: Apple Mail (2.1786.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FAsrnsh+EegwZNz0hYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxorpl5kKdopUzNvTw9zAuE6gi5GTQ0LAROLh9T/MELaYxIV7 69m6GLk4hAT6mSQ+r9nODOFMZ5K4trmNBaSKWUBLYv3O40wgNq+AgcSlGfvZQGxhAQmJ1o8f 2UFsNgEViW+X74LVcAokS8x8t5URxGYRUJU41biNEWKOtsSTdxdYuxg5gObYSHzZ4gixaw6z xNTNEPUiQHN+fFzJCHGdvMSKR9fYJjDyz0JyxiwkZ8xCMnYBI/MqRoGi1JzESlO9xIKCnFS9 5PzcTYzgECuM2MH4f5nVIUYBDkYlHl6HC98DhVgTy4orcw8xSnAwK4nwygf9CBTiTUmsrEot yo8vKs1JLT7EKM3BoiTOO/MLULVAemJJanZqakFqEUyWiYNTqoFx1flNax5XvJi5vOWH2/ye te85G6u51X+9Zr1Vx/JnO+/nNycYeF+JaUe9Lt2xo7aSpehszeKJ1qGPLt2wdJfOF9zA/3Pn JL2V+0Ni2+Yr/mDOPlVwU2zh3BlPlW/ErPk7dfmFkulmdVuF730Rvd3CJioy/VTDm4DHFpoG a/iN61/rx/pGXOZ8o8RSnJFoqMVcVJwIAJMgCvgtAgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 00:01:42 -0000 On Jul 30, 2013, at 15:25 , Ronald Bonica wrote: > > I disagree. Aside from the advice that you quote below, the draft does two things: > > - It admits that there is an operational problem > - It instructs the IETF not to make the problem worse by standardizing yet more applications that rely upon fragmentation. I'm not sure how we are in disagreement, but I still sense we are disagreeing. Somehow. I think the above two things are useful things for IETF to do, and they are reasons to publish an RFC to do it. I also think it isn't a good idea to advise maintainers [like me] of host stacks with legacy application and transport protocols to consider breaking their dependence on IPv6 fragmentation. (This is one of those moments where I wish I were able to express myself candidly in a hotel lobby bar with a half-consumed beer in my hand, so you'll just have to imagine what my version of Linus's infamous "we don't break user space" rant might sound like. I'm mellower, but it still wouldn't be pretty.) On a different but related note, I agree with Fred Templin and others. I still think you're missing something. As it stands now, this document-- as you have said you plan to amend it-- can still be summarized as follows: "[Section 2] IETF wrote standards for IPv6 fragmentation and ICMPv6 path MTU discovery that many operators do not abide. [Section 3] IETF wrote standards for a raft of transport and application protocols that are broken as a result. [Section 4] Sad trombone." I would like to see Section 4 strengthened further, so it can be summarized like so: "IETF will take the following steps to mend the damage." To be more specific, and to repeat myself again repeatedly and for redundancy, IETF should promise-- among other things-- to do something in forthcoming drafts about the problems Fred Templin and I have been prodding the working group to deal with: the lack of PLPMTUD for tunnels like GRE, IPsec, et cetera, which need to carry encapsulated minimum MTU packets over paths where neither fragmentation nor RFC 1981 work. Fragmentation and/or RFC 1981 is essential to those protocols, they are broken wherever both are unavailable, while this draft basically capitulates and says, "That's everywhere you care about. Sorry about that." Most importantly, there are no standard replacements, and no promises ever to produce standard replacements. What is to be done about that? -- james woodyatt core os networking From marka@isc.org Tue Jul 30 17:54:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E80321E8054 for ; Tue, 30 Jul 2013 17:54:35 -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 dPNqzymgFn7l for ; Tue, 30 Jul 2013 17:54:30 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6D30521E811A for ; Tue, 30 Jul 2013 17:54:21 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 9420BC94D1; Wed, 31 Jul 2013 00:54:06 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375232060; bh=6/DIECT7U2QDrguaGGpvtw8t7UtElD7hR94tF5kPf3A=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=RRVfEzxWyKVLMI2oYupbtoVy21u9Sqy6uawGU0lhDLW0uA4vSg2pZDwZXBSZTPGXv OAG7nqlo03yqWSdSfBbBIyq1Mm9N0fKAgdn9aNPym1SIJK4ermNQ8s43Xq4OcpA28z u9WE9CdCXFB6vkrNjHRirpBjgwC6WlVjxUuXtJhw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 31 Jul 2013 00:54:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 972851602D0; Wed, 31 Jul 2013 00:57:49 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 33fVYHEl9kLg; Wed, 31 Jul 2013 00:57:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 164F61602CF; Wed, 31 Jul 2013 00:57:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UvkkrGoVOsFG; Wed, 31 Jul 2013 00:57:48 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8C7361602CE; Wed, 31 Jul 2013 00:57:48 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5566437DED06; Wed, 31 Jul 2013 10:54:03 +1000 (EST) To: james woodyatt From: Mark Andrews References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE2512715631@BL2PRD0511MB421.namprd05.prod.outlook.com> <44C69D85-EA12-422E-A1DC-7F1EE8133721@apple.com> Subject: Re: "Deprecate" In-reply-to: Your message of "Tue, 30 Jul 2013 17:01:19 -0700." <44C69D85-EA12-422E-A1DC-7F1EE8133721@apple.com> Date: Wed, 31 Jul 2013 10:54:03 +1000 Message-Id: <20130731005403.5566437DED06@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Maintanence X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 00:54:35 -0000 In message <44C69D85-EA12-422E-A1DC-7F1EE8133721@apple.com>, james woodyatt wri tes: > On Jul 30, 2013, at 15:25 , Ronald Bonica wrote: > > > > I disagree. Aside from the advice that you quote below, the draft does two > things: > > > > - It admits that there is an operational problem > > - It instructs the IETF not to make the problem worse by standardizing yet > more applications that rely upon fragmentation. > > I'm not sure how we are in disagreement, but I still sense we are disagreeing > . Somehow. > > I think the above two things are useful things for IETF to do, and they are r > easons to publish an RFC to do it. I also think it isn't a good idea to advi > se maintainers [like me] of host stacks with legacy application and transport > protocols to consider breaking their dependence on IPv6 fragmentation. (Thi > s is one of those moments where I wish I were able to express myself candidly > in a hotel lobby bar with a half-consumed beer in my hand, so you'll just ha > ve to imagine what my version of Linus's infamous "we don't break user space" > rant might sound like. I'm mellower, but it still wouldn't be pretty.) > > On a different but related note, I agree with Fred Templin and others. I sti > ll think you're missing something. > > As it stands now, this document-- as you have said you plan to amend it-- can > still be summarized as follows: "[Section 2] IETF wrote standards for IPv6 f > ragmentation and ICMPv6 path MTU discovery that many operators do not abide. > [Section 3] IETF wrote standards for a raft of transport and application prot > ocols that are broken as a result. [Section 4] Sad trombone." > > I would like to see Section 4 strengthened further, so it can be summarized l > ike so: "IETF will take the following steps to mend the damage." To be more > specific, and to repeat myself again repeatedly and for redundancy, IETF shou > ld promise-- among other things-- to do something in forthcoming drafts about > the problems Fred Templin and I have been prodding the working group to deal > with: the lack of PLPMTUD for tunnels like GRE, IPsec, et cetera, which need > to carry encapsulated minimum MTU packets over paths where neither fragmenta > tion nor RFC 1981 work. Fragmentation and/or RFC 1981 is essential to those > protocols, they are broken wherever both are unavailable, while this draft ba > sically capitulates and says, "That's everywhere you care about. Sorry about > that." Most importantly, there are no standard replacements, and no promises > ever to produce standard replacements. What is to be done about that? I can write up my suggestion as a I-D. It provides the information stateless middleware needs to pass fragments. It also helps firewalls that decide they need to see the entire contents of packets by providing protection to their reassembly queues. > -- > james woodyatt > core os networking > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From randy@psg.com Tue Jul 30 21:46:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74B421F9A05 for ; Tue, 30 Jul 2013 21:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQX0-DXknWix for ; Tue, 30 Jul 2013 21:46:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id 902BE21F99AB for ; Tue, 30 Jul 2013 21:46:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1V4OId-0007K3-Cs; Wed, 31 Jul 2013 04:46:11 +0000 Date: Wed, 31 Jul 2013 06:46:10 +0200 Message-ID: From: Randy Bush To: Bob Hinden Subject: Re: "Deprecate" In-Reply-To: <07C36E38-16BA-4833-BD47-56E3238B1FDB@gmail.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <07C36E38-16BA-4833-BD47-56E3238B1FDB@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 04:46:17 -0000 > I think the draft (especially since is headed toward BCP) should also > include a message that PMTUD is useful and should not be blocked by > routers/firewalls/middleboxes/etc. i might say SHOULD NOT but i would also be clear that the operator/user will find that it is often the case that PMTUD does not work on man paths. off-pissing? yes. but a lot of reality is. randy From otroan@employees.org Wed Jul 31 01:24:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D44321F9AC4 for ; Wed, 31 Jul 2013 01:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igZyt4LFYpip for ; Wed, 31 Jul 2013 01:23:59 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8116621F9C81 for ; Wed, 31 Jul 2013 01:22:27 -0700 (PDT) Received: from dhcp-10-61-97-185.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 505B65F70; Wed, 31 Jul 2013 01:22:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: 6MAN WG Last Call: From: Ole Troan In-Reply-To: <51F6D5B1.2010208@gmail.com> Date: Wed, 31 Jul 2013 10:22:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FBF2013-BD8B-4783-AE70-162799332CCC@employees.org> References: <51F670EF.2070809@kit.edu> <51F6D5B1.2010208@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:24:05 -0000 Brian, (participant hat) >> I found the last statements in section 4 slightly confusing: >> There is no algorithm >> for determining whether this case has arisen, rather than a genuine >> MAC address collision. Implementers should carefully consider the >> consequences of continuing IPv6 operation on the interface in this >> unlikely situation. >>=20 >> 1.) DAD should actually detect that collision >=20 > Yes, but it cannot detect the cause. why not? can't the node just check the L2 source address against it's own? I suggest removing the sentence: "There is no algorithm for determining whether this case has arisen, = rather than a genuine MAC address collision. " cheers, Ole= From otroan@employees.org Wed Jul 31 02:09:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A88B21E8082 for ; Wed, 31 Jul 2013 02:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRzWVLRyDBz9 for ; Wed, 31 Jul 2013 02:09:48 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 7A24C21F9DAB for ; Wed, 31 Jul 2013 02:02:03 -0700 (PDT) Received: from dhcp-10-61-97-185.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 90E855E5C; Wed, 31 Jul 2013 02:01:54 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Confirmation to adopt draft-cooper-6man-ipv6-address-generation-privacy-00 as a WG item Date: Wed, 31 Jul 2013 11:01:53 +0200 Message-Id: <659E8DB1-582F-4465-8E20-1F0EDB501E82@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:09:56 -0000 There was consensus to adopt = draft-cooper-6man-ipv6-address-generation-privacy-00 as a 6MAN working = group item at the IETF87 working group meeting. This is a call to = confirm that consensus on the mailing list. If you object to adopting this document please state so and your = reasons. This call will end on 2013-08-07. Best regards, Ole and Bob= From otroan@employees.org Wed Jul 31 02:10:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D7121F8F78 for ; Wed, 31 Jul 2013 02:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 00b5WiWuigu1 for ; Wed, 31 Jul 2013 02:10:43 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 623C121F9C6A for ; Wed, 31 Jul 2013 02:03:24 -0700 (PDT) Received: from dhcp-10-61-97-185.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id A01A65E9C; Wed, 31 Jul 2013 02:03:11 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Confirmation to adopt draft-droms-6man-multicast-scopes-02 as a WG item Date: Wed, 31 Jul 2013 11:03:09 +0200 Message-Id: <0536DB01-A4BC-4B83-A759-08EE25BB0774@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:10:47 -0000 There was consensus to adopt draft-droms-6man-multicast-scopes-02 as a = 6MAN working group item at the IETF87 working group meeting. This is a = call to confirm that consensus on the mailing list. If you object to adopting this document please state so and your = reasons. This call will end on 2013-08-07. Best regards, Ole and Bob= From linda.dunbar@huawei.com Wed Jul 31 02:16:08 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3107C21F9D05; Wed, 31 Jul 2013 02:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 agkFxxvXVKdo; Wed, 31 Jul 2013 02:16:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E5BA121F9D12; Wed, 31 Jul 2013 02:11:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVP16407; Wed, 31 Jul 2013 09:11:25 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 10:11:11 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 10:11:20 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 02:11:16 -0700 From: Linda Dunbar To: "ipv6@ietf.org" , Internet Area Subject: any concerns of SEND mixed with Proxy Gateway described in draft-nachum-sarp-06? Thread-Topic: any concerns of SEND mixed with Proxy Gateway described in draft-nachum-sarp-06? Thread-Index: Ac6NzewNJHkq28RwQ12LSg9ChiEyhA== Date: Wed, 31 Jul 2013 09:11:16 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B5269D@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.90] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B5269Ddfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Brian Haberman , Suresh Krishnan , Tal Mizrahi X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:16:08 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645B5269Ddfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-nachum-sarp-06 proposes a Proxy Gateway m= echanism to limit switches' FDB (MAC table) sizes in an environment where h= osts (or VMs) within one subnet (or VLAN) can spread over many access domai= ns (or shelves or sites) and each access domain has hosts (VMs) belonging t= o many subnets (or VLANs). The main idea of SARP is to represent all VMs (or hosts) under each access = domain by their corresponding access (or aggregation) node's MAC address re= gardless whether the access (or aggregation) node is the VMs (hosts)' gatew= ay or not. For example, when a host "a" under access domain "S" needs to co= mmunicate with peers on the same VLAN but connected to different access dom= ains, SARP requires "a" to use remote access node's MAC address rather than= peers' MAC addresses. By doing so, switches in each domain do not need to = maintain a list of MAC addresses for all the VMs (hosts) in different acces= s domains in their FDBs. Therefore, the switches' FDB size is limited regar= dless how VLAN is spread. However, when SEND is used, Access (or Aggregation) switches might not poss= ess knowledge of the attached hosts (VMs)' private keys. Are there any concerns/feedback for giving the following recommendation in = our draft? Any preferences? 1) state that SARP is not recommended when SEND is deployed; 2) recommend using RFC6496 (Secure Proxy ND Support for SEND). p.s. Even though NVO3/TRILL provides an overlay mechanism so that the hosts (or = VMs) addresses are hidden from the switches in the core, all the overlay ed= ge nodes are still exposed to all the hosts MAC addresses on the VLANs that= are enabled on the edges, which can cause switches' FDB size explosion iss= ue. For example: For a typical Access switch (Top of Rack) with 40 physical servers attache= d, where each server has 100 VMs, there are 4000 hosts under the Access Swi= tch. If indeed hosts/VMs can be moved anywhere, the worst case for the Acce= ss Switch is when all those 4000 VMs belong to different VLANs, i.e. the ac= cess switch has 4000 VLANs enabled. If each VLAN has 200 hosts, this access= switch's MAC table potentially has 200*4000 =3D 800,000 entries. Thank you very much for your feedback. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645B5269Ddfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

https://tools.ietf.org/html/draft-nachum-sarp-06 proposes a Pr= oxy Gateway mechanism to limit switches’ FDB (MAC table) sizes in an = environment where hosts (or VMs) within one subnet (or VLAN) can spread over many access domains (or shelves or sites)= and each access domain has hosts (VMs) belonging to many subnets (or VLANs= ).

 

The main idea of SARP is to represent all VMs (or ho= sts) under each access domain by their corresponding access (or aggregation= ) node's MAC address regardless whether the access (or aggregation) node is= the VMs (hosts)’ gateway or not. For example, when a host “a” under access domain “S̶= 1; needs to communicate with peers on the same VLAN but connected to differ= ent access domains, SARP requires “a” to use remote access node= ’s MAC address rather than peers’ MAC addresses. By doing so, s= witches in each domain do not need to maintain a list of MAC addresses for all the= VMs (hosts) in different access domains in their FDBs. Therefore, the swit= ches’ FDB size is limited regardless how VLAN is spread.

 

However, when SEND is used, Access (or Aggregation) = switches might not possess knowledge of the attached hosts (VMs)’ pri= vate keys.

 

Are there any concerns/feedback for giving the follo= wing recommendation in our draft? Any preferences?

1) state that SARP is not= recommended when SEND is deployed;

2) recommend using RFC649= 6 (Secure Proxy ND Support for SEND).

 

 

p.s.

Even though NVO3/TRILL provides an o= verlay mechanism so that the hosts (or VMs) addresses are hidden from the s= witches in the core, all the overlay edge nodes are still exposed to all the hosts MAC addresses on the VLANs that are enabled on th= e edges, which can cause switches’ FDB size explosion issue.

 

For example:

For a typical Access switch (Top of = Rack)  with 40 physical servers attached, where each server has 100 VM= s, there are 4000 hosts under the Access Switch. If indeed hosts/VMs can be moved anywhere, the worst case for the Access Switch is when all th= ose 4000 VMs belong to different VLANs, i.e. the access switch has 4000 VLA= Ns enabled. If each VLAN has 200 hosts, this access switch’s MAC tabl= e potentially has 200*4000 =3D 800,000 entries.

 

Thank you very much for your feedback.

 

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645B5269Ddfweml509mbxchi_-- From ietf@rozanak.com Wed Jul 31 04:13:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B6111E810D for ; Wed, 31 Jul 2013 04:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.285, 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 ZAC6GFB0+cxD for ; Wed, 31 Jul 2013 04:13:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D62E611E80E4 for ; Wed, 31 Jul 2013 04:12:59 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Mdb08-1UhJiG1pdc-00PMYm; Wed, 31 Jul 2013 07:12:57 -0400 From: "Hosnieh Rafiee" To: "Dave Thaler" , , "Andrew Yourtchenko" Subject: lifetime of the IID - RFC 4941 Date: Wed, 31 Jul 2013 13:12:41 +0200 Message-ID: <003701ce8dde$e6114270$b233c750$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01CE8DEF.A99F90B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6N2TnfPX3Rm6DPTvS5SlTfs0mHSg== Content-Language: en-us X-Provags-ID: V02:K0:4vD3zorn8+9GPi+n/E66khZvENR6fThAMJwNeY+n/2C Rp/2YUoyHitLtxxAg/UR8mUtB7Z+hePob1s6y5/+6qo/2k45T7 3TFoVee+aEFH17lGSZ9W4fFSZfk5ODE+NqpT2CtbpzSKMwm6L5 LE5wXC+O9vL335kIQdzPIgtk48qAK5QiOIp4f5QayfrdwzRMsH bv09LtaNebTpSw9k32pBgzglI/0d9CH95AkccrlnD9LGvgMdQK LBUq13cug6sULFeAMqXi3NaeA3IQSZHHWdqKeFwzY7JvzaPHrU 0fqVY7aTh/2CKHc5pD1+WRvtR4nbJGOp+CjBKyFumlEJiA+OQT kZYb0I8I/CvlE4/OHswc= Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:13:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0038_01CE8DEF.A99F90B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Let's first start the discussion about the lifetime of an IID. There are some sections in RFC 4941 that explains the lifetime of an IID The maximum lifetime is 1 week and preferred lifetime is 1 day. The address cannot exceed the maximum lifetime value. When it reaches to this maximum value, the state of this IID will change to deprecated. Section 3.3. http://tools.ietf.org/html/rfc4941#section-3.3 If a received option will extend the lifetime of a public address, the lifetimes of temporary addresses should be extended, subject to the overall constraint that no temporary addresses should ever remain "valid" or "preferred" for a time longer than (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR), respectively. This section explains the case where a node receives a new router advertisement with an option to extend the lifetime of its IID. So, if the maximum lifetime is not reached, it does it. (might not change IID when receives new RA) Section 3.4. http://tools.ietf.org/html/rfc4941#section-3.4 As an optional optimization, an implementation MAY remove a deprecated temporary address that is not in use by applications or upper layers as detailed in Section 6 . Section 6 http://tools.ietf.org/html/rfc4941#section-6 An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before). This is in contrast to current approaches where addresses are removed from an interface when they become invalid [ADDRCONF ], independent of whether or not upper layer protocols are still using them. For TCP connections, such information is available in control blocks. For UDP-based applications, it may be the case that only the applications have knowledge about what addresses are actually in use. Consequently, an implementation generally will need to use heuristics in deciding when an address is no longer in use. >From the above sections, I presume that the current approach in RFC 4941 uses the same approach that is defined in RFC 4862. So, it removes the IID independent of the upper layer protocols. This means that it makes problem for applications like FTP or other application even though it continue to keep its connections after the IID is deprecated if a there is any. Because it considers it as connection and not if the application using it. The advantage of ra-privacy http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy is to have: . an application layer lifetime. There are some variables that is used to control "the lifetime of the IID", "the number of application per IID" and "the number of valid IID". The total number of valid IID cannot exceed the max valid IID. So, The difference of this approach with RFC 4941 is that as long as an application uses an IID, this IID will not be removed, although, the maximum lifetime is reached. But it cannot be used for assigning any new application to it. Also always the assign of application to IID is based on the highest lifetime. The draft is also handled the exceptional situation where the maximum number of IID and the maximum number of application per IID are reached. In this case it increase the local value which keeps the maximum number of application for a specific IID. So it can later play with this value to handle this exceptional situation and again set the application to the IID with highest lifetime. It also set the lifetime of all IIDs to zero when it receives new router advertisement. . Introduces an highly randomized algorithm for use in place of the algorithm used in RFC 4941 that is preferable because there is no stable storage is needed Other updates: . In case the first approach is used, it changes the word "might" to "should" or MUST in order to force application use randomization RFC. If there are any more issues that I need to concern please leave your comment here. Thanks, Hosnieh ------=_NextPart_000_0038_01CE8DEF.A99F90B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let’s first start the discussion about the = lifetime of an IID. There are some sections in RFC 4941 that explains = the lifetime of an IID

 

The maximum = lifetime is 1 week and preferred lifetime is 1 day. The address cannot = exceed the maximum lifetime value. When it reaches to this maximum = value, the state of this IID will change to deprecated.

Section 3.3. = http://tools.ietf= .org/html/rfc4941#section-3.3 

If a =
received
      =
 option will extend the lifetime of a public address, =
the
       =
lifetimes of temporary addresses should be extended, subject =
to
       the =
overall constraint that no temporary addresses should =
ever
       =
remain "valid" or "preferred" for a time longer =
than
       =
(TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME =
-
   =
    DESYNC_FACTOR), =
respectively.
 

This section explains the case where a node receives a = new router advertisement with an option to extend the lifetime of its = IID. So, if the maximum lifetime is not reached, it does it. (might not = change IID when receives new RA)

 

 

Section = 3.4. http://tools.ietf= .org/html/rfc4941#section-3.4

 

As an optional =
optimization, an implementation MAY remove =
a
   deprecated temporary address =
that is not in use by applications =
or
   upper layers as detailed in =
Section =
6.

 

 

 

Section 6 http://tools.ietf.o= rg/html/rfc4941#section-6 = 

 
 =

   An implementation might want to =
keep track of which addresses =
are
   being used by upper layers =
so as to be able to remove a =
deprecated
   temporary address =
from internal data structures once no upper =
layer
   protocols are using it =
(but not before).  This is in contrast =
to
   current approaches where =
addresses are removed from an interface =
when
   they become invalid [ADDRCONF], independent of whether or not =
upper
   layer protocols are still =
using them.  For TCP connections, =
such
   information is available =
in control blocks.  For =
UDP-based
   applications, it may =
be the case that only the applications =
have
   knowledge about what =
addresses are actually in use.  Consequently, =
an
   implementation generally =
will need to use heuristics in deciding =
when
   an address is no longer in =
use.

 

From = the above sections, I presume that the current approach in RFC 4941 uses = the same approach that is defined in RFC 4862. So, it removes the IID = independent of the upper layer protocols.

 

This means = that it makes problem for applications like FTP or other application = even though it continue to keep its connections after the IID is = deprecated if a there is any. Because it considers it as connection and = not if the application using it.  

 

The = advantage of ra-privacy http://t= ools.ietf.org/html/draft-rafiee-6man-ra-privacy is to = have:

·         = an application = layer lifetime.

There are = some variables that is used to control “the lifetime of the = IID”, “the number of application per IID” and = “the number of valid IID”. The total number of valid IID = cannot exceed the max valid IID.  So, The difference of this = approach with RFC 4941  is that as long as an application uses an = IID, this IID will not be removed, although, the maximum lifetime is = reached. But it cannot be used for assigning any new application to it. = Also always the assign of application to IID is based on the highest = lifetime. The draft is also handled the exceptional situation where the = maximum number of IID and the maximum number of application per IID are = reached. In this case it increase the local value which keeps the = maximum number of application for a specific IID. So it can later play = with this value to handle this exceptional situation and again set the = application to the IID with highest lifetime. It also set the lifetime = of all IIDs to zero when it receives new router = advertisement.

·         = Introduces an = highly randomized algorithm for use in place of the algorithm used in = RFC 4941 that is preferable because there is no stable storage is = needed

Other = updates:

·         = In case the first = approach is used, it changes the word “might” to = “should” or MUST in order to force application use = randomization RFC.

 

If there are = any more issues that I need to concern please leave your comment = here.

 

Thanks,

Hosnieh

------=_NextPart_000_0038_01CE8DEF.A99F90B0-- From brian.e.carpenter@gmail.com Wed Jul 31 14:03:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C32221F95DC for ; Wed, 31 Jul 2013 14:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foTnjgjPZY1b for ; Wed, 31 Jul 2013 14:03:34 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 018B721F9AD2 for ; Wed, 31 Jul 2013 14:03:18 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id up15so1248254pbc.12 for ; Wed, 31 Jul 2013 14:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Jtm6mILvFNtvJS5Vs/NaMDEGz/XDUIcUO0y03TA5mB0=; b=ZuvS7BwyUcv9L39D9U2vg47nqAHHRHwo+iT89ron9sWsLODTmAy23UsoGNvKQtZLXd aSR1ZbEXvoEH/xPbsl8fClB8HSlQPNFlLG7zB4VbHXXVpAST0z1mgqKHabKy9qCbUgIN s8UhSRCdueIc4m6KFGx4ji1iZQsOxqV5b6unGBsNEH0YOKGiQTbXX0xT9LsQ68Zf1/KD wBZCNyrMbN+aAug1U+kQfB0GL04xY8hG3Q2ZFiz8IkbPDN61XJ94ce4BtmByGjtk1Gqu dauggK/eQ5yed8FR2g1hltwnjgKQ2Ab4xtZfvfZ6bC/a56Hgp+JmxYz7MuQS7HnW19fu 0fhA== X-Received: by 10.66.150.40 with SMTP id uf8mr235342pab.66.1375304598667; Wed, 31 Jul 2013 14:03:18 -0700 (PDT) Received: from [192.168.178.23] (220.199.69.111.dynamic.snap.net.nz. [111.69.199.220]) by mx.google.com with ESMTPSA id x8sm109140pbb.39.2013.07.31.14.03.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 14:03:17 -0700 (PDT) Message-ID: <51F97B9A.1010300@gmail.com> Date: Thu, 01 Aug 2013 09:03:22 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan Subject: Re: 6MAN WG Last Call: References: <51F670EF.2070809@kit.edu> <51F6D5B1.2010208@gmail.com> <8FBF2013-BD8B-4783-AE70-162799332CCC@employees.org> In-Reply-To: <8FBF2013-BD8B-4783-AE70-162799332CCC@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 21:03:34 -0000 Ole, On 31/07/2013 20:22, Ole Troan wrote: > Brian, > > (participant hat) > >>> I found the last statements in section 4 slightly confusing: >>> There is no algorithm >>> for determining whether this case has arisen, rather than a genuine >>> MAC address collision. Implementers should carefully consider the >>> consequences of continuing IPv6 operation on the interface in this >>> unlikely situation. >>> >>> 1.) DAD should actually detect that collision >> Yes, but it cannot detect the cause. > > why not? > can't the node just check the L2 source address against it's own? I suppose, if the MAC layer actually delivers the clashing packet to the ND layer. > > I suggest removing the sentence: > "There is no algorithm for determining whether this case has arisen, rather than a genuine > MAC address collision. " We'll be rewriting the text, for sure. Brian > > cheers, > Ole From jhw@apple.com Wed Jul 31 14:27:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD7621F9A29 for ; Wed, 31 Jul 2013 14:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPK3QkxeLecq for ; Wed, 31 Jul 2013 14:27:23 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BD21F9C82 for ; Wed, 31 Jul 2013 14:26:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) 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 <0MQT00CZIKW3JDT0@mail-out.apple.com> for ipv6@ietf.org; Wed, 31 Jul 2013 14:26:27 -0700 (PDT) X-AuditID: 11807157-b7f1a6d000003e11-eb-51f98103955c Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id EB.B8.15889.30189F15; Wed, 31 Jul 2013 14:26:27 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MQT00HKLKW3GU60@aniseed.apple.com> for ipv6@ietf.org; Wed, 31 Jul 2013 14:26:27 -0700 (PDT) Subject: Re: 6MAN WG Last Call: From: james woodyatt In-reply-to: <51F97B9A.1010300@gmail.com> Date: Wed, 31 Jul 2013 14:26:26 -0700 Message-id: References: <51F670EF.2070809@kit.edu> <51F6D5B1.2010208@gmail.com> <8FBF2013-BD8B-4783-AE70-162799332CCC@employees.org> <51F97B9A.1010300@gmail.com> To: 6man WG X-Mailer: Apple Mail (2.1786.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FAsrsvc+DPQ4Nw2RYuXZ98zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY92kFvaCo0wVXUcfMDYwNjJ1MXJySAiYSBy7dY0RwhaTuHBv PVsXIxeHkEA/k8TyW+/YIZzpTBJNl54yg1QxC2hJrN95HKybV8BA4tKM/UAdHBzCAtYS6x+a gITZBFQkvl2+C1bCKaApseTlIhYQm0VAVeJI53SoMdoST95dYAVp5RWwkfj6MR9i1RlGicZT O8HqRQSkJb78288McZy8xIpH19gmMPLPQnLFLCRXzEIydgEj8ypGgaLUnMRKE73EgoKcVL3k /NxNjOAAKwzfwfhvmdUhRgEORiUeXscL3wOFWBPLiitzDzFKcDArifBuTf8ZKMSbklhZlVqU H19UmpNafIhRmoNFSZx3xhegaoH0xJLU7NTUgtQimCwTB6dUA+N2iRdim5mF1/u+PuP4WWtu 4oZcece7xVWJ/xxE7r3d7vRRKKZtrvf1rt7DGye7mgq5sVRG7TL4eInXr+GpK2u7U2jUoQMi 3/M1c099z/6l+lzXT87ylcfRaSomf+S69HnM/0lqqhr+COZYYyK0q373jt+n+77zyGySM1D5 fGMpw+97Tue47JVYijMSDbWYi4oTAW0sTP0sAgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 21:27:34 -0000 On Jul 31, 2013, at 14:03 , Brian E Carpenter wrote: > > I suppose, if the MAC layer actually delivers the clashing packet to the ND layer. Alas, the presence of Neighbor Discovery proxy can disrupt that mechanism. -- james woodyatt core os networking From ayourtch@gmail.com Wed Jul 31 11:17:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C91A11E81AD for ; Wed, 31 Jul 2013 11:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9Qk-GSeSEOu for ; Wed, 31 Jul 2013 11:17:28 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B207D11E81A5 for ; Wed, 31 Jul 2013 11:17:27 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je2so358530bkc.4 for ; Wed, 31 Jul 2013 11:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Blu2Zrcom0AniMEzOS7kfK2zJGOkoXTXLnOwCExRpHg=; b=hXvQkKEu4mqHvbXVpbwieVvT18h2E7TCkgZezmKcNlOqz+LIqh/zfcT4CIvIXqgwFl P3huyw4Nqsliwq/moZU3R7esbwKJuNXzxFhFrbM2aQ4W6aP3V+yFdw+ZHPj6JLPVdwba FG1205mQlOi8VEIv0qjNgjFWfk4DRZIZUnZ5rRhBi9UFAFCV2nZpX5+ap0KXNHREQMEW xFjXw2l7byhaJO59tqIawRrjCo1vSgO3n4m/zJCHMOPEHadFM1Pljn8IsIMmKBQFSeql wqJGd9LUC+WDT3CgjXcXGkZPlf0g6zLpIRTSfgHfxB6y9ADh6mp0uxwdS4wdUzur8LH4 GexA== MIME-Version: 1.0 X-Received: by 10.204.233.14 with SMTP id jw14mr5055942bkb.159.1375294646747; Wed, 31 Jul 2013 11:17:26 -0700 (PDT) Received: by 10.204.226.7 with HTTP; Wed, 31 Jul 2013 11:17:26 -0700 (PDT) In-Reply-To: <003701ce8dde$e6114270$b233c750$@rozanak.com> References: <003701ce8dde$e6114270$b233c750$@rozanak.com> Date: Wed, 31 Jul 2013 20:17:26 +0200 Message-ID: Subject: Re: lifetime of the IID - RFC 4941 From: Andrew Yourtchenko To: Hosnieh Rafiee Content-Type: multipart/alternative; boundary=485b3979da84e1b42404e2d2bce7 X-Mailman-Approved-At: Wed, 31 Jul 2013 22:16:23 -0700 Cc: ipv6@ietf.org, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:17:29 -0000 --485b3979da84e1b42404e2d2bce7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hosnieh, "an application layer lifetime". 1) The problem that this is a solution for. I've looked through the draft multiple times, and what I see is a generic abstract and then a very specific dive-in into the details. What I think is very much missing is - what is the application you see in mind that would use this ? How would it look like to the user ? What is the trigger for the app to request an address ? 2) The cohabitation with other hosts and the network devices How does the app knows that it *can* request an address ? As I told: my employer's WiFi gear, based on the RFC you quoted and parameters therein, has a limit of 8 addresses per IPv6 host. With the default settings, if you use more than 8 addresses within 5 minutes, the latest addresses will be simply blocked. There is no mechanism today to communicate this kind of network parameters back to hosts, and at a minimum I think it should be added. I think having such a mechanism could be a very useful contribution to the protocol - and is in my opinion an integral part of such a proposal that allows to increase the frequency with which the host generates the addresses. 3) The state of the art in this. This is from my mac: ast login: Wed Jul 31 14:51:11 on ttys007 ayourtch-mac:~ ayourtch$ ifconfig en0 en0: flags=3D8863 mtu 1500 ether 28:cf:e9:1d:22:f7 inet6 fe80::2acf:e9ff:fe1d:22f7%en0 prefixlen 64 scopeid 0x4 inet 130.129.17.232 netmask 0xfffff800 broadcast 130.129.23.255 inet6 2001:df8::16:2acf:e9ff:fe1d:22f7 prefixlen 64 autoconf inet6 2001:df8::16:6110:66b2:eca2:cf4c prefixlen 64 autoconf temporary media: autoselect status: active **** disconnect wifi, reconnect wifi **** ayourtch-mac:~ ayourtch$ ifconfig en0 en0: flags=3D8863 mtu 1500 ether 28:cf:e9:1d:22:f7 inet6 fe80::2acf:e9ff:fe1d:22f7%en0 prefixlen 64 scopeid 0x4 inet 130.129.17.232 netmask 0xfffff800 broadcast 130.129.23.255 inet6 2001:df8::16:2acf:e9ff:fe1d:22f7 prefixlen 64 autoconf inet6 2001:df8::16:f9f9:fb2:2767:5caf prefixlen 64 autoconf temporary media: autoselect status: active ayourtch-mac:~ ayourtch$ So, given that I also have to clear cookies, etc. etc. today to get any semblance of the privacy: I can as well flip the wifi. So, it is not as bad :-) Also, you saw the presentation from Guillaume - it's dramatically changed in the past 2 years. So, again - I'd like to see more text about the problem being solved, and interaction with the user. thanks! :-) --a On Wed, Jul 31, 2013 at 1:12 PM, Hosnieh Rafiee wrote: > Let=92s first start the discussion about the lifetime of an IID. There ar= e > some sections in RFC 4941 that explains the lifetime of an IID**** > > ** ** > > The maximum lifetime is 1 week and preferred lifetime is 1 day. The > address cannot exceed the maximum lifetime value. When it reaches to this > maximum value, the state of this IID will change to deprecated.**** > > **** > > *Section 3.3. http://tools.ietf.org/html/rfc4941#section-3.3 * > > *If a received* > > * option will extend the lifetime of a public address, the* > > * lifetimes of temporary addresses should be extended, subject to* > > * the overall constraint that no temporary addresses should ever* > > * remain "valid" or "preferred" for a time longer than* > > * (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -* > > * DESYNC_FACTOR), respectively.* > > ** ** > > This section explains the case where a node receives a new router > advertisement with an option to extend the lifetime of its IID. So, if th= e > maximum lifetime is not reached, it does it. (might not change IID when > receives new RA) **** > > ** ** > > ** ** > > *Section 3.4. http://tools.ietf.org/html/rfc4941#section-3.4 * > > * * > > *As an optional optimization, an implementation MAY remove a* > > * deprecated temporary address that is not in use by applications or* > > * upper layers as detailed in Section 6 .* > > ** ** > > ** ** > > * * > > *Section 6 http://tools.ietf.org/html/rfc4941#section-6 * > > * * > > * * > > * An implementation might want to keep track of which addresses are* > > * being used by upper layers so as to be able to remove a deprecated* > > * temporary address from internal data structures once no upper layer* > > * protocols are using it (but not before). This is in contrast to* > > * current approaches where addresses are removed from an interface when= * > > * they become invalid [ADDRCONF ], independent of whether or not upper* > > * layer protocols are still using them. For TCP connections, such* > > * information is available in control blocks. For UDP-based* > > * applications, it may be the case that only the applications have* > > * knowledge about what addresses are actually in use. Consequently, an= * > > * implementation generally will need to use heuristics in deciding when= * > > * an address is no longer in use.* > > * * > > From the above sections, I presume that the current approach in RFC 4941 > uses the same approach that is defined in RFC 4862. So, it removes the II= D > independent of the upper layer protocols.**** > > ** ** > > This means that it makes problem for applications like FTP or other > application even though it continue to keep its connections after the IID > is deprecated if a there is any. Because it considers it as connection an= d > not if the application using it. **** > > ** ** > > The advantage of ra-privacy > http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy is to have:**** > > **=B7 ***an application layer lifetime.* **** > > There are some variables that is used to control =93the lifetime of the > IID=94, =93the number of application per IID=94 and =93the number of vali= d IID=94. > The total number of valid IID cannot exceed the max valid IID. So, The > difference of this approach with RFC 4941 is that as long as an > application uses an IID, this IID will not be removed, although, the > maximum lifetime is reached. But it cannot be used for assigning any new > application to it. Also always the assign of application to IID is based = on > the highest lifetime. The draft is also handled the exceptional situation > where the maximum number of IID and the maximum number of application per > IID are reached. In this case it increase the local value which keeps the > maximum number of application for a specific IID. So it can later play wi= th > this value to handle this exceptional situation and again set the > application to the IID with highest lifetime. It also set the lifetime of > all IIDs to zero when it receives new router advertisement.**** > > **=B7 **Introduces an highly randomized algorithm for use in plac= e > of the algorithm used in RFC 4941 that is preferable because there is no > stable storage is needed**** > > Other updates:**** > > **=B7 **In case the first approach is used, it changes the word > =93might=94 to =93should=94 or MUST in order to force application use ran= domization > RFC.**** > > ** ** > > If there are any more issues that I need to concern please leave your > comment here.**** > > ** ** > > Thanks,**** > > Hosnieh**** > --485b3979da84e1b42404e2d2bce7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hosnieh,

"an application layer lif= etime".=A0

1) The problem that this is a solu= tion for.

I've looked through the draft multip= le times, and what I see is a generic abstract and then a very specific div= e-in into the details.

What I think is very much missing is - what is the appl= ication you see in mind that would use this ?

How = would it look like to the user ?

What is the trigg= er for the app to request an address ?

2) The cohabitation with other hosts and the network de= vices

How does the app knows that it *can* request= an address ?

As I told: my employer's WiFi ge= ar, based on the RFC you quoted and parameters therein, has a limit of 8 ad= dresses per IPv6 host. With the default settings, if you use more than 8 ad= dresses within 5 minutes, the latest addresses will be simply blocked. Ther= e is no mechanism today to communicate this kind of network parameters back= to hosts, and at a minimum I think it should be added.

I think having such a mechanism could be a very useful = contribution to the protocol - and is in my opinion an integral part of suc= h a proposal that allows to increase the frequency with which the host gene= rates the addresses.

3) The state of the art in this.

This is from my mac:

ast login: Wed Jul 31= 14:51:11 on ttys007
ayourtch-mac:~ ayourtch$ ifconfig en0
en0: flags=3D8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> = mtu 1500
ether= 28:cf:e9:1d:22:f7=A0
= inet6 fe80::2acf:e9ff:fe1d:22f7%en0 prefixlen 64 scopeid 0x4=A0
inet 130.129.17.232= netmask 0xfffff800 broadcast 130.129.23.255
inet6 2001:df8::16:2acf:e9ff:fe1d:22f7 prefi= xlen 64 autoconf=A0
inet6 2001:df8::16:= 6110:66b2:eca2:cf4c prefixlen 64 autoconf temporary=A0
media: autoselect
status: active

**** disconnect wifi, reconnect wifi ****
ayourtch-mac:~ ayourtch$ ifconfig en0
en0: flags=3D88= 63<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 28:cf:e9:1d:22:f7= =A0
inet6 fe80= ::2acf:e9ff:fe1d:22f7%en0 prefixlen 64 scopeid 0x4=A0
inet 130.129.17.232 netmask 0xfffff= 800 broadcast 130.129.23.255
inet6 2001:df8::16:= 2acf:e9ff:fe1d:22f7 prefixlen 64 autoconf=A0
inet6 2001:df8::16:f9f9:fb2:2767:5caf prefix= len 64 autoconf temporary=A0
media: autoselect
status: active<= /div>
ayourtch-mac:~ ayourtch$=A0

So, gi= ven that I also have to clear cookies, etc. etc. today to get any semblance= of the privacy:

I can as well flip the wifi.

S= o, it is not as bad :-)

Also, you saw the presenta= tion from Guillaume - it's dramatically changed in the past 2 years.

So, again - I'd like to see more text about the pro= blem being solved, and interaction with the user.

= thanks! :-)

--a



On Wed, Jul 31, 2013 at 1:12 PM, Hosnieh= Rafiee <ietf@rozanak.com> wrote:

Let=92s first start the discussion about the lifetime of an IID. There = are some sections in RFC 4941 that explains the lifetime of an IID

=A0

The maxi= mum lifetime is 1 week and preferred lifetime is 1 day. The address cannot = exceed the maximum lifetime value. When it reaches to this maximum value, t= he state of this IID will change to deprecated.

Section= 3.3. http://tools.ietf.org/html/rfc4941#section-3.3 

If a received
=A0=A0=A0=A0=A0=A0 opt=
ion will extend the lifetime of a public address, the
=A0=A0=A0=A0=A0=A0 lifetimes of temporary addresses should be ext=
ended, subject to


=A0=A0=A0=A0=A0=A0 the overall constraint that no temporary address=
es should ever
=A0=A0=A0=A0=A0=A0 remain &qu=
ot;valid" or "preferred" for a time longer than
=A0=A0=A0=A0=A0=A0 (TEMP_VALID_LIFETIME) or (TEMP_PREFER=
RED_LIFETIME -


=A0=A0 =A0=A0=A0=A0DESYNC_FACTOR), respectively.<=
/pre>
=A0
This section explai=
ns the case where a node receives a new router advertisement with an option=
 to extend the lifetime of its IID. So, if the maximum lifetime is not reac=
hed, it does it. (might not change IID when receives new RA) =



=A0
=
=A0
Section 3.4. http://tools.ietf.or=
g/html/rfc4941#section-3.4 


=A0
As an optional o=
ptimization, an implementation MAY remove a
=
=A0=A0 deprecated temporary address that is not in use by applications or


=A0=A0 upper layers as detailed in Section 6.=

=A0
=A0


=A0
<=
i>Section 6 http://tools.ietf.org/html/rfc4941#section-6 =



=A0
=A0
=
=A0=A0 An implementation might want to keep track of which addresses are=

=A0=A0 being used by upper layers so as to =
be able to remove a deprecated


=A0=A0 temporary address from internal data structures once no uppe=
r layer
=A0=A0 protocols are using it (but n=
ot before).=A0 This is in contrast to
=A0=A0=
 current approaches where addresses are removed from an interface when


=A0=A0 they become invalid [ADDRCONF], independent of whether or not upp=
er


=A0=A0 layer protocols are still using them.=A0 For TCP connections=
, such
=A0=A0 information is available in co=
ntrol blocks.=A0 For UDP-based
=A0=A0 applic=
ations, it may be the case that only the applications have


=A0=A0 knowledge about what addresses are actually in use.=A0 Conse=
quently, an
=A0=A0 implementation generally =
will need to use heuristics in deciding when
=A0=A0 an address is no longer in use.


=A0
F=
rom the above sections, I presume that the current approach in RFC 4941 use=
s the same approach that is defined in RFC 4862. So, it removes the IID ind=
ependent of the upper layer protocols.


=A0
This mea=
ns that it makes problem for applications like FTP or other application eve=
n though it continue to keep its connections after the IID is deprecated if=
 a there is any. Because it considers it as connection and not if the appli=
cation using it. =A0


=A0
The adva=
ntage of ra-privacy http://tools.ietf.org/html/draft-rafiee-6man=
-ra-privacy is to have:


=B7=A0=A0=A0=A0=A0=A0=A0=A0 an application layer lifetime. =


There are some variables that is used to control =93the lifetime of the IID=
=94, =93the number of application per IID=94 and =93the number of valid IID=
=94. The total number of valid IID cannot exceed the max valid IID. =A0So, =
The difference of this approach with RFC 4941 =A0is that as long as an appl=
ication uses an IID, this IID will not be removed, although, the maximum li=
fetime is reached. But it cannot be used for assigning any new application =
to it. Also always the assign of application to IID is based on the highest=
 lifetime. The draft is also handled the exceptional situation where the ma=
ximum number of IID and the maximum number of application per IID are reach=
ed. In this case it increase the local value which keeps the maximum number=
 of application for a specific IID. So it can later play with this value to=
 handle this exceptional situation and again set the application to the IID=
 with highest lifetime. It also set the lifetime of all IIDs to zero when i=
t receives new router advertisement.


=B7=A0=A0=A0=A0=A0=A0=A0=A0 Introduces an highly randomized algori=
thm for use in place of the algorithm used in RFC 4941 that is preferable b=
ecause there is no stable storage is needed


Other updates:
=B7=A0=A0=A0=A0=A0=A0=A0=A0 In case the first approach is used, it changes the word =
=93might=94 to =93should=94 or MUST in order to force application use rando=
mization RFC.


=A0
If there=
 are any more issues that I need to concern please leave your comment here.=

=A0

Thanks,
Hosnieh

--485b3979da84e1b42404e2d2bce7--