From nobody Tue Mar 1 06:00:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D71A1A8713 for ; Tue, 1 Mar 2016 06:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.907 X-Spam-Level: X-Spam-Status: No, score=-113.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlwI0bw1Lnpu for ; Tue, 1 Mar 2016 06:00:19 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6531A870E for ; Tue, 1 Mar 2016 06:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=996; q=dns/txt; s=iport; t=1456840819; x=1458050419; h=date:from:message-id:to:subject; bh=HzqJVg2Ojy0pB4jpaZiewAb/ZMQlrEwXwSBArOh8Ra0=; b=mjmn90okW3kPDy3M3irdzuIVogWSO8scBaahOHSCHxWZ7NB17RvO2Vp8 K6MoCgennTXXQIWxKYI2uhg5lz71ktvBG2kIqoLagwOJTqOZBMNu4UMvy zwRO+RQPnV0g+TQ5+AnJalxrunX5G+KblI2Zhur/HjfriSU0XSI1hDyw0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AgC5n9VW/4UNJK1egzqrcQGPfgENg?= =?us-ascii?q?WaHWTgUAQEBAQEBAWQnhX00iH8BoGiedAEBCAEBAQEBG49Ng24Fjh+Ib4Ebmz2?= =?us-ascii?q?OTB4BAUKEBYkVAQEB?= X-IronPort-AV: E=Sophos;i="5.22,523,1449532800"; d="scan'208";a="76171271" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Mar 2016 14:00:18 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u21E0IMG029073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Mar 2016 14:00:18 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u21E0Io0025857 for ; Tue, 1 Mar 2016 06:00:18 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u21E0IPV025856 for v6ops@ietf.org; Tue, 1 Mar 2016 06:00:18 -0800 Date: Tue, 1 Mar 2016 06:00:18 -0800 From: fred@cisco.com Message-Id: <201603011400.u21E0IPV025856@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:00:20 -0000 RFC Editor: EDIT,Sent to the RFC Editor 2016-02-29 draft-ietf-v6ops-mobile-device-profile IESG: IESG Evaluation 2016-02-29 draft-ietf-v6ops-ipv6-ehs-in-real-world IESG: In Last Call 2016-02-29 draft-bao-v6ops-rfc6145bis 2016-02-29 draft-ietf-v6ops-host-addr-availability WG: In WG Last Call 2016-02-16 draft-ietf-v6ops-dhcpv6-slaac-problem WG: Unupdated WG Document 2015-10-19 draft-ietf-v6ops-design-choices WG: Updated WG Document 2016-02-08 draft-ietf-v6ops-ula-usage-considerations 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host Individual Submission: Unupdated 2015-10-19 draft-xu-v6ops-dslite-redundancy 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack Individual Submission: Updated 2016-02-27 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node 2016-02-04 draft-gont-v6ops-ipv6-ehs-packet-drops 2016-01-05 draft-templin-v6ops-pdhost 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment 2016-01-03 draft-xli-v6ops-cernet-deployment From nobody Tue Mar 1 14:19:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943F41B427C for ; Tue, 1 Mar 2016 14:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16rsOIBP_fGM for ; Tue, 1 Mar 2016 14:19:10 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88D71B4279 for ; Tue, 1 Mar 2016 14:19:09 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id 124so58866299pfg.0 for ; Tue, 01 Mar 2016 14:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jWooHFCc6s59miD8LeysL8O/lSVx+uPpGgSANfCQbVg=; b=KhX4t7rvKfikKuZ4Is7CCy1TORB6ZwmzDEyi/5xSjjnJdtgaVecHNN2bKjNzbi1rh3 UrLWjMjE1gE5CqFDdmPWjEuLrZYweadhnAXjUtxtQ+VVm9YJKu7gmoq+Vud7XPMRzf18 REMN9Y8wrYcDI9KeJg/3tbQDJhsteDV2JvfTBhfy+XnaNywm76isnL2EqDjAgBmj2yt2 KdJYnW/LgPlrJSVvsf5EmrdE2Y2ToU4htintIC53PRjSpdhk2nVBPPUuBd0bl4CREwBs h5DO0kGJO2MbPi47nnIT3kp9+vN/ZxQlcaqNfxPj6Dkoy5CvZn0a1h+56uJXpf4CzmAq BP0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=jWooHFCc6s59miD8LeysL8O/lSVx+uPpGgSANfCQbVg=; b=Gac++BGD++drVIK4x8GoryzF4thHh7Ymcvt5HgGvalSPEsgnMTMg3CtZrlBPmshc+i G8nJeg6vn6UQvNw4WG1hOqqUhHkQWL6D/P19kEAFwPOUEtBZXbOlVTYbu7Ny1+GOOLgd XmQAcbMzKaDoBxnkxYepqpOvoQU09BelYHH9lz5MTZryGz75R3T20slVmP/V+OzfO1Oq MJCQ9+fnsy83n19hiJQO34C7uwwByUtpu1LDd1B1dBs7JdHhNNp9ce0xC0XCKdFLUpWW 6E0sgc4jdVqav8bD+GgZvbSV2N7GVkiFel/6C876HpepLl8WVfBqFErUZfqNH3lrIoE8 M0Mg== X-Gm-Message-State: AD7BkJLh4FBr3jhaVV0oivmuvnO3+mbmEnuvJIk1ZkPDcItzDKoxPbMWxB6l/PfJ/QmBtw== X-Received: by 10.98.34.212 with SMTP id p81mr33274569pfj.23.1456870749520; Tue, 01 Mar 2016 14:19:09 -0800 (PST) Received: from ?IPv6:2406:e007:7832:1:28cc:dc4c:9703:6781? ([2406:e007:7832:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w69sm32763000pfi.55.2016.03.01.14.19.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 14:19:07 -0800 (PST) To: Lorenzo Colitti , Fernando Gont References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com> <56CEB3F2.8060101@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56D6155C.3040105@gmail.com> Date: Wed, 2 Mar 2016 11:19:08 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:19:11 -0000 Firstly, I still think this document is valuable (some comments on why I = think that are below). Secondly, I think that Fernando, Lorenzo and Jinmei-san have raised valid= technical comments that need to be fixed. So we aren't done yet. More in line below: On 25/02/2016 21:04, Lorenzo Colitti wrote: > On Thu, Feb 25, 2016 at 4:57 PM, Fernando Gont > wrote: >=20 >>> So starting DHCPv6 without an RA is pointless because even if you get= an >>> address, you can't use to talk to anything. >> >> Yes, we should close that gap. Sad that a religious war essentially en= ds >> up with *two* mandatory protocols. Because in many scenarios, you need= >> both. >> >=20 > Well, that's not something we can do in this WG. No. But IMHO it is important to document the result for hundreds of thous= ands of site operators, especially the potential for divergent behaviour. >>> 3. Where the draft says "It could be reasonably deduced that M flag >>> should be independent from A flag" - again, the text should mention t= hat >>> for a client following draft-ietf-dhc-anonymity-profile, that's not t= rue. >> >> Which again brings the question of why such document is not updating t= he >> corresponding spec. >> >=20 > I think you'll have to take that up with the IESG at this point. Obviou= sly > they took the position that doing so was not necessary; I suspect that > position is far from conteroversial. Exactly, or we wouldn't need this draft in the first place. As with other= IETF goofs, it's more constructive to document the problem than to ignore= it. Actually attempting to fix the specifications would be a follow-on task. >>> 7. The draft makes no mention of Android. Perhaps it should say that >>> Android does not have this problem because it does not implement DHCP= v6? >> >> That's kind of misleading ;-). That could be read to mean that it's >> actually a good thing that android does not support ipv6. I think Fernando meant DHCPv6 there... >> (FWIW, Nodes that don't do v6 don't have this problem, either.) >> >=20 > We can say whatever we can get WG consensus on, but I think we have to = say > something about Android, because there are more Android devices than mo= st > of the platforms that you do say something about. Send text? On 27/02/2016 11:18, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: =2E.. > If we keep this appendix, > I'd strongly suggest including at least one open-source BSD variant. That would be good, but I think it's important to write at the beginning that the tests and observations only involved a small number of stacks and that probably not all divergent behaviours have been discovered. Regards Brian From nobody Wed Mar 2 01:13:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926B91A9235 for ; Wed, 2 Mar 2016 01:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgtomZ8759-4 for ; Wed, 2 Mar 2016 01:13:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A02B1A9233 for ; Wed, 2 Mar 2016 01:13:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJK59870; Wed, 02 Mar 2016 09:13:24 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Mar 2016 09:13:22 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 2 Mar 2016 17:13:16 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Lorenzo Colitti , Fernando Gont Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHRbNo4gqEUER8qq0SFTIVdqXX6nZ86QbCAgAGi4gCAAAIJgIAIylMAgAE5ktA= Date: Wed, 2 Mar 2016 09:13:16 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D49288@nkgeml514-mbx.china.huawei.com> References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com> <56CEB3F2.8060101@si6networks.com> <56D6155C.3040105@gmail.com> In-Reply-To: <56D6155C.3040105@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.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.56D6AEB4.00DC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 010ab88b9f2eaeb22c6ca42e2492e683 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 09:13:32 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMg W21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRQ0KPiBD YXJwZW50ZXINCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwMiwgMjAxNiA2OjE5IEFNDQo+IFRv OiBMb3JlbnpvIENvbGl0dGk7IEZlcm5hbmRvIEdvbnQNCj4gQ2M6IHY2b3BzQGlldGYub3JnIFdH DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXBy b2JsZW0gV0dMQw0KPiANCj4gRmlyc3RseSwgSSBzdGlsbCB0aGluayB0aGlzIGRvY3VtZW50IGlz IHZhbHVhYmxlIChzb21lIGNvbW1lbnRzIG9uIHdoeSBJIHRoaW5rDQo+IHRoYXQgYXJlIGJlbG93 KS4NCj4gDQo+IFNlY29uZGx5LCBJIHRoaW5rIHRoYXQgRmVybmFuZG8sIExvcmVuem8gYW5kIEpp bm1laS1zYW4gaGF2ZSByYWlzZWQgdmFsaWQNCj4gdGVjaG5pY2FsIGNvbW1lbnRzIHRoYXQgbmVl ZCB0byBiZSBmaXhlZC4gU28gd2UgYXJlbid0IGRvbmUgeWV0Lg0KDQpbQmluZ10gWWVzLCBJIGRp ZCBzZWUgc29tZSBnb29kIGRpc2N1c3Npb24gYXJvdW5kIExvcmVuem8ncyB0ZWNobmljYWwgY29t bWVudHMuIEknbGwgdHJ5IHRvIGNhcHR1cmUgaXQgaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KDQo+ IE1vcmUgaW4gbGluZSBiZWxvdzoNCj4gDQo+IE9uIDI1LzAyLzIwMTYgMjE6MDQsIExvcmVuem8g Q29saXR0aSB3cm90ZToNCj4gPiBPbiBUaHUsIEZlYiAyNSwgMjAxNiBhdCA0OjU3IFBNLCBGZXJu YW5kbyBHb250DQo+IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+DQo+ID4gd3JvdGU6DQo+ID4NCj4g Pj4+IFNvIHN0YXJ0aW5nIERIQ1B2NiB3aXRob3V0IGFuIFJBIGlzIHBvaW50bGVzcyBiZWNhdXNl IGV2ZW4gaWYgeW91DQo+ID4+PiBnZXQgYW4gYWRkcmVzcywgeW91IGNhbid0IHVzZSB0byB0YWxr IHRvIGFueXRoaW5nLg0KPiA+Pg0KPiA+PiBZZXMsIHdlIHNob3VsZCBjbG9zZSB0aGF0IGdhcC4g U2FkIHRoYXQgYSByZWxpZ2lvdXMgd2FyIGVzc2VudGlhbGx5DQo+ID4+IGVuZHMgdXAgd2l0aCAq dHdvKiBtYW5kYXRvcnkgcHJvdG9jb2xzLiBCZWNhdXNlIGluIG1hbnkgc2NlbmFyaW9zLA0KPiA+ PiB5b3UgbmVlZCBib3RoLg0KPiA+Pg0KPiA+DQo+ID4gV2VsbCwgdGhhdCdzIG5vdCBzb21ldGhp bmcgd2UgY2FuIGRvIGluIHRoaXMgV0cuDQo+IA0KPiBOby4gQnV0IElNSE8gaXQgaXMgaW1wb3J0 YW50IHRvIGRvY3VtZW50IHRoZSByZXN1bHQgZm9yIGh1bmRyZWRzIG9mDQo+IHRob3VzYW5kcyBv ZiBzaXRlIG9wZXJhdG9ycywgZXNwZWNpYWxseSB0aGUgcG90ZW50aWFsIGZvciBkaXZlcmdlbnQg YmVoYXZpb3VyLg0KPiANCj4gPj4+IDMuIFdoZXJlIHRoZSBkcmFmdCBzYXlzICJJdCBjb3VsZCBi ZSByZWFzb25hYmx5IGRlZHVjZWQgdGhhdCBNIGZsYWcNCj4gPj4+IHNob3VsZCBiZSBpbmRlcGVu ZGVudCBmcm9tIEEgZmxhZyIgLSBhZ2FpbiwgdGhlIHRleHQgc2hvdWxkIG1lbnRpb24NCj4gPj4+ IHRoYXQgZm9yIGEgY2xpZW50IGZvbGxvd2luZyBkcmFmdC1pZXRmLWRoYy1hbm9ueW1pdHktcHJv ZmlsZSwgdGhhdCdzIG5vdA0KPiB0cnVlLg0KPiA+Pg0KPiA+PiBXaGljaCBhZ2FpbiBicmluZ3Mg dGhlIHF1ZXN0aW9uIG9mIHdoeSBzdWNoIGRvY3VtZW50IGlzIG5vdCB1cGRhdGluZw0KPiA+PiB0 aGUgY29ycmVzcG9uZGluZyBzcGVjLg0KPiA+Pg0KPiA+DQo+ID4gSSB0aGluayB5b3UnbGwgaGF2 ZSB0byB0YWtlIHRoYXQgdXAgd2l0aCB0aGUgSUVTRyBhdCB0aGlzIHBvaW50Lg0KPiA+IE9idmlv dXNseSB0aGV5IHRvb2sgdGhlIHBvc2l0aW9uIHRoYXQgZG9pbmcgc28gd2FzIG5vdCBuZWNlc3Nh cnk7IEkNCj4gPiBzdXNwZWN0IHRoYXQgcG9zaXRpb24gaXMgZmFyIGZyb20gY29udGVyb3ZlcnNp YWwuDQo+IA0KPiBFeGFjdGx5LCBvciB3ZSB3b3VsZG4ndCBuZWVkIHRoaXMgZHJhZnQgaW4gdGhl IGZpcnN0IHBsYWNlLiBBcyB3aXRoIG90aGVyIElFVEYNCj4gZ29vZnMsIGl0J3MgbW9yZSBjb25z dHJ1Y3RpdmUgdG8gZG9jdW1lbnQgdGhlIHByb2JsZW0gdGhhbiB0byBpZ25vcmUgaXQuDQo+IEFj dHVhbGx5IGF0dGVtcHRpbmcgdG8gZml4IHRoZSBzcGVjaWZpY2F0aW9ucyB3b3VsZCBiZSBhIGZv bGxvdy1vbiB0YXNrLg0KPiANCj4gPj4+IDcuIFRoZSBkcmFmdCBtYWtlcyBubyBtZW50aW9uIG9m IEFuZHJvaWQuIFBlcmhhcHMgaXQgc2hvdWxkIHNheSB0aGF0DQo+ID4+PiBBbmRyb2lkIGRvZXMg bm90IGhhdmUgdGhpcyBwcm9ibGVtIGJlY2F1c2UgaXQgZG9lcyBub3QgaW1wbGVtZW50DQo+IERI Q1B2Nj8NCj4gPj4NCj4gPj4gVGhhdCdzIGtpbmQgb2YgbWlzbGVhZGluZyA7LSkuICBUaGF0IGNv dWxkIGJlIHJlYWQgdG8gbWVhbiB0aGF0IGl0J3MNCj4gPj4gYWN0dWFsbHkgYSBnb29kIHRoaW5n IHRoYXQgYW5kcm9pZCBkb2VzIG5vdCBzdXBwb3J0IGlwdjYuDQo+IA0KPiBJIHRoaW5rIEZlcm5h bmRvIG1lYW50IERIQ1B2NiB0aGVyZS4uLg0KPiANCj4gPj4gKEZXSVcsIE5vZGVzIHRoYXQgZG9u J3QgZG8gdjYgZG9uJ3QgaGF2ZSB0aGlzIHByb2JsZW0sIGVpdGhlci4pDQo+ID4+DQo+ID4NCj4g PiBXZSBjYW4gc2F5IHdoYXRldmVyIHdlIGNhbiBnZXQgV0cgY29uc2Vuc3VzIG9uLCBidXQgSSB0 aGluayB3ZSBoYXZlIHRvDQo+ID4gc2F5IHNvbWV0aGluZyBhYm91dCBBbmRyb2lkLCBiZWNhdXNl IHRoZXJlIGFyZSBtb3JlIEFuZHJvaWQgZGV2aWNlcw0KPiA+IHRoYW4gbW9zdCBvZiB0aGUgcGxh dGZvcm1zIHRoYXQgeW91IGRvIHNheSBzb21ldGhpbmcgYWJvdXQuDQo+IA0KPiBTZW5kIHRleHQ/ DQo+IA0KPiBPbiAyNy8wMi8yMDE2IDExOjE4LCDnpZ7mmI7pgZTlk4kgd3JvdGU6DQo+IC4uLg0K PiA+IElmIHdlIGtlZXAgdGhpcyBhcHBlbmRpeCwNCj4gPiBJJ2Qgc3Ryb25nbHkgc3VnZ2VzdCBp bmNsdWRpbmcgYXQgbGVhc3Qgb25lIG9wZW4tc291cmNlIEJTRCB2YXJpYW50Lg0KPiANCj4gVGhh dCB3b3VsZCBiZSBnb29kLCBidXQgSSB0aGluayBpdCdzIGltcG9ydGFudCB0byB3cml0ZSBhdCB0 aGUgYmVnaW5uaW5nIHRoYXQNCj4gdGhlIHRlc3RzIGFuZCBvYnNlcnZhdGlvbnMgb25seSBpbnZv bHZlZCBhIHNtYWxsIG51bWJlciBvZiBzdGFja3MgYW5kIHRoYXQNCj4gcHJvYmFibHkgbm90IGFs bCBkaXZlcmdlbnQgYmVoYXZpb3VycyBoYXZlIGJlZW4gZGlzY292ZXJlZC4NCg0KW0JpbmddIEV4 YWN0bHkuIEkgdGhpbmsgdGhlIHRlc3QgY2FzZXMgbW9zdGx5IHNlcnZlIGFzICJoaW50cyIgb2Yg cG9zc2libGUgZGl2ZXJnZW5jZSwgcmF0aGVyIHRoYW4gYSBmdWxsIGVudW1lcmF0aW9uLg0KDQpU aGFua3MgZm9yIHRoZSBjb21tZW50cy4NCg0KQmVzdCByZWdhcmRzLA0KQmluZyANCg0KPiBSZWdh cmRzDQo+ICAgICBCcmlhbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Wed Mar 2 06:57:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B847F1B2DE0; Wed, 2 Mar 2016 06:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cicczyisw2wp; Wed, 2 Mar 2016 06:57:25 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7531B2DEC; Wed, 2 Mar 2016 06:57:25 -0800 (PST) Received: from mailboxes.uclouvain.be (mailboxes.uclouvain.be [130.104.6.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPS id 768D21833ED; Wed, 2 Mar 2016 15:57:10 +0100 (CET) Received: from [130.104.228.78] (130.104.228.78) by ucl-mbx04.OASIS.UCLOUVAIN.BE (10.10.10.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Mar 2016 15:57:09 +0100 Message-ID: <56D6FF46.60703@uclouvain.be> Date: Wed, 2 Mar 2016 15:57:10 +0100 From: David Lebrun User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: , , Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mb3DHfxIwmkUoq4EaMqKBrlwxkEaskmBN" X-Originating-IP: [130.104.228.78] X-ClientProxiedBy: UCL-CAS02.OASIS.UCLOUVAIN.BE (10.10.10.42) To ucl-mbx04.OASIS.UCLOUVAIN.BE (10.10.10.24) X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (client IP white listed); receiver=; client-ip=130.104.6.131; helo= Received-SPF: Pass (client IP white listed); receiver=; client-ip=130.104.6.131; envelope-from= X-SGSI-MailScanner-ID: 768D21833ED.A3293 X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-2, requis 5, autolearn=not spam, ALL_TRUSTED -2.00) X-SGSI-From: david.lebrun@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: "srv6-eft@external.cisco.com" Subject: [v6ops] SR-IPv6 Linux implementation status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 14:57:27 -0000 --mb3DHfxIwmkUoq4EaMqKBrlwxkEaskmBN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, The Linux implementation of SR-IPv6 has reached a milestone with a large codebase cleanup, support of LWT (lightweight tunnels), numerous bugfixes and centralized userland control tool (iproute2). For the occasion, I have completely reinstalled the implementation website, at http://segment-routing.org It now has clear documentation on how to install and use our modified kernel and tools, and we provide a Virtual Machine in QEMU and VirtualBox formats in order to easily test the implementation. The VM also contains a framework to instantiate virtual networks within the VM, in order to test various network setups with SR. Feel free to look a the website and test the VM, and any feedback would be appreciated. Thanks ! David --mb3DHfxIwmkUoq4EaMqKBrlwxkEaskmBN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlbW/0YACgkQjbzn67sZ6AMkwwCeOcqYhPvM3L2hZz2BEdtw/sp9 VioAn0ob3lmG+/5bAvpCNkZ1Tlvakyu/ =lzEZ -----END PGP SIGNATURE----- --mb3DHfxIwmkUoq4EaMqKBrlwxkEaskmBN-- From nobody Wed Mar 2 11:05:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378161B2D90 for ; Wed, 2 Mar 2016 11:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUA8dv9Wu6bA for ; Wed, 2 Mar 2016 11:05:41 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DD01B2D86 for ; Wed, 2 Mar 2016 11:05:40 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id m184so2262671iof.1 for ; Wed, 02 Mar 2016 11:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=1PKreVkxps8AOoLbfFF0/JV/ZEhT3JvFksALDerZ0Uw=; b=GDoFB1FDF7DdrBXhqQ7EnLQj5dfWsSE1fwSTwETWGmf+KOnOTlOtTXyHS9Y3vj4IO8 eKlq5eLyM+IxFQSn2tovWInAG+LiCBVegpOwd8BXa30YcL7fKM2aphn4ow7vyNzyPhVy SRd/oCsI1ilgDRmZQS5H4++lZ2RY8SrKqbcgV6uflVR6pogIxtuPohOy6jyPZv8kbqX5 /Gvv6DKBaxlczrIJ+rxvwBET/A36tcyCCUx+iM2suAG7purw5UYhgDG0oqipIGI1lAd3 5wEuqdu7eNiREOkkSYZXFSdRDwa+dMOEcD3pzhOF1QnDGe5l4o5eYINAQi9l/L4R7NjU /PRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=1PKreVkxps8AOoLbfFF0/JV/ZEhT3JvFksALDerZ0Uw=; b=U0AYPNXYtTgt/BjM3Ty4H9LFcoU9OPX8J19QD0A/HvRGhmuGlQuEWrJzckgQ+U7Jk6 VS1BfOuiKnwuDM85OGdGpb/82nJyg2r8Om2Ba93a4dLsMbbTP/d2+3p8LW7HfWAiQNro gAiyHR+3eSXnF9L1+znlxjfmuw3wRZnFWyj3B/f79HOrvO5oZi+YYJ+gwoG5RFGOt1O6 wDmM9VsvoA/mS6oXytQQ+LbQF+k6CZLtgVED5ZTW1J+fSqKbCwDX5aJ7iCShyIsMdBqG zBCnTIvBF+kYnqcknnmQdA9hUc/RvNBtHlJqjPTbtpFUHZekeRgYnOBqxT1R/pDaZnJT 9RZg== X-Gm-Message-State: AG10YOTck6teCJgT32z7tyWply1osHLtmTJ6SxXEIY98axIbY/EtgX1z3uMTJFS9frnoMbDRsm1tSNZZWaR3sA== MIME-Version: 1.0 X-Received: by 10.107.198.197 with SMTP id w188mr29998751iof.178.1456945540168; Wed, 02 Mar 2016 11:05:40 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.169.35 with HTTP; Wed, 2 Mar 2016 11:05:40 -0800 (PST) In-Reply-To: <56D6155C.3040105@gmail.com> References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com> <56CEB3F2.8060101@si6networks.com> <56D6155C.3040105@gmail.com> Date: Wed, 2 Mar 2016 11:05:40 -0800 X-Google-Sender-Auth: 1-lFw1aG40cp68qch-lupgiCsEg Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:05:42 -0000 At Wed, 2 Mar 2016 11:19:08 +1300, Brian E Carpenter wrote: > On 27/02/2016 11:18, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > ... > > If we keep this appendix, > > I'd strongly suggest including at least one open-source BSD variant. > > That would be good, but I think it's important to write at the beginning > that the tests and observations only involved a small number of stacks > and that probably not all divergent behaviours have been discovered. In case my point wasn't taken as I intended: I didn't make this suggestion to list *all divergent behaviours*; it's an impossible goal. I suggested this because in its current content the number of tested stacks is *too small*, especially in that there's essentially only one 100% open-source instance: Linux (of different distributions). I believe including open-source implementations in this type of data is particularly important since anyone can reproduce the test scenario more easily and can identify whether it's actually a stupid implementation defect or it's more likely a result of protocol spec ambiguity. And if we know at least more than one totally different implementations show odd behavior, it should suggest the existence of a more general problem in the specification. In that sense, it seems to be a very poor choice to simply use the same OS. It's also not very clear to me how/whether the choice of different distributions and slightly different kernel versions matters. This point is also related to my other higher-level comment on the appendices (I think Fernando made basically the same point): it's currently presented in a very unorganized way and it's very painful to read. It's not immediately clear whether different distributions/kernel versions were chosen to highlight some particular difference between the versions/distributions, or were simply chosen randomly available for the tester at the time of the test. Sometimes it may be useful to show that a particular odd behavior doesn't change in multiple different versions, but it's also not clear from the current presentation whether it tries to highlight that kind of point. If this is a personal technical blog or something, it may be okay. But it's not acceptable to me as a professional technical document such as an RFC. -- JINMEI, Tatuya From nobody Wed Mar 2 12:00:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFB51B2E6F for ; Wed, 2 Mar 2016 12:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.988 X-Spam-Level: * X-Spam-Status: No, score=1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G8m1vsKDW0r for ; Wed, 2 Mar 2016 12:00:00 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9A81B2E6A for ; Wed, 2 Mar 2016 12:00:00 -0800 (PST) Received: by mail-pa0-x234.google.com with SMTP id bj10so69435520pad.2 for ; Wed, 02 Mar 2016 12:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=u/jXu2yfPJ7DonPFK58dD7IuZ8P7tMHrzD+bU8tkkLk=; b=Pfo5siqqt3kG0KuHpZSg5aA8tLHnig3EiuwHzAVWsZuetqzQ0e1iSDPePw14++hFAd ZJZvqJkFlAzR3h7pU/CvfpSCJoFwEFJ5kbFpTA6S7RLZNLfITcU2tNtMCjySEvx8kNzT HZpry+s6j78PJqwW5r4uCgds895SZ16goysdgku81EAipoBbXW+vuhNIatEVVHNo6ti+ Y6ZlXkrhMhIRcZK9s/21zEFfd0wJDHM+wxqBCgtJNubomadX83fbdghq/rkVFaM0XzjX UALMXfaZYex22rnkD02YXI6p8paatGlY6WgCKgiHTzaBgqAPVn1MM9jy5XBROke/Xaxt ap8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=u/jXu2yfPJ7DonPFK58dD7IuZ8P7tMHrzD+bU8tkkLk=; b=liBTqjJWEEfFeJiKOA96NYqepmjVmJLYLTJP7qOjfhUQIjODzqIfCKnvKM2RPEeMpa akOfWZ3cb0oYMkZE7dVrux4gnZCrrqCaK278M/L1zdr7RjEbX2q261OngN3sq1t5/Dol xsyZCBtgF5cWNLyUcfviClclrCCLEOwh2/GxFZzSSRfCK9JOO39AKoBjts1EisWZwgO4 JQX5Vw/xIPbIohlSq3b2ncQRnng/pXTuTYSFaUb19xjV4l4gltXZsgz2G7mrvytm+Rgy lxZ1bpbnahKh9IlnIgBxxigJmXKn5YAoj3iW7IQgyUkOCu+ni/qJ3BHu+e7mSR+jsdD7 REwQ== X-Gm-Message-State: AD7BkJL00fjWEFPWdsvdIEWdsR7u4A4UF+Qe3cvpWYIpHypovxBgrRCZoSnmq9ZM2px/Nw== X-Received: by 10.66.65.137 with SMTP id x9mr2504332pas.137.1456948800090; Wed, 02 Mar 2016 12:00:00 -0800 (PST) Received: from ?IPv6:2406:e007:451b:1:28cc:dc4c:9703:6781? ([2406:e007:451b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id xa9sm55001973pab.44.2016.03.02.11.59.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2016 11:59:57 -0800 (PST) To: otroan@employees.org References: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com> <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org> <56CCAE04.6010308@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56D74640.2060502@gmail.com> Date: Thu, 3 Mar 2016 09:00:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CCAE04.6010308@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:00:01 -0000 I'm sorry to distract the group with a practical question, but I'm a bit stumped. My question is below. In the thread "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)", on 24/02/2016 08:07, Brian E Carpenter wrote: > On 24/02/2016 07:53, otroan@employees.org wrote: >>>> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups. >>> >>> Yes. What is the possible use of a link-local "join"? The packets are just there >>> on the link anyway, so "joining" is entirely an internal matter for each node. >>> >>> However, it is the case that some switches are not transparent to LL multicasts >>> to arbitrary addresses. For example in some tests I did recently, the lab switch >>> was transparent to ff02::1 but opaque to ff02::114. >> >> it was presumably snooping on MLD and did forward when it had received a join for ff02::114? > > Possibly. I fixed the problem by inserting a dumb bridge that does what bridges > are supposed to do. > >> the switch designers I've spoken to state that they cannot scale for the number of multicast groups, in particular solicited node multicast. I think they often do an exception for ff02::1 and treat that as broadcast. > > But why not pass all LL multicasts? > > Anyway, if this is common behaviour by switches it has to be allowed for. Now my practical question. When a host starts listening to a LL multicast address, who or what sends the MLD Listener Report? Is the stack supposed to do so automatically, or does the socket programmer have to do something? RFC 3810 really doesn't answer this question, and Google has been unable to help me. A Python fragment is below to show what I am actually doing. This works perfectly, but not when the LAN switch is filtering multicasts. Thanks Brian GRASP_LISTEN_PORT = 1021 ALL_GRASP_NEIGHBOR_6 = ipaddress.IPv6Address('ff02::114') mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) mcrsock.bind(('',GRASP_LISTEN_PORT)) mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_zone_id) mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq) mcrsock.settimeout(300) rawmsg, send_addr = mcrsock.recvfrom(2048) From nobody Wed Mar 2 13:13:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8701B30DD for ; Wed, 2 Mar 2016 13:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.489 X-Spam-Level: *** X-Spam-Status: No, score=3.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, FRT_STOCK2=3.988, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh78-smQAciE for ; Wed, 2 Mar 2016 13:13:03 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F94D1B30D8 for ; Wed, 2 Mar 2016 13:13:03 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id e6so1731803vkh.2 for ; Wed, 02 Mar 2016 13:13:03 -0800 (PST) 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; bh=Z0t3cEulb7woQCY+0yDLD96Gq58964ApKThRiaiGt7I=; b=uUcvEszVx+CAExWFLiTtlQQtVeLhwtuaxmTTYzSTYv1xOIGTWYW0Aaj1c1otO+71+o lSJ9PLB0ZMONJgVvqlB0AEs5QsiBJhsoW9xpthYQVLoh4HdT3vpAUor9e4wjYPVtShEu VafKYLjCRNW2t3zgCgmJP+TKcmtSL1eCpWMOhgjn4kPX/1ZxxVHWQ+jeKm0XxbJxvSoY YdjqFAkZmGIbOCsfvcvDRCSs6QIUTmCBI8PSvlnWbtnE9ybWzwi49LQLTbHEVHHGerYm 9nTcapDt1yWMJHz5jg/GPxGLwvYmyzdGSZAG0oylB7CfOJxRPiilLobiB8atq0BhUAtr m1lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Z0t3cEulb7woQCY+0yDLD96Gq58964ApKThRiaiGt7I=; b=ZTlJF7FkZ58/Q9LrwDd+/Y8jHisksBzdwd2yXXl5eMeJGZx7rJGJoW+dFIY4tr/A8M b1Wv/cXGe0TxcKBRXnXi1m3RoR2qgJnjwAnCFAcFVa6Xt2fwhrY9wW0bU6vu8BNAGzb9 NLm5yYDayQcE5cv0mk76sA2NTMNi3c2NS+RSX1UJgyjOaZ3jyscyAQlOdyL6NUd6oxOo SA3OIOBX2Ap3glFHEMTrdiSHxEMKnG2c9vMFe6ad/tjm8N1JJAxp5rr+JWNvoeHv9rNo XYeLF6OYTawEDsxahp/eEiA9xLPP+ej8n258vkH+Uf5fiopaB64Y1/a4UXbgRy/eLf/l zQfg== X-Gm-Message-State: AD7BkJLLbabe4bMGkVqmLYvWg4a8tqb3jvIuP5mWuu7hAPPU0j4xj0RTFM1JUfShxNQO91M82GLQ3S7XqBCb0g== MIME-Version: 1.0 X-Received: by 10.31.54.75 with SMTP id d72mr21284757vka.30.1456953182721; Wed, 02 Mar 2016 13:13:02 -0800 (PST) Received: by 10.176.5.68 with HTTP; Wed, 2 Mar 2016 13:13:02 -0800 (PST) Received: by 10.176.5.68 with HTTP; Wed, 2 Mar 2016 13:13:02 -0800 (PST) In-Reply-To: <56D74640.2060502@gmail.com> References: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com> <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org> <56CCAE04.6010308@gmail.com> <56D74640.2060502@gmail.com> Date: Thu, 3 Mar 2016 08:13:02 +1100 Message-ID: From: Mark Smith To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11430a1ee91a72052d175833 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 21:13:06 -0000 --001a11430a1ee91a72052d175833 Content-Type: text/plain; charset=UTF-8 On 3 Mar 2016 07:00, "Brian E Carpenter" wrote: > > I'm sorry to distract the group with a practical question, but I'm a bit stumped. > My question is below. > > In the thread "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)", on > 24/02/2016 08:07, Brian E Carpenter wrote: > > On 24/02/2016 07:53, otroan@employees.org wrote: > >>>> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups. > >>> > >>> Yes. What is the possible use of a link-local "join"? The packets are just there > >>> on the link anyway, so "joining" is entirely an internal matter for each node. > >>> > >>> However, it is the case that some switches are not transparent to LL multicasts > >>> to arbitrary addresses. For example in some tests I did recently, the lab switch > >>> was transparent to ff02::1 but opaque to ff02::114. > >> > >> it was presumably snooping on MLD and did forward when it had received a join for ff02::114? > > > > Possibly. I fixed the problem by inserting a dumb bridge that does what bridges > > are supposed to do. > > > >> the switch designers I've spoken to state that they cannot scale for the number of multicast groups, in particular solicited node multicast. I think they often do an exception for ff02::1 and treat that as broadcast. > > > > But why not pass all LL multicasts? > > > > Anyway, if this is common behaviour by switches it has to be allowed for. > > Now my practical question. When a host starts listening to a LL multicast address, > who or what sends the MLD Listener Report? Is the stack supposed to do so > automatically, or does the socket programmer have to do something? RFC 3810 > really doesn't answer this question, and Google has been unable to help me. > My expectation is the stack, and when I wrote the following a number of years a go, I'm pretty sure I saw the (Linux) stack doing it for LL multicasts. https://github.com/markzzzsmith/replicast I think the stack would have to do it unless the application had a MLD client implementation in it to send periodic reports and to respond to MLD router queries. > A Python fragment is below to show what I am actually doing. This works > perfectly, but not when the LAN switch is filtering multicasts. > Is any sort of active multicast filtering enabled e.g., MLD snooping? If not, it reminds me of some ADSL DSLAMs that will pass IPv4 multicasts but not IPv6 ones thorough "transparent LAN service" configurations. Regards, Mark. > Thanks > Brian > > GRASP_LISTEN_PORT = 1021 > ALL_GRASP_NEIGHBOR_6 = ipaddress.IPv6Address('ff02::114') > > mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) > mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) > mcrsock.bind(('',GRASP_LISTEN_PORT)) > mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_zone_id) > mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq) > mcrsock.settimeout(300) > rawmsg, send_addr = mcrsock.recvfrom(2048) --001a11430a1ee91a72052d175833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 Mar 2016 07:00, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>
> I'm sorry to distract the group with a practical question, but I&#= 39;m a bit stumped.
> My question is below.
>
> In the thread "Further Mitigating Router ND Cache Exhaustion DoS = Attacks Using Solicited-Node Group Membership (-01)", on
> 24/02/2016 08:07, Brian E Carpenter wrote:
> > On 24/02/2016 07:53, otro= an@employees.org wrote:
> >>>> MLD joins for the solicited node multicast address ha= s turned out to have little practical purpose. I am thinking of going the o= ther way and stop sending joins for link-local multicast groups.
> >>>
> >>> Yes. What is the possible use of a link-local "join&= quot;?=C2=A0 The packets are just there
> >>> on the link anyway, so "joining" is entirely an= internal matter for each node.
> >>>
> >>> However, it is the case that some switches are not transp= arent to LL multicasts
> >>> to arbitrary addresses. For example in some tests I did r= ecently, the lab switch
> >>> was transparent to ff02::1 but opaque to ff02::114.
> >>
> >> it was presumably snooping on MLD and did forward when it had= received a join for ff02::114?
> >
> > Possibly. I fixed the problem by inserting a dumb bridge that doe= s what bridges
> > are supposed to do.
> >
> >> the switch designers I've spoken to state that they canno= t scale for the number of multicast groups, in particular solicited node mu= lticast. I think they often do an exception for ff02::1 and treat that as b= roadcast.
> >
> > But why not pass all LL multicasts?
> >
> > Anyway, if this is common behaviour by switches it has to be allo= wed for.
>
> Now my practical question. When a host starts listening to a LL multic= ast address,
> who or what sends the MLD Listener Report? Is the stack supposed to do= so
> automatically, or does the socket programmer have to do something? RFC= 3810
> really doesn't answer this question, and Google has been unable to= help me.
>

My expectation is the stack, and when I wrote the following = a number of years a go, I'm pretty sure I saw the (Linux) stack doing i= t for LL multicasts.

https:= //github.com/markzzzsmith/replicast

I think the stack would have to do it unless the application= had a MLD client implementation in it to send periodic reports and to resp= ond to MLD router queries.

> A Python fragment is below to show what I am actually d= oing. This works
> perfectly, but not when the LAN switch is filtering multicasts.
>

Is any sort of active multicast filtering enabled e.g., MLD = snooping?

If not, it reminds me of some ADSL DSLAMs that will pass IPv= 4 multicasts but not IPv6 ones thorough "transparent LAN service"= configurations.

Regards,
Mark.

> Thanks
> =C2=A0 =C2=A0 Brian
>
> GRASP_LISTEN_PORT =3D=C2=A0 1021
> ALL_GRASP_NEIGHBOR_6 =3D ipaddress.IPv6Address('ff02::114') >
> mcrsock =3D socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
> mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> mcrsock.bind(('',GRASP_LISTEN_PORT))
> mreq =3D ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_z= one_id)
> mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq)<= br> > mcrsock.settimeout(300)
> rawmsg, send_addr =3D mcrsock.recvfrom(2048)

--001a11430a1ee91a72052d175833-- From nobody Wed Mar 2 18:29:35 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F9C1B3961 for ; Wed, 2 Mar 2016 18:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.989 X-Spam-Level: * X-Spam-Status: No, score=1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_-Q4DbaruQI for ; Wed, 2 Mar 2016 18:29:31 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3011B395F for ; Wed, 2 Mar 2016 18:29:30 -0800 (PST) Received: by mail-lb0-x231.google.com with SMTP id x1so7025123lbj.3 for ; Wed, 02 Mar 2016 18:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=e0GHo7RX7mUQW0fwzgUHnShcekUErk2B8fPYNBg339w=; b=slLo7/HnbGnJSPIpdgw+aC2DeyycPMxp41r9SXtaGH+J2DynrqYcE4Vxyzm0iqWAt+ vEyJo57/zbC1Glv0FyQTx+ACqn+CYdi7WHb5UH2OJ2iDAMU3OwsdKM6ypwJtbJdg34EF kk+4MFYbQsDYwvhdiCdMU7liRA3ohS/U2B6B2JzXXY31Ts3/QZlT/qFcn2wTWcRBRCWW fdrld4t8edAGdGi6GvVn1aPWsVyJz7v1LH8XNf6/H1FdNXAzHmY2Un0807qL1OfHiWJN M0Dv9d2Or+HgMLr5gANzLYV/U6zK3dVxfJ5Zzp9cVM7a8BVAKY1IHrb2SFcPU63yXvPZ aMMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=e0GHo7RX7mUQW0fwzgUHnShcekUErk2B8fPYNBg339w=; b=VCZdPPRwXA0t+fkCneIrXZCDcSAkiJ9Ftrj2DiNwGycasb2dW12QwkinnXEGxlHd1/ 8dUNdIjghC9q08RsA/tXG+SHb6VG0w/LuV3ONEVisvnpL5vAkmnwVmxARcKFz+3zucR6 raZOkTufHXYooZnOlNeEkMLpKXGJxLNVhQwNxpbTl5gyuPC2DTezliDAueaOj/0xthw5 KwVVJvfvr7tg8y5kGkoQYUHv6xTYrjlu9AL+HH110z6904Ul5B/YOqmMgffaFl3B9X82 YlmfiF2UQA9ACdZ6A8wlI+PuZqw8XKeOkUNBGOffliwj3xl10FvR++g8ON5uESTwhvNS DVcg== X-Gm-Message-State: AD7BkJKXRi21dJ3Hz27qrm6rPT7LCUI80gH5G+pzi2apPndIcYyAD4JAu267MoFFoPv2sgAXJLOe+60+UVAEXQ== MIME-Version: 1.0 X-Received: by 10.112.67.1 with SMTP id j1mr27533lbt.103.1456972169122; Wed, 02 Mar 2016 18:29:29 -0800 (PST) Received: by 10.25.19.152 with HTTP; Wed, 2 Mar 2016 18:29:29 -0800 (PST) Date: Thu, 3 Mar 2016 15:29:29 +1300 Message-ID: From: Hermin Anggawijaya To: Mark Smith Content-Type: multipart/alternative; boundary=001a11347b0e969cd3052d1bc408 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 02:29:34 -0000 --001a11347b0e969cd3052d1bc408 Content-Type: text/plain; charset=UTF-8 On Linux, the IPv6 stack will generate MLD report (both unsolicited report and as reply to queries) if a socket is set with IPV6_ADD_MEMBERSHIP or IPV6_JOIN_GROUP for the given IPv6 multicast address. And looks like the Python script should do the job. Having seen an MLD report from a host running the Python script, I would have thought that the LAN switch would make the host (or the switch port the host is connected to) to become a member of the multicast group, and the switch should forward all multicast packets for ff02::114. *If the corresponding multicast packets (ff02::114) are indeed filtered by MLD snooping switch* - despite seeing the membership report sent by the host running the script, then on some switches you could try either (depends on availability of features): 1. disable snooping - but this could make the LAN 'chatty' 2. set the default behaviour for unknown multicast address to flood, then apply a filter on the MLDSnooping module so that it never 'learns' ff02::114, thus keeping ff02::114 as unknown multicast 3. add static MLD snooping entry for ff02::114 and make all the ports in the vlan as a member. 4. add ff02::114 as a 'protocol' address to MLD Snooping so that it is flooded properly to 'router ports' like ff02::6, ff02:6, ff02::9 etc. Kind regards Angga On Thu, Mar 3, 2016 at 10:13 AM, Mark Smith wrote: > > On 3 Mar 2016 07:00, "Brian E Carpenter" > wrote: > > > > I'm sorry to distract the group with a practical question, but I'm a bit > stumped. > > My question is below. > > > > In the thread "Further Mitigating Router ND Cache Exhaustion DoS Attacks > Using Solicited-Node Group Membership (-01)", on > > 24/02/2016 08:07, Brian E Carpenter wrote: > > > On 24/02/2016 07:53, otroan@employees.org wrote: > > >>>> MLD joins for the solicited node multicast address has turned out > to have little practical purpose. I am thinking of going the other way and > stop sending joins for link-local multicast groups. > > >>> > > >>> Yes. What is the possible use of a link-local "join"? The packets > are just there > > >>> on the link anyway, so "joining" is entirely an internal matter for > each node. > > >>> > > >>> However, it is the case that some switches are not transparent to LL > multicasts > > >>> to arbitrary addresses. For example in some tests I did recently, > the lab switch > > >>> was transparent to ff02::1 but opaque to ff02::114. > > >> > > >> it was presumably snooping on MLD and did forward when it had > received a join for ff02::114? > > > > > > Possibly. I fixed the problem by inserting a dumb bridge that does > what bridges > > > are supposed to do. > > > > > >> the switch designers I've spoken to state that they cannot scale for > the number of multicast groups, in particular solicited node multicast. I > think they often do an exception for ff02::1 and treat that as broadcast. > > > > > > But why not pass all LL multicasts? > > > > > > Anyway, if this is common behaviour by switches it has to be allowed > for. > > > > Now my practical question. When a host starts listening to a LL > multicast address, > > who or what sends the MLD Listener Report? Is the stack supposed to do so > > automatically, or does the socket programmer have to do something? RFC > 3810 > > really doesn't answer this question, and Google has been unable to help > me. > > > > My expectation is the stack, and when I wrote the following a number of > years a go, I'm pretty sure I saw the (Linux) stack doing it for LL > multicasts. > > https://github.com/markzzzsmith/replicast > > I think the stack would have to do it unless the application had a MLD > client implementation in it to send periodic reports and to respond to MLD > router queries. > > > A Python fragment is below to show what I am actually doing. This works > > perfectly, but not when the LAN switch is filtering multicasts. > > > > Is any sort of active multicast filtering enabled e.g., MLD snooping? > > If not, it reminds me of some ADSL DSLAMs that will pass IPv4 multicasts > but not IPv6 ones thorough "transparent LAN service" configurations. > > Regards, > Mark. > > > Thanks > > Brian > > > > GRASP_LISTEN_PORT = 1021 > > ALL_GRASP_NEIGHBOR_6 = ipaddress.IPv6Address('ff02::114') > > > > mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) > > mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) > > mcrsock.bind(('',GRASP_LISTEN_PORT)) > > mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_zone_id) > > mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq) > > mcrsock.settimeout(300) > > rawmsg, send_addr = mcrsock.recvfrom(2048) > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11347b0e969cd3052d1bc408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Linux, the IPv6 stack will generate= MLD report (both unsolicited report and as reply to queries) if a socket i= s set with IPV6_ADD_MEMBERSHIP or IPV6_JOIN_GROUP for the given IPv6 multic= ast address. And looks like the Python script should do the job.

Having seen an MLD report from a host running the Python script, I = would have thought that the
LAN switch would make the host (o= r the switch port the host is connected to) to become a member of the multi= cast group, and the switch should forward all multicast packets for ff02::1= 14.

*If the corresponding multicast packets (ff02::114) a= re indeed filtered by MLD snooping switch* - despite seeing the membership = report sent by the host running the script, then on some switches you could= try either (depends on availability of features):

1. dis= able snooping - but this could make the LAN 'chatty'
= 2. set the default behaviour for unknown multicast address to flood, then a= pply a filter on the MLDSnooping module so that it never 'learns' f= f02::114, thus keeping ff02::114 as unknown multicast
3. add = static MLD snooping entry for ff02::114 and make all the ports in the vlan = as a member.
4. add ff02::114 as a 'protocol' address= to MLD Snooping so that it is flooded properly to 'router ports' l= ike ff02::6, ff02:6, ff02::9 etc.


Kind reg= ards

Angga



On Thu, Mar 3, 2016 at 10:13 A= M, Mark Smith <markzzzsmith@gmail.com> wrote:


On 3 Mar 2016 07:00, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>
> I'm sorry to distract the group with a practical question, but I&#= 39;m a bit stumped.
> My question is below.
>
> In the thread "Further Mitigating Router ND Cache Exhaustion DoS = Attacks Using Solicited-Node Group Membership (-01)", on
> 24/02/2016 08:07, Brian E Carpenter wrote:
> > On 24/02/2016 07:53, otroan@employees.org wrote:
> >>>> MLD joins for the solicited node multicast address ha= s turned out to have little practical purpose. I am thinking of going the o= ther way and stop sending joins for link-local multicast groups.
> >>>
> >>> Yes. What is the possible use of a link-local "join&= quot;?=C2=A0 The packets are just there
> >>> on the link anyway, so "joining" is entirely an= internal matter for each node.
> >>>
> >>> However, it is the case that some switches are not transp= arent to LL multicasts
> >>> to arbitrary addresses. For example in some tests I did r= ecently, the lab switch
> >>> was transparent to ff02::1 but opaque to ff02::114.
> >>
> >> it was presumably snooping on MLD and did forward when it had= received a join for ff02::114?
> >
> > Possibly. I fixed the problem by inserting a dumb bridge that doe= s what bridges
> > are supposed to do.
> >
> >> the switch designers I've spoken to state that they canno= t scale for the number of multicast groups, in particular solicited node mu= lticast. I think they often do an exception for ff02::1 and treat that as b= roadcast.
> >
> > But why not pass all LL multicasts?
> >
> > Anyway, if this is common behaviour by switches it has to be allo= wed for.
>
> Now my practical question. When a host starts listening to a LL multic= ast address,
> who or what sends the MLD Listener Report? Is the stack supposed to do= so
> automatically, or does the socket programmer have to do something? RFC= 3810
> really doesn't answer this question, and Google has been unable to= help me.
>

My expectation is the stack, and when I wrote the fol= lowing a number of years a go, I'm pretty sure I saw the (Linux) stack = doing it for LL multicasts.

https://github.com/markzzzsmith/replicast

I think the stack would have to do it unless the application= had a MLD client implementation in it to send periodic reports and to resp= ond to MLD router queries.

> A Python fragment is below to show what I am actually d= oing. This works
> perfectly, but not when the LAN switch is filtering multicasts.
>

Is any sort of active multicast filtering enabled e.g= ., MLD snooping?

If not, it reminds me of some ADSL DSLAMs that will pass IPv= 4 multicasts but not IPv6 ones thorough "transparent LAN service"= configurations.

Regards,
Mark.

> Thanks
> =C2=A0 =C2=A0 Brian
>
> GRASP_LISTEN_PORT =3D=C2=A0 1021
> ALL_GRASP_NEIGHBOR_6 =3D ipaddress.IPv6Address('ff02::114') >
> mcrsock =3D socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
> mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> mcrsock.bind(('',GRASP_LISTEN_PORT))
> mreq =3D ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_z= one_id)
> mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq)<= br> > mcrsock.settimeout(300)
> rawmsg, send_addr =3D mcrsock.recvfrom(2048)


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


--001a11347b0e969cd3052d1bc408-- From nobody Wed Mar 2 18:44:52 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAF01B39CD for ; Wed, 2 Mar 2016 18:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.711 X-Spam-Level: ** X-Spam-Status: No, score=2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVuRwwDUHcTy for ; Wed, 2 Mar 2016 18:44:48 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FDE1B39CC for ; Wed, 2 Mar 2016 18:44:47 -0800 (PST) Received: by mail-lb0-x236.google.com with SMTP id of3so7365132lbc.1 for ; Wed, 02 Mar 2016 18:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6AhonC/k6wt/7ceaXxj7pDjMi97wZ0pP4csIXNFPd+o=; b=GChJh9NxFiUbzLpZ8FHM45DuNeQjp92BDWU0HQORCRjuArJ7S79bThJ0FlMc1+MrM1 9gQtzN7Udp40/GRDek2bz38f3xzuASj1m2Y5xtExse4Mgbcv0ofMAIKIHMp9+xPC/Lzy lrtsI7hNjT4PSMVhloAu83qn8ra8NgHK5Xk0gx8A4fnOs8mCrQ7FToSJX5C3NKYslD88 gAMqKvE2w9kngrJFLDSNeGYyNOiRjwQ7EQWsAa7u6xQxlUGi3Enf8xrogzs38WceNW8F eFSuPE3WLgWOpEyx03/ixpp54+3SnlJMyWB4rmCOQ8IR3S9f7ef5G0WdUSNd+Zqn8Zb4 fwGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6AhonC/k6wt/7ceaXxj7pDjMi97wZ0pP4csIXNFPd+o=; b=h8yaJKh6jo/U+ZknsaU7gH20UvSInyKMMQnudbTVoS0fK1XKqC8Nsa6l9hv2l5Zrl+ nMmEDabUIQYd1ZP01Mxl4RTVOcYtItUALzVtXEfP/6Kyxsw6qVik62Czm2/4YQcUDRMe 7WeZ9/33ew5BGNnJtOiXv0P/L+gwfWOxG/hQ7NrJq3BaL76yq2pPNCRh2mOOFCflDlsV ojE8Y6UmVdVX+FD/IyIMTE4ipVzOoVwEkhHishWY0lOdIsJ4R24eGnSCvGqDpYZeh6h+ /+T2arTvydmn5JtoV/ppzHVPtaNYw1SDqm3FaHkAsc8Ga+nVYFG+CyfQj0CZkV+XfYDF YjFA== X-Gm-Message-State: AD7BkJLMULcyVCliJqNF5CdxvglrWj7yJ/P4MNCKOY7Y5mxq7UOHaOcYQ+f0c1QV1j23tOjvXwYajVAjSE3UWg== MIME-Version: 1.0 X-Received: by 10.112.171.163 with SMTP id av3mr48810lbc.145.1456973086196; Wed, 02 Mar 2016 18:44:46 -0800 (PST) Received: by 10.25.89.78 with HTTP; Wed, 2 Mar 2016 18:44:46 -0800 (PST) Received: by 10.25.89.78 with HTTP; Wed, 2 Mar 2016 18:44:46 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Mar 2016 18:44:46 -0800 Message-ID: From: Stig Venaas To: Hermin Anggawijaya Content-Type: multipart/alternative; boundary=001a11c36b36401b9f052d1bfb6e Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 02:44:51 -0000 --001a11c36b36401b9f052d1bfb6e Content-Type: text/plain; charset=UTF-8 Yes, the stack should take care of sending the report. In many cases applications don't have the privileges. Also the stack knows the aggregate state of all the sockets. Multiple applications could listen to the same group, and in response to general queries you also need the aggregate state. Stig On Mar 2, 2016 6:29 PM, "Hermin Anggawijaya" wrote: > > On Linux, the IPv6 stack will generate MLD report (both unsolicited report > and as reply to queries) if a socket is set with IPV6_ADD_MEMBERSHIP or > IPV6_JOIN_GROUP for the given IPv6 multicast address. And looks like the > Python script should do the job. > > Having seen an MLD report from a host running the Python script, I would > have thought that the > LAN switch would make the host (or the switch port the host is connected > to) to become a member of the multicast group, and the switch should > forward all multicast packets for ff02::114. > > *If the corresponding multicast packets (ff02::114) are indeed filtered by > MLD snooping switch* - despite seeing the membership report sent by the > host running the script, then on some switches you could try either > (depends on availability of features): > > 1. disable snooping - but this could make the LAN 'chatty' > 2. set the default behaviour for unknown multicast address to flood, then > apply a filter on the MLDSnooping module so that it never 'learns' > ff02::114, thus keeping ff02::114 as unknown multicast > 3. add static MLD snooping entry for ff02::114 and make all the ports in > the vlan as a member. > 4. add ff02::114 as a 'protocol' address to MLD Snooping so that it is > flooded properly to 'router ports' like ff02::6, ff02:6, ff02::9 etc. > > > Kind regards > > Angga > > > > On Thu, Mar 3, 2016 at 10:13 AM, Mark Smith > wrote: > >> >> On 3 Mar 2016 07:00, "Brian E Carpenter" >> wrote: >> > >> > I'm sorry to distract the group with a practical question, but I'm a >> bit stumped. >> > My question is below. >> > >> > In the thread "Further Mitigating Router ND Cache Exhaustion DoS >> Attacks Using Solicited-Node Group Membership (-01)", on >> > 24/02/2016 08:07, Brian E Carpenter wrote: >> > > On 24/02/2016 07:53, otroan@employees.org wrote: >> > >>>> MLD joins for the solicited node multicast address has turned out >> to have little practical purpose. I am thinking of going the other way and >> stop sending joins for link-local multicast groups. >> > >>> >> > >>> Yes. What is the possible use of a link-local "join"? The packets >> are just there >> > >>> on the link anyway, so "joining" is entirely an internal matter for >> each node. >> > >>> >> > >>> However, it is the case that some switches are not transparent to >> LL multicasts >> > >>> to arbitrary addresses. For example in some tests I did recently, >> the lab switch >> > >>> was transparent to ff02::1 but opaque to ff02::114. >> > >> >> > >> it was presumably snooping on MLD and did forward when it had >> received a join for ff02::114? >> > > >> > > Possibly. I fixed the problem by inserting a dumb bridge that does >> what bridges >> > > are supposed to do. >> > > >> > >> the switch designers I've spoken to state that they cannot scale for >> the number of multicast groups, in particular solicited node multicast. I >> think they often do an exception for ff02::1 and treat that as broadcast. >> > > >> > > But why not pass all LL multicasts? >> > > >> > > Anyway, if this is common behaviour by switches it has to be allowed >> for. >> > >> > Now my practical question. When a host starts listening to a LL >> multicast address, >> > who or what sends the MLD Listener Report? Is the stack supposed to do >> so >> > automatically, or does the socket programmer have to do something? RFC >> 3810 >> > really doesn't answer this question, and Google has been unable to help >> me. >> > >> >> My expectation is the stack, and when I wrote the following a number of >> years a go, I'm pretty sure I saw the (Linux) stack doing it for LL >> multicasts. >> >> https://github.com/markzzzsmith/replicast >> >> I think the stack would have to do it unless the application had a MLD >> client implementation in it to send periodic reports and to respond to MLD >> router queries. >> >> > A Python fragment is below to show what I am actually doing. This works >> > perfectly, but not when the LAN switch is filtering multicasts. >> > >> >> Is any sort of active multicast filtering enabled e.g., MLD snooping? >> >> If not, it reminds me of some ADSL DSLAMs that will pass IPv4 multicasts >> but not IPv6 ones thorough "transparent LAN service" configurations. >> >> Regards, >> Mark. >> >> > Thanks >> > Brian >> > >> > GRASP_LISTEN_PORT = 1021 >> > ALL_GRASP_NEIGHBOR_6 = ipaddress.IPv6Address('ff02::114') >> > >> > mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) >> > mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) >> > mcrsock.bind(('',GRASP_LISTEN_PORT)) >> > mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_zone_id) >> > mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq) >> > mcrsock.settimeout(300) >> > rawmsg, send_addr = mcrsock.recvfrom(2048) >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c36b36401b9f052d1bfb6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, the stack should take care of sending the report. In ma= ny cases applications don't have the privileges. Also the stack knows t= he aggregate state of all the sockets. Multiple applications could listen t= o the same group, and in response to general=C2=A0 queries you also need th= e aggregate state.

Stig

On Mar 2, 2016 6:29 PM, "Hermin Anggawijaya= " <hermin.anggawija= ya@gmail.com> wrote:

On Linux, the IPv6 stack will = generate MLD report (both unsolicited report and as reply to queries) if a = socket is set with IPV6_ADD_MEMBERSHIP or IPV6_JOIN_GROUP for the given IPv= 6 multicast address. And looks like the Python script should do the job.
Having seen an MLD report from a host running the Python sc= ript, I would have thought that the
LAN switch would make the= host (or the switch port the host is connected to) to become a member of t= he multicast group, and the switch should forward all multicast packets for= ff02::114.

*If the corresponding multicast packets (ff02= ::114) are indeed filtered by MLD snooping switch* - despite seeing the mem= bership report sent by the host running the script, then on some switches y= ou could try either (depends on availability of features):

1. disable snooping - but this could make the LAN 'chatty'
2. set the default behaviour for unknown multicast address to flood= , then apply a filter on the MLDSnooping module so that it never 'learn= s' ff02::114, thus keeping ff02::114 as unknown multicast
3. add static MLD snooping entry for ff02::114 and make all the ports in t= he vlan as a member.
4. add ff02::114 as a 'protocol'= address to MLD Snooping so that it is flooded properly to 'router port= s' like ff02::6, ff02:6, ff02::9 etc.


= Kind regards

Angga



<= div class=3D"gmail_extra">
On Thu, Mar 3, 2016 at= 10:13 AM, Mark Smith <markzzzsmith@gmail.com> wrote:

On 3 Mar 2016 07:00, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>
> I'm sorry to distract the group with a practical question, but I&#= 39;m a bit stumped.
> My question is below.
>
> In the thread "Further Mitigating Router ND Cache Exhaustion DoS = Attacks Using Solicited-Node Group Membership (-01)", on
> 24/02/2016 08:07, Brian E Carpenter wrote:
> > On 24/02/2016 07:53, otroan@employees.org wrote:
> >>>> MLD joins for the solicited node multicast address ha= s turned out to have little practical purpose. I am thinking of going the o= ther way and stop sending joins for link-local multicast groups.
> >>>
> >>> Yes. What is the possible use of a link-local "join&= quot;?=C2=A0 The packets are just there
> >>> on the link anyway, so "joining" is entirely an= internal matter for each node.
> >>>
> >>> However, it is the case that some switches are not transp= arent to LL multicasts
> >>> to arbitrary addresses. For example in some tests I did r= ecently, the lab switch
> >>> was transparent to ff02::1 but opaque to ff02::114.
> >>
> >> it was presumably snooping on MLD and did forward when it had= received a join for ff02::114?
> >
> > Possibly. I fixed the problem by inserting a dumb bridge that doe= s what bridges
> > are supposed to do.
> >
> >> the switch designers I've spoken to state that they canno= t scale for the number of multicast groups, in particular solicited node mu= lticast. I think they often do an exception for ff02::1 and treat that as b= roadcast.
> >
> > But why not pass all LL multicasts?
> >
> > Anyway, if this is common behaviour by switches it has to be allo= wed for.
>
> Now my practical question. When a host starts listening to a LL multic= ast address,
> who or what sends the MLD Listener Report? Is the stack supposed to do= so
> automatically, or does the socket programmer have to do something? RFC= 3810
> really doesn't answer this question, and Google has been unable to= help me.
>

My expectation is the stack, and when I wrote the fol= lowing a number of years a go, I'm pretty sure I saw the (Linux) stack = doing it for LL multicasts.

https://github.com/markzzzsmith/replicast

I think the stack would have to do it unless the application= had a MLD client implementation in it to send periodic reports and to resp= ond to MLD router queries.

> A Python fragment is below to show what I am actually d= oing. This works
> perfectly, but not when the LAN switch is filtering multicasts.
>

Is any sort of active multicast filtering enabled e.g= ., MLD snooping?

If not, it reminds me of some ADSL DSLAMs that will pass IPv= 4 multicasts but not IPv6 ones thorough "transparent LAN service"= configurations.

Regards,
Mark.

> Thanks
> =C2=A0 =C2=A0 Brian
>
> GRASP_LISTEN_PORT =3D=C2=A0 1021
> ALL_GRASP_NEIGHBOR_6 =3D ipaddress.IPv6Address('ff02::114') >
> mcrsock =3D socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
> mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> mcrsock.bind(('',GRASP_LISTEN_PORT))
> mreq =3D ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_z= one_id)
> mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq)<= br> > mcrsock.settimeout(300)
> rawmsg, send_addr =3D mcrsock.recvfrom(2048)


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



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

--001a11c36b36401b9f052d1bfb6e-- From nobody Wed Mar 2 19:58:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA81B3B48 for ; Wed, 2 Mar 2016 19:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.988 X-Spam-Level: * X-Spam-Status: No, score=1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcYv13GxtjUj for ; Wed, 2 Mar 2016 19:58:31 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634A31B3B47 for ; Wed, 2 Mar 2016 19:58:31 -0800 (PST) Received: by mail-pa0-x236.google.com with SMTP id fy10so6688215pac.1 for ; Wed, 02 Mar 2016 19:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=eCgVd4ooKSAnNvWRsN4ULURuWvU5XEBAFITxjcOIfMo=; b=j9h1H9pOj+RjrXwuDzqTCRBrE3KFQSH408PHfjp/Ej2oJVi8ThKsFuf6Bz0nSns8d2 5ZCp2ecoQnXH4zPPSlPndCBA+vgo1Dx0LSKfrIygqFYsJEj5F5O14kY2lc1h44BHgRgU pYkX0xYBwYOI/Tw2clot7FdaYyuPdHGfCI10E6kS033R9mTG06I5xUzNqdMK7ki9pWMg +emy5zJTo3OSw7Uz6Idudtxywo5YKlaoEuoOSMPDhN2bbDHRa4MK8+djBB1m4wceVc1/ FmtlsDDufOmBkDWmHysr4+v0nfeMi4C96AF7W3Nz66OO6Nnx7JjWlPcSxSuxqeRvMwcF eEQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=eCgVd4ooKSAnNvWRsN4ULURuWvU5XEBAFITxjcOIfMo=; b=ZeojJNZk5Jo6TpK6e60r/+deklVtAfHRrMSdqdmD4RcWd7vVaaggsj0XEP4FQ+9zfH 5aGL4bXrs8ZRfBZCSYF6HKc+BErzRvJ3achvplIhvmYGrrTkZL+JaRFcEc5UuIgjDyd2 5oRJAQ5lUT2sP4wewV1Wif3+dcHLJq9p23SJzJBrh+WIQfW9aaSetuxycKl/DiLSypMZ YdIyvgSK+Re56/GG8UMvI7MmQmgZ4SSXjEojhDsQJxayQyCoKn2irQX5ANEXZbaUFZMU nOjyc1zNuDl+Ley0SayAN/0UT8eYcrDAQxKfqBj+Qt+xM3slFMntIRUIPgE5YX2d5Tlv UMQA== X-Gm-Message-State: AD7BkJJLKun+K8B9ZGVE5wJYyCN4KJESDwxr2YMrZVLVh9PLQr26ClAY/xab+PdEH+EQCw== X-Received: by 10.66.160.231 with SMTP id xn7mr678213pab.134.1456977510724; Wed, 02 Mar 2016 19:58:30 -0800 (PST) Received: from ?IPv6:2406:e007:451b:1:28cc:dc4c:9703:6781? ([2406:e007:451b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id vy6sm56318101pac.38.2016.03.02.19.58.27 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2016 19:58:28 -0800 (PST) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56D7B667.6020009@gmail.com> Date: Thu, 3 Mar 2016 16:58:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 03:58:34 -0000 Thanks to everyone who replied on and off list. I've confirmed with Wireshark that Windows 7 does send appropriate MLD2 listener reports and I am assured that Linux does so too (but I'd need to go back in the lab to confirm that personally). So I guess the switch involved is not processing MLD correctly. Oughta be a law against it. Regards Brian On 03/03/2016 15:44, Stig Venaas wrote: > Yes, the stack should take care of sending the report. In many cases > applications don't have the privileges. Also the stack knows the aggregate > state of all the sockets. Multiple applications could listen to the same > group, and in response to general queries you also need the aggregate > state. > > Stig > On Mar 2, 2016 6:29 PM, "Hermin Anggawijaya" > wrote: > >> >> On Linux, the IPv6 stack will generate MLD report (both unsolicited report >> and as reply to queries) if a socket is set with IPV6_ADD_MEMBERSHIP or >> IPV6_JOIN_GROUP for the given IPv6 multicast address. And looks like the >> Python script should do the job. >> >> Having seen an MLD report from a host running the Python script, I would >> have thought that the >> LAN switch would make the host (or the switch port the host is connected >> to) to become a member of the multicast group, and the switch should >> forward all multicast packets for ff02::114. >> >> *If the corresponding multicast packets (ff02::114) are indeed filtered by >> MLD snooping switch* - despite seeing the membership report sent by the >> host running the script, then on some switches you could try either >> (depends on availability of features): >> >> 1. disable snooping - but this could make the LAN 'chatty' >> 2. set the default behaviour for unknown multicast address to flood, then >> apply a filter on the MLDSnooping module so that it never 'learns' >> ff02::114, thus keeping ff02::114 as unknown multicast >> 3. add static MLD snooping entry for ff02::114 and make all the ports in >> the vlan as a member. >> 4. add ff02::114 as a 'protocol' address to MLD Snooping so that it is >> flooded properly to 'router ports' like ff02::6, ff02:6, ff02::9 etc. >> >> >> Kind regards >> >> Angga >> >> >> >> On Thu, Mar 3, 2016 at 10:13 AM, Mark Smith >> wrote: >> >>> >>> On 3 Mar 2016 07:00, "Brian E Carpenter" >>> wrote: >>>> >>>> I'm sorry to distract the group with a practical question, but I'm a >>> bit stumped. >>>> My question is below. >>>> >>>> In the thread "Further Mitigating Router ND Cache Exhaustion DoS >>> Attacks Using Solicited-Node Group Membership (-01)", on >>>> 24/02/2016 08:07, Brian E Carpenter wrote: >>>>> On 24/02/2016 07:53, otroan@employees.org wrote: >>>>>>>> MLD joins for the solicited node multicast address has turned out >>> to have little practical purpose. I am thinking of going the other way and >>> stop sending joins for link-local multicast groups. >>>>>>> >>>>>>> Yes. What is the possible use of a link-local "join"? The packets >>> are just there >>>>>>> on the link anyway, so "joining" is entirely an internal matter for >>> each node. >>>>>>> >>>>>>> However, it is the case that some switches are not transparent to >>> LL multicasts >>>>>>> to arbitrary addresses. For example in some tests I did recently, >>> the lab switch >>>>>>> was transparent to ff02::1 but opaque to ff02::114. >>>>>> >>>>>> it was presumably snooping on MLD and did forward when it had >>> received a join for ff02::114? >>>>> >>>>> Possibly. I fixed the problem by inserting a dumb bridge that does >>> what bridges >>>>> are supposed to do. >>>>> >>>>>> the switch designers I've spoken to state that they cannot scale for >>> the number of multicast groups, in particular solicited node multicast. I >>> think they often do an exception for ff02::1 and treat that as broadcast. >>>>> >>>>> But why not pass all LL multicasts? >>>>> >>>>> Anyway, if this is common behaviour by switches it has to be allowed >>> for. >>>> >>>> Now my practical question. When a host starts listening to a LL >>> multicast address, >>>> who or what sends the MLD Listener Report? Is the stack supposed to do >>> so >>>> automatically, or does the socket programmer have to do something? RFC >>> 3810 >>>> really doesn't answer this question, and Google has been unable to help >>> me. >>>> >>> >>> My expectation is the stack, and when I wrote the following a number of >>> years a go, I'm pretty sure I saw the (Linux) stack doing it for LL >>> multicasts. >>> >>> https://github.com/markzzzsmith/replicast >>> >>> I think the stack would have to do it unless the application had a MLD >>> client implementation in it to send periodic reports and to respond to MLD >>> router queries. >>> >>>> A Python fragment is below to show what I am actually doing. This works >>>> perfectly, but not when the LAN switch is filtering multicasts. >>>> >>> >>> Is any sort of active multicast filtering enabled e.g., MLD snooping? >>> >>> If not, it reminds me of some ADSL DSLAMs that will pass IPv4 multicasts >>> but not IPv6 ones thorough "transparent LAN service" configurations. >>> >>> Regards, >>> Mark. >>> >>>> Thanks >>>> Brian >>>> >>>> GRASP_LISTEN_PORT = 1021 >>>> ALL_GRASP_NEIGHBOR_6 = ipaddress.IPv6Address('ff02::114') >>>> >>>> mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) >>>> mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) >>>> mcrsock.bind(('',GRASP_LISTEN_PORT)) >>>> mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_zone_id) >>>> mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq) >>>> mcrsock.settimeout(300) >>>> rawmsg, send_addr = mcrsock.recvfrom(2048) >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Mar 2 21:55:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F26D1B3E0E for ; Wed, 2 Mar 2016 21:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.797 X-Spam-Level: X-Spam-Status: No, score=-101.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5IQB5aH8j7F for ; Wed, 2 Mar 2016 21:55:05 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F031B3E08 for ; Wed, 2 Mar 2016 21:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:from:content-type:content-transfer-encoding:subject:date: message-id:cc:to:mime-version:x-mailer:return-path; bh=sA4JsjZzllm2FtKAmRYYPqZzKqpvnUbEyf22zAfXD9I=; b=PYETW4a0ne6K9g6geQqaBq8O0Y6hlJMVPAJT4q8gDPF1wrEFYql4/RO9u4ggQ4g+YcciUVhCpLfiH ctsR1OVXg9DNdY7LMTF4OP69EG1K2gxzVEuyyw3KiTbLwRrqW2lqEw13eQEz8l81USgQRPdXyHGqQk EbsX92T99jlwc6v8= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Thu, 3 Mar 2016 15:55:00 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 3 Mar 2016 15:54:44 +1000 From: Geoff Huston Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2016 16:54:56 +1100 Message-ID: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> To: MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Cc: rtg-dir@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 05:55:07 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-v6ops-host-addr-availability-05.txt Reviewer: Geoff Huston =20 Review Date: 3 March 2016=20 IETF LC End Date: 9 March 2016=20 Intended Status: BCP Summary:=20 I have some minor concerns about this document that I think should = be resolved before publication. Comments: BCP documents cover a wide range of purposes - some limit themselves = to documenting current operational practices. Other advocate the = adoption of operational practices that may not be in widespread use at = present. It appears that this document falls into the latter category as = it exposes that network operators provide a IPv6 service that admits the = provision of multiple addresses at connection time. The draft has generated considerable discussion in the V6ops Working = Group, principally relating to the description of the available = technology to perform such provisioning. Section 9.3 comments on Routing, but actually considers the layer 2 = issue of the binding of L2 MAC addresses to IP addresses, noting that in = a totally unconstrained environment it is possible to encounter = scenarios where the number of bindings exceed the capacity of the = network devices. The solution offered, using a single binding entry that = binds a MAC address to a /64 prefix would obviate this problem and also = obviate the need to perform ND and DAD when selecting additional local = addresses, but the document does not make any reference to current = router behaviour and the treatment of multi-addressed hosts.=20 Major Issues: No major issues found. Minor Issues: 1. The Security Considerations section is empty, while the document = explicitly discusses issues relating to the operational integrity of = networks that has an impact on the security of the service. I find it rather anomalous that section 9.3 describes a potential = scenario that would impact the operational integrity of a network, yet = the Security Considerations says =E2=80=9CNone so far.=E2=80=9D As an = absolute minimum it would be reasonable to this reviewer to have the = Security Considerations section reference the considerations described = in Section 9.3 as a potential source of operational instability under = certain circumstances. (While it is not part of a routing-related review = I also note that Section 9.1 talks about security issues as well) 2. The Recommendations section could include consideration of = routing / cache scaling. The recommendations in Section 8 do not include some recommendations = related to the management of MAC to IPv6 address bindings, and indeed on = the nature of these provisioned multiple addresses. I was expecting to = see either some level of admonition of a practice of "chequerboarding" = the address space, where multiple hosts on a network are provisioned = with discrete /128 addresses, or a particular recommendation relating to = the use of prefix delegation as this allows more efficient forms of MAC = to address binding, and limits the level of propagation of individual = host routes in the network Nits: 1. Introduction: -- =E2=80=9Cvirtually unlimited amount of address space=E2=80=9D is = a very imprecise term, and historically its been proved wrong when = claimed for other large spaces. Could the authors think of another term = that avoids any use of the word =E2=80=9Cunlimited=E2=80=9D? -- =E2=80=9Cfuture applications=E2=80=9D is not a benefit per se, = at least not grammatically correct one. =E2=80=9Cflexibility to = accommodate future applications=E2=80=99 needs=E2=80=9D might be closer = to what the author intended. -- =E2=80=9Cthe ability to deploy the Internet=E2=80=9D - surely = this is about =E2=80=9Cthe ability to deploy IPv6-based Internet = services=E2=80=9D instead? 4. Problems=E2=80=A6 -- "Reasons might include hardware limitations=E2=80=9D - begs the = inclusion of a forward reference to section 9.3 From nobody Sat Mar 5 11:44:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C651B360B; Sat, 5 Mar 2016 11:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RroLn5RUcryl; Sat, 5 Mar 2016 11:44:22 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204641B360A; Sat, 5 Mar 2016 11:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6465; q=dns/txt; s=iport; t=1457207062; x=1458416662; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=v+VTmZ4nt2UzUA0gNkYWX6WLzRIMNowioyfcGB99jK8=; b=cUQ2TztTww2FMAyuMLeVafipLO7znwBfs5C7Rqj+4ua6T4xBFth1xyWN qdoZWtInp7hjBrIT+MgXhf7jXDIhNGniGSCarj7CRsxSa6ulSNjO4Bbq8 a8JDrhEsg34plnlL6i2etK5GG9E6l56CR7AY6sPU6nh0mHMxPslOJWsqc o=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOBQDUNdtW/4MNJK1dgzpSbQa8MSGFb?= =?us-ascii?q?gKBIzsRAQEBAQEBAWQnhEEBAQEDASNWBQsCAQgOBgQqAgIyJQIEAQ0FDg2Hfwg?= =?us-ascii?q?OsDiOWgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0IiAYIgkaEFUWCYCuBDwWSeoQwA?= =?us-ascii?q?YMRgWVsiAqBY0uDeYhThXmIWwE2LINkagGIBTx+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,542,1449532800"; d="asc'?scan'208";a="83583787" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2016 19:44:20 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u25JiKYE022849 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 5 Mar 2016 19:44:20 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 5 Mar 2016 13:44:20 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Sat, 5 Mar 2016 13:44:19 -0600 From: "Fred Baker (fred)" To: Geoff Huston , "draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org" Thread-Topic: RigDir review: draft-ietf-v6ops-host-addr-availability Thread-Index: AQHRdxdoVxVp8WEWBEqlueGaVO7qOQ== Date: Sat, 5 Mar 2016 19:44:19 +0000 Message-ID: References: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> In-Reply-To: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.233.63] Content-Type: multipart/signed; boundary="Apple-Mail=_C46996A7-0A54-4D40-926D-012DA0BCA0D2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "v6ops@ietf.org WG" , "rtg-ads@tools.ietf.org" Subject: Re: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 19:44:24 -0000 --Apple-Mail=_C46996A7-0A54-4D40-926D-012DA0BCA0D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Geoff. Lorenzo et al: the draft is right now in IETF Last Call. When that ends, = you will want to update it to address those comments. Include this, = please. > On Mar 3, 2016, at 6:54 AM, Geoff Huston wrote: >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. >=20 > Document: draft-ietf-v6ops-host-addr-availability-05.txt > Reviewer: Geoff Huston > Review Date: 3 March 2016 > IETF LC End Date: 9 March 2016 > Intended Status: BCP >=20 > Summary: >=20 > I have some minor concerns about this document that I think should = be resolved before publication. >=20 > Comments: >=20 > BCP documents cover a wide range of purposes - some limit = themselves to documenting current operational practices. Other advocate = the adoption of operational practices that may not be in widespread use = at present. It appears that this document falls into the latter category = as it exposes that network operators provide a IPv6 service that admits = the provision of multiple addresses at connection time. >=20 > The draft has generated considerable discussion in the V6ops Working = Group, principally relating to the description of the available = technology to perform such provisioning. >=20 > Section 9.3 comments on Routing, but actually considers the layer 2 = issue of the binding of L2 MAC addresses to IP addresses, noting that in = a totally unconstrained environment it is possible to encounter = scenarios where the number of bindings exceed the capacity of the = network devices. The solution offered, using a single binding entry that = binds a MAC address to a /64 prefix would obviate this problem and also = obviate the need to perform ND and DAD when selecting additional local = addresses, but the document does not make any reference to current = router behaviour and the treatment of multi-addressed hosts. >=20 > Major Issues: >=20 > No major issues found. >=20 > Minor Issues: >=20 > 1. The Security Considerations section is empty, while the document = explicitly discusses issues relating to the operational integrity of = networks that has an impact on the security of the service. >=20 > I find it rather anomalous that section 9.3 describes a potential = scenario that would impact the operational integrity of a network, yet = the Security Considerations says =E2=80=9CNone so far.=E2=80=9D As an = absolute minimum it would be reasonable to this reviewer to have the = Security Considerations section reference the considerations described = in Section 9.3 as a potential source of operational instability under = certain circumstances. (While it is not part of a routing-related review = I also note that Section 9.1 talks about security issues as well) >=20 > 2. The Recommendations section could include consideration of = routing / cache scaling. >=20 > The recommendations in Section 8 do not include some = recommendations related to the management of MAC to IPv6 address = bindings, and indeed on the nature of these provisioned multiple = addresses. I was expecting to see either some level of admonition of a = practice of "chequerboarding" the address space, where multiple hosts on = a network are provisioned with discrete /128 addresses, or a particular = recommendation relating to the use of prefix delegation as this allows = more efficient forms of MAC to address binding, and limits the level of = propagation of individual host routes in the network >=20 > Nits: >=20 > 1. Introduction: > -- =E2=80=9Cvirtually unlimited amount of address space=E2=80=9D = is a very imprecise term, and historically its been proved wrong when = claimed for other large spaces. Could the authors think of another term = that avoids any use of the word =E2=80=9Cunlimited=E2=80=9D? >=20 > -- =E2=80=9Cfuture applications=E2=80=9D is not a benefit per se, = at least not grammatically correct one. =E2=80=9Cflexibility to = accommodate future applications=E2=80=99 needs=E2=80=9D might be closer = to what the author intended. >=20 > -- =E2=80=9Cthe ability to deploy the Internet=E2=80=9D - surely = this is about =E2=80=9Cthe ability to deploy IPv6-based Internet = services=E2=80=9D instead? >=20 > 4. Problems=E2=80=A6 >=20 > -- "Reasons might include hardware limitations=E2=80=9D - begs the = inclusion of a forward reference to section 9.3 >=20 >=20 --Apple-Mail=_C46996A7-0A54-4D40-926D-012DA0BCA0D2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVts3EUayAOS/EQ8MAQK2uQ/9F4sC3XT2tGCpkO/PYn8NMWOrsaZJZsmg iHtJEG3hL/XF3rlv9ea3DB2QDNjtIcvBWjtaP5UJaGpucL0ww7VPJwxjpiyn1xIn /uH3mp/LKxXARkcySoE8N8uXAAk/z4xSBComhRfxQjNSbyHeN3LThhgxPWWUcOTg udf1edRlRFyBVEGKzClXxJ+trPjpnxrPqq2PBo7fC0cX53D5R26aMKjKlCyksl9b zVksFnnTrwflWSu1o6EBd3mMBQsQyXDrJVjh88EeQ7e2CWVua0cTbmvXZ3o/xihF vuQ7qinoJZBVa4dwXSlPOYbfEd+C4ijDVPsqHQvoSg4sdr+n78zcqkkjmW4NXmOg JJ2jMynnnrb4Y1bABxGHrC7JA+/bsLYzqAvlOuzE4FsF/F90d2m2+PNnigg8ttN2 a89IDV8ekzesWN/SeGp3ZG/TaLUhplqjp6fRoL3EOYWyZSMd7NDJqlDn6Gv+qVK9 6RntY6hUrDsD4xfbLgWBoE4/iFHuLi0tuHlO2wOYY9vo251czWkwHsQqjWpSlrGr Wr4UYtRbk9bOmCVRprpBqrTWQOuV8+gvCA7gREQ+Q6pkUYByHRmQ1ylZePDXWn1p yq+WdNmC0yXV4JPUm23QdLFwGsgOtBG6/AzDfLUduE2D6nAF6RUHQaV1SqVbYO8m ouek+0xbNR8= =3Vvz -----END PGP SIGNATURE----- --Apple-Mail=_C46996A7-0A54-4D40-926D-012DA0BCA0D2-- From nobody Sun Mar 6 21:24:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CDC1A8FD6 for ; Sun, 6 Mar 2016 21:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFmWXkalFK2U for ; Sun, 6 Mar 2016 21:24:11 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280641A8FD4 for ; Sun, 6 Mar 2016 21:24:11 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id h197so24133685yke.2 for ; Sun, 06 Mar 2016 21:24:11 -0800 (PST) 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; bh=LlYY6nY2li1isgRo6OwfluKhoWtrN9ReN8MKjzzllgk=; b=iyp63eXX7ZjyXcjRi8WxHRoz6CFz9K89qOSJpvx7miFVF1F8hghaJAPp4/YTuL/MSR FRhCaWBaAoJpKImlSnL3QQjcuIPBZI5JTNTf5prbK0kIH/RE/lviN6hdgHH9E6qj/sWj NqwkUzh4M7+COm3ly78uB7IZP4D8HhGMaMxm6LDec0zIXqJnR5PBLK1btlz/Vwb2uvVw ++UzEZqnr0Cj4tqXzbJz5ad5tFi3IiwxbPRC7UHrfbP2a7YKmFGyODKZsGWojg2qDzvc r6EPD6Uzl69RigACNhcY9+VTORRK0LW+HUxIAeXMKhiwj5wnbCQjk/tIrkWac415fa+x bsRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LlYY6nY2li1isgRo6OwfluKhoWtrN9ReN8MKjzzllgk=; b=R0Qfx9G+e/yA64frkMEHHQMzRjKKLMqylO+egU3MZNeG1hzTGB6qzfw9HPF2OOpvLH YxtqOdAfD337jd0A0DlVNhzMZuSXLb1cNZSEpByxrVfQ237bgJeKlLV1KSWqdecvmR3g rkWxjnuqJVjR//bI6TneMjZsGYG8JhJbYfj6AdZDPQEJTNr0pE+dO87SbwFqm4e0ll44 nYBL7SEU5/UYPjdhsrSk9Ew6jbYHVlbKREYE9Se9Sv2oszZfHwspGR6Mwk1FDVRltPqO 35GmNKoy1kaatq2/Up047rJcVxcIrRa2j5jsGL3Z1FYWuYM+KcMokDkKwa5PjmgQXesi G2tg== X-Gm-Message-State: AD7BkJK9BWNqu9AJoEBtIyKUHUglC+Xd5zegG7L5LAXSBn8kmga+dfYZwTXVEjXzgqRErfZwSbUAwGjVEzxU/+xo X-Received: by 10.37.13.83 with SMTP id 80mr11563188ybn.49.1457328250140; Sun, 06 Mar 2016 21:24:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.19.65 with HTTP; Sun, 6 Mar 2016 21:23:50 -0800 (PST) In-Reply-To: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> References: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> From: Lorenzo Colitti Date: Mon, 7 Mar 2016 14:23:50 +0900 Message-ID: To: Geoff Huston Content-Type: multipart/alternative; boundary=001a11c06ad8ac3a34052d6eaccb Archived-At: Cc: rtg-dir@ietf.org, "v6ops@ietf.org WG" , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 05:24:13 -0000 --001a11c06ad8ac3a34052d6eaccb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 3, 2016 at 2:54 PM, Geoff Huston wrote: > Other advocate the adoption of operational practices that may not be in > widespread use at present. It appears that this document falls into the > latter category as it exposes that network operators provide a IPv6 servi= ce > that admits the provision of multiple addresses at connection time. > I think an important point to note is that the vast majority of IPv6 networks (certainly in terms of number of devices) already does this. This is stated pretty clearly in section 2: In most general-purpose IPv6 networks, including all 3GPP networks ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC [RFC4862], IPv6 hosts have the ability to configure additional IPv6 addresses from the link prefix(es) without explicit requests to the network. The main goal of this document is to observe that the majority of IPv6 use is on devices that *do* have access to multiple addresses, and that this provides many benefits, and to recommend that networks provide multiple addresses regardless of what address provisioning methodology is in use. 1. The Security Considerations section is empty, while the document > explicitly discusses issues relating to the operational integrity of > networks that has an impact on the security of the service. > > I find it rather anomalous that section 9.3 describes a potential > scenario that would impact the operational integrity of a network, yet th= e > Security Considerations says =E2=80=9CNone so far.=E2=80=9D As an absolut= e minimum it would > be reasonable to this reviewer to have the Security Considerations sectio= n > reference the considerations described in Section 9.3 as a potential sour= ce > of operational instability under certain circumstances. (While it is not > part of a routing-related review I also note that Section 9.1 talks about > security issues as well) > How about this? =3D=3D=3D=3D As mentioned in section 9.3, on shared networks using SLAAC it is possible for devices to attempt to exhaust network resources and possibly deny service to other devices by creating unreasonable numbers (e.g., hundreds or thousands) of addresses. Networks that provide access to untrusted devices can mitigate this threat by providing a dedicated /64 prefix per device. It is also possible to mitigate the threat by limiting the number of ND cache entries that can be created for a particular device, but care must be taken to ensure that the network does not restrict the IP addresses available to non-malicious devices. Security issues related to host tracking are discussed in section 9.1. =3D=3D=3D=3D > 2. The Recommendations section could include consideration of routing > / cache scaling. > > The recommendations in Section 8 do not include some recommendations > related to the management of MAC to IPv6 address bindings, and indeed on > the nature of these provisioned multiple addresses. I was expecting to se= e > either some level of admonition of a practice of "chequerboarding" the > address space, where multiple hosts on a network are provisioned with > discrete /128 addresses, or a particular recommendation relating to the u= se > of prefix delegation as this allows more efficient forms of MAC to addres= s > binding, and limits the level of propagation of individual host routes in > the network > The current text on DHCPv6 PD is a compromise. Previous versions contained stronger language in support of DHCPv6 PD, but a small number of WG participants felt that it was not acceptable to recommend DHCPv6 PD in a BCP document because of the lack of widespread support in current host operating systems. The draft already makes these scaling recommendations in section 9.3, though. Is that not sufficient? Nits: > > 1. Introduction: > -- =E2=80=9Cvirtually unlimited amount of address space=E2=80=9D is = a very imprecise > term, and historically its been proved wrong when claimed for other large > spaces. Could the authors think of another term that avoids any use of th= e > word =E2=80=9Cunlimited=E2=80=9D? > > -- =E2=80=9Cfuture applications=E2=80=9D is not a benefit per se, at= least not > grammatically correct one. =E2=80=9Cflexibility to accommodate future app= lications=E2=80=99 > needs=E2=80=9D might be closer to what the author intended. > > -- =E2=80=9Cthe ability to deploy the Internet=E2=80=9D - surely thi= s is about =E2=80=9Cthe > ability to deploy IPv6-based Internet services=E2=80=9D instead? > > 4. Problems=E2=80=A6 > > -- "Reasons might include hardware limitations=E2=80=9D - begs the i= nclusion > of a forward reference to section 9.3 > I've tried to address these in the next version. Cheers, Lorenzo --001a11c06ad8ac3a34052d6eaccb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 3, 2016 at 2:54 PM, Geoff Huston <gih@apnic.net> wrote:<= br>
Other advocate the adoption of operational practices th= at may not be in widespread use at present. It appears that this document f= alls into the latter category as it exposes that network operators provide = a IPv6 service that admits the provision of multiple addresses at connectio= n time.

I think an important point to n= ote is that the vast majority of IPv6 networks (certainly in terms of numbe= r of devices) already does this. This is stated pretty clearly in section 2= :

=C2=A0 =C2=A0In most general-purpose IPv6 n= etworks, including all 3GPP networks
=C2=A0 =C2=A0([RFC6459] sect= ion 5.2) and Ethernet and Wi-Fi networks using SLAAC
=C2=A0 =C2= =A0[RFC4862], IPv6 hosts have the ability to configure additional IPv6
=C2=A0 =C2=A0addresses from the link prefix(es) without explicit requ= ests to the
=C2=A0 =C2=A0network.

= The main goal of this document is to observe that the majority of IPv6 use = is on devices that *do* have access to multiple addresses, and that this pr= ovides many benefits, and to recommend that networks provide multiple addre= sses regardless of what address provisioning methodology is in use.

=C2=A0 =C2=A0 1. The Security Considerations = section is empty, while the document explicitly discusses issues relating t= o the operational integrity of networks that has an impact on the security = of the service.

=C2=A0 =C2=A0 I find it rather anomalous that section 9.3 describes a poten= tial scenario that would impact the operational integrity of a network, yet= the Security Considerations says =E2=80=9CNone so far.=E2=80=9D As an abso= lute minimum it would be reasonable to this reviewer to have the Security C= onsiderations section reference the considerations described in Section 9.3= as a potential source of operational instability under certain circumstanc= es. (While it is not part of a routing-related review I also note that Sect= ion 9.1 talks about security issues as well)

How about this?

=3D=3D=3D=3D
As me= ntioned in section 9.3, on shared networks using SLAAC it is possible for d= evices to attempt to exhaust network resources and possibly deny service to= other devices by creating unreasonable numbers (e.g., hundreds or thousand= s) of addresses. Networks that provide access to untrusted devices can miti= gate this threat by providing a dedicated /64 prefix per device. It is also= possible to mitigate the threat by limiting the number of ND cache entries= that can be created for a particular device, but care must be taken to ens= ure that the network does not restrict the IP addresses available to non-ma= licious devices.

Security issues related to host t= racking are discussed in section 9.1.
=3D=3D=3D=3D
=C2= =A0
=C2=A0 =C2=A0 2. The Recommendations section could include consideration of= routing / cache scaling.

=C2=A0 =C2=A0 The recommendations in Section 8 do not include some recommen= dations related to the management of MAC to IPv6 address bindings, and inde= ed on the nature of these provisioned multiple addresses. I was expecting t= o see either some level of admonition of a practice of "chequerboardin= g" the address space, where multiple hosts on a network are provisione= d with discrete /128 addresses, or a particular recommendation relating to = the use of prefix delegation as this allows more efficient forms of MAC to = address binding, and limits the level of propagation of individual host rou= tes in the network

The current text on = DHCPv6 PD is a compromise. Previous versions contained stronger language in= support of DHCPv6 PD, but a small number of WG participants felt that it w= as not acceptable to recommend DHCPv6 PD in a BCP document because of the l= ack of widespread support in current host operating systems. The draft alre= ady makes these scaling recommendations in section 9.3, though. Is that not= sufficient?

Nits:

=C2=A0 =C2=A0 1. Introduction:
=C2=A0 =C2=A0 --=C2=A0 =E2=80=9Cvirtually unlimited amount of address space= =E2=80=9D is a very imprecise term, and historically its been proved wrong = when claimed for other large spaces. Could the authors think of another ter= m that avoids any use of the word =E2=80=9Cunlimited=E2=80=9D?

=C2=A0 =C2=A0 --=C2=A0 =E2=80=9Cfuture applications=E2=80=9D is not a benef= it per se, at least not grammatically correct one. =E2=80=9Cflexibility to = accommodate future applications=E2=80=99 needs=E2=80=9D might be closer to = what the author intended.

=C2=A0 =C2=A0 --=C2=A0 =E2=80=9Cthe ability to deploy the Internet=E2=80=9D= - surely this is about =E2=80=9Cthe ability to deploy IPv6-based Internet = services=E2=80=9D instead?

=C2=A0 =C2=A04. Problems=E2=80=A6

=C2=A0 =C2=A0 --=C2=A0 "Reasons might include hardware limitations=E2= =80=9D - begs the inclusion of a forward reference to section 9.3

I've tried to address these in the next vers= ion.

Cheers,
Lorenzo
--001a11c06ad8ac3a34052d6eaccb-- From nobody Mon Mar 7 00:04:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12B71B36F3 for ; Mon, 7 Mar 2016 00:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkQza-Evd7Q5 for ; Mon, 7 Mar 2016 00:04:15 -0800 (PST) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725911B36F1 for ; Mon, 7 Mar 2016 00:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=u70/GWu+8ZXGb7CrVPi69bWiLnrbHEN8Rp2F1ZDGmJs=; b=YdRtL8BFFwqSCSW3aM52bCpE5rvDZTEJrioaFPCuredx5iX+rniwj44bOSePAYrkk+Gr/IM9Hn5xA yctjCfZyse15qMbIcLQQfo0SOk3/ytBvWo3j5850sFivVqr2PL1Z+2UUwBIRQDJf5gvbAtT/AlwE3Q XRE16pSR67ODXj5A= Received: from iamda3.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Mon, 7 Mar 2016 18:04:17 +1000 (AEST) Received: from [192.168.1.189] (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Mar 2016 18:01:04 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Geoff Huston In-Reply-To: Date: Mon, 7 Mar 2016 18:59:10 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <971F196C-0A1E-4B17-ADC3-B3BD41DE3B78@apnic.net> References: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3112) Archived-At: Cc: rtg-dir@ietf.org, "v6ops@ietf.org WG" , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 08:04:17 -0000 > On 7 Mar 2016, at 4:23 PM, Lorenzo Colitti wrote: >=20 > On Thu, Mar 3, 2016 at 2:54 PM, Geoff Huston wrote: > Other advocate the adoption of operational practices that may not be = in widespread use at present. It appears that this document falls into = the latter category as it exposes that network operators provide a IPv6 = service that admits the provision of multiple addresses at connection = time. >=20 > I think an important point to note is that the vast majority of IPv6 = networks (certainly in terms of number of devices) already does this. = This is stated pretty clearly in section 2: >=20 > In most general-purpose IPv6 networks, including all 3GPP networks > ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC > [RFC4862], IPv6 hosts have the ability to configure additional IPv6 > addresses from the link prefix(es) without explicit requests to the > network. >=20 > The main goal of this document is to observe that the majority of IPv6 = use is on devices that *do* have access to multiple addresses, and that = this provides many benefits, and to recommend that networks provide = multiple addresses regardless of what address provisioning methodology = is in use. ** This was a general comment on my part - no changes in the text was = proposed, so I accept your observation. >=20 > 1. The Security Considerations section is empty, while the = document explicitly discusses issues relating to the operational = integrity of networks that has an impact on the security of the service. >=20 > I find it rather anomalous that section 9.3 describes a potential = scenario that would impact the operational integrity of a network, yet = the Security Considerations says =E2=80=9CNone so far.=E2=80=9D As an = absolute minimum it would be reasonable to this reviewer to have the = Security Considerations section reference the considerations described = in Section 9.3 as a potential source of operational instability under = certain circumstances. (While it is not part of a routing-related review = I also note that Section 9.1 talks about security issues as well) >=20 > How about this? >=20 > =3D=3D=3D=3D > As mentioned in section 9.3, on shared networks using SLAAC it is = possible for devices to attempt to exhaust network resources and = possibly deny service to other devices by creating unreasonable numbers = (e.g., hundreds or thousands) of addresses. Networks that provide access = to untrusted devices can mitigate this threat by providing a dedicated = /64 prefix per device. It is also possible to mitigate the threat by = limiting the number of ND cache entries that can be created for a = particular device, but care must be taken to ensure that the network = does not restrict the IP addresses available to non-malicious devices. >=20 > Security issues related to host tracking are discussed in section 9.1. > =3D=3D=3D=3D ** Yes, I agree with this proposed text for the Security Considerations = section. > =20 > 2. The Recommendations section could include consideration of = routing / cache scaling. >=20 > The recommendations in Section 8 do not include some = recommendations related to the management of MAC to IPv6 address = bindings, and indeed on the nature of these provisioned multiple = addresses. I was expecting to see either some level of admonition of a = practice of "chequerboarding" the address space, where multiple hosts on = a network are provisioned with discrete /128 addresses, or a particular = recommendation relating to the use of prefix delegation as this allows = more efficient forms of MAC to address binding, and limits the level of = propagation of individual host routes in the network >=20 > The current text on DHCPv6 PD is a compromise. Previous versions = contained stronger language in support of DHCPv6 PD, but a small number = of WG participants felt that it was not acceptable to recommend DHCPv6 = PD in a BCP document because of the lack of widespread support in = current host operating systems. The draft already makes these scaling = recommendations in section 9.3, though. Is that not sufficient? >=20 ** perhaps you may instead want to add the advice as a final sentence to = the third paragraph: "For these reasons the use DHCPv6 PD, where available, represents a more = operationally prudent approach.=E2=80=9D Which does not contain an explicit recommendation, but does state a = preference with associated justification. > Nits: >=20 > 1. Introduction: > -- =E2=80=9Cvirtually unlimited amount of address space=E2=80=9D = is a very imprecise term, and historically its been proved wrong when = claimed for other large spaces. Could the authors think of another term = that avoids any use of the word =E2=80=9Cunlimited=E2=80=9D? >=20 > -- =E2=80=9Cfuture applications=E2=80=9D is not a benefit per se, = at least not grammatically correct one. =E2=80=9Cflexibility to = accommodate future applications=E2=80=99 needs=E2=80=9D might be closer = to what the author intended. >=20 > -- =E2=80=9Cthe ability to deploy the Internet=E2=80=9D - surely = this is about =E2=80=9Cthe ability to deploy IPv6-based Internet = services=E2=80=9D instead? >=20 > 4. Problems=E2=80=A6 >=20 > -- "Reasons might include hardware limitations=E2=80=9D - begs = the inclusion of a forward reference to section 9.3 >=20 > I've tried to address these in the next version. ** Great, thanks Lorenzo. regards, Geoff From nobody Wed Mar 9 06:00:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2223512D695 for ; Wed, 9 Mar 2016 06:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR9xTqUGm-9u for ; Wed, 9 Mar 2016 06:00:10 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B75212D641 for ; Wed, 9 Mar 2016 06:00:09 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id h129so40058734ywb.1 for ; Wed, 09 Mar 2016 06:00:09 -0800 (PST) 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; bh=Qaj2oT9YkX7pPazE0vCqLxhvl1Y35ve6m6jUVDhGb9I=; b=RXR7g5GuftH8zxFYv3NiUCWxuO5qViKxSzh38I290pGwli5RDqJOB4+ny9pl/GlSVe 5ug1BhmYjF3zCGdPIEryTeByDXW+UwP4NthV1e6Md1SIC158G7fdPJDGg0H3pMdtfTQj aDiylx9WLA7R8nkNjt0auHTCAjEGd2G8ci5hK/v2LCP+ynke4H8qL18ssdtWFWIBgSEf 8OxMMKurq22SLE+ptKT2fPcPlqSzyVKLas+yrw3yF9kjyuz7csZyk5Z9Wu5vfLebz/TP 8rKM4nEWbOtqCs+NRmOIBhlqvE8k3v3qL2o7Bl/o5HyhBO0ZM5V9ombErzDVgHB1atXJ OCrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qaj2oT9YkX7pPazE0vCqLxhvl1Y35ve6m6jUVDhGb9I=; b=OQtkWvY1XheOaMY1SSv+bgPibEALJF+h9WHm0biWPQUOke2a/dYWVhSsdhtRM8Vmng GaRCcNfsiCWucR/5eKCn1KZKDc5wb1yiHvb2dUYyTF6XhBwduOZZcncrOlQhpp3G+10P +KX3r2a1vkjGT9t65tFZ9Ema5i1nPve4qzba5ztzX7VH+4v5DfiE5oHCEdgMaCkEjqHC ebqUbzEtmEprpl1UH7T2jjgIPriwN1Li9ue573QCLDAKhgDSWsSOqucDpD4+9qLyGoSW Ho3lDe9KjoMyHp9ZIT8tnntcTxSxl+0nMdJf/W+8RTF087Dk7sa1zunJ4QOK50pBtBpY bThg== X-Gm-Message-State: AD7BkJKQS7siYT3KxwigttwaOa+bhvTpHq/fAjDVOvQJBJFXreE41euMaHdfwM9tFVaGj4NKbcjeUx4ppzMdKs1F X-Received: by 10.13.212.204 with SMTP id w195mr758101ywd.156.1457532008592; Wed, 09 Mar 2016 06:00:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.19.65 with HTTP; Wed, 9 Mar 2016 05:59:48 -0800 (PST) In-Reply-To: <971F196C-0A1E-4B17-ADC3-B3BD41DE3B78@apnic.net> References: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> <971F196C-0A1E-4B17-ADC3-B3BD41DE3B78@apnic.net> From: Lorenzo Colitti Date: Wed, 9 Mar 2016 22:59:48 +0900 Message-ID: To: Geoff Huston Content-Type: multipart/alternative; boundary=001a114fbd389f82c4052d9e1d0d Archived-At: Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 14:00:17 -0000 --001a114fbd389f82c4052d9e1d0d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Geoff, I've teed up the other fixes for review by my coauthors, but I have a question about this one. > 2. The Recommendations section could include consideration of routing > / cache scaling. > > > > The recommendations in Section 8 do not include some recommendation= s > related to the management of MAC to IPv6 address bindings, and indeed on > the nature of these provisioned multiple addresses. I was expecting to se= e > either some level of admonition of a practice of "chequerboarding" the > address space, where multiple hosts on a network are provisioned with > discrete /128 addresses, or a particular recommendation relating to the u= se > of prefix delegation as this allows more efficient forms of MAC to addres= s > binding, and limits the level of propagation of individual host routes in > the network > > > > The current text on DHCPv6 PD is a compromise. Previous versions > contained stronger language in support of DHCPv6 PD, but a small number o= f > WG participants felt that it was not acceptable to recommend DHCPv6 PD in= a > BCP document because of the lack of widespread support in current host > operating systems. The draft already makes these scaling recommendations = in > section 9.3, though. Is that not sufficient? > > > > > ** perhaps you may instead want to add the advice as a final sentence to > the third paragraph: > > "For these reasons the use DHCPv6 PD, where available, represents a more > operationally prudent approach.=E2=80=9D > > Which does not contain an explicit recommendation, but does state a > preference with associated justification. > Where do you suggest we put this text? At the end of section 8 or at the end of section 9.3? (They both have three paragraphs). I'm leery of using the exact words "operationally prudent" because there was a vocal minority in the WG that maintained that DHCPv6 PD is not known to be operationally feasible due to lack of deployment. However, it's indisputable that DHCPv6 PD suffers from none of the ND cache scaling problems that affect shared links, so we could definitely make that statement. It also might be worth mentioning that, on networks where the client is uniquely identified by its MAC address, such as 802.11 networks in infrastructure mode, SLAAC with a dedicated prefix has the same attractive scaling properties. Cheers, Lorenzo --001a114fbd389f82c4052d9e1d0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Geoff,

I've teed up the other fixes= for review by my coauthors, but I have a question about this one.

>=C2=A0 =C2=A0 =C2=A02. The Recommendations sectio= n could include consideration of routing / cache scaling.
>
>=C2=A0 =C2=A0 =C2=A0The recommendations in Section 8 do not include som= e recommendations related to the management of MAC to IPv6 address bindings= , and indeed on the nature of these provisioned multiple addresses. I was e= xpecting to see either some level of admonition of a practice of "cheq= uerboarding" the address space, where multiple hosts on a network are = provisioned with discrete /128 addresses, or a particular recommendation re= lating to the use of prefix delegation as this allows more efficient forms = of MAC to address binding, and limits the level of propagation of individua= l host routes in the network
>
> The current text on DHCPv6 PD is a compromise. Previous versions conta= ined stronger language in support of DHCPv6 PD, but a small number of WG pa= rticipants felt that it was not acceptable to recommend DHCPv6 PD in a BCP = document because of the lack of widespread support in current host operatin= g systems. The draft already makes these scaling recommendations in section= 9.3, though. Is that not sufficient?
>


** perhaps you may instead want to add the advice as a final sentenc= e to the third paragraph:

"For these reasons the use DHCPv6 PD, where available, represents a mo= re operationally prudent approach.=E2=80=9D

Which does not contain an explicit recommendation, but does state a prefere= nce with associated justification.

Wher= e do you suggest we put this text? At the end of section 8 or at the end of= section 9.3? (They both have three paragraphs).

I= 'm leery of using the exact words "operationally prudent" bec= ause there was a vocal minority in the WG that maintained that DHCPv6 PD is= not known to be operationally feasible due to lack of deployment. However,= it's indisputable that DHCPv6 PD suffers from none of the ND cache sca= ling problems that affect shared links, so we could definitely make that st= atement. It also might be worth mentioning that, on networks where the clie= nt is uniquely identified by its MAC address, such as 802.11 networks in in= frastructure mode, SLAAC with a dedicated prefix has the same attractive sc= aling properties.

Cheers,
Lorenzo
<= /div>
--001a114fbd389f82c4052d9e1d0d-- From nobody Wed Mar 9 07:50:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8735312DFC4 for ; Wed, 9 Mar 2016 07:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.792 X-Spam-Level: X-Spam-Status: No, score=-106.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=apnic.net Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmNx0H2CIugx for ; Wed, 9 Mar 2016 07:49:28 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668DF12E0E7 for ; Wed, 9 Mar 2016 07:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=oK8D3u8m/MXRnMHV8NRXraTq52BqJNsxArVgPdiqDEQ=; b=g8TjQXPQnqQvGmA2uXC86N2pCncIpBXP01YnZzx4AJh0t5G85MltkbW4WpzIbHdVGpKjgmm8bZJYN 7tZGXywHiQtauXNVs6jgc5t+RSFipU1SsTwbSzBhVde5P1PWvSI56f/msatv8GhHLy0okFYTVAl2xW LNVV0fEeBOYdg828= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Thu, 10 Mar 2016 01:36:28 +1000 (AEST) Received: from [10.196.204.92] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 10 Mar 2016 01:35:36 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Geoff Huston In-Reply-To: Date: Thu, 10 Mar 2016 02:35:46 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> <971F196C-0A1E-4B17-ADC3-B3BD41DE3B78@apnic.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:49:30 -0000 > On 10 Mar 2016, at 12:59 AM, Lorenzo Colitti = wrote: >=20 > Geoff, >=20 > I've teed up the other fixes for review by my coauthors, but I have a = question about this one. >=20 > > 2. The Recommendations section could include consideration of = routing / cache scaling. > > > > The recommendations in Section 8 do not include some = recommendations related to the management of MAC to IPv6 address = bindings, and indeed on the nature of these provisioned multiple = addresses. I was expecting to see either some level of admonition of a = practice of "chequerboarding" the address space, where multiple hosts on = a network are provisioned with discrete /128 addresses, or a particular = recommendation relating to the use of prefix delegation as this allows = more efficient forms of MAC to address binding, and limits the level of = propagation of individual host routes in the network > > > > The current text on DHCPv6 PD is a compromise. Previous versions = contained stronger language in support of DHCPv6 PD, but a small number = of WG participants felt that it was not acceptable to recommend DHCPv6 = PD in a BCP document because of the lack of widespread support in = current host operating systems. The draft already makes these scaling = recommendations in section 9.3, though. Is that not sufficient? > > >=20 >=20 > ** perhaps you may instead want to add the advice as a final sentence = to the third paragraph: >=20 > "For these reasons the use DHCPv6 PD, where available, represents a = more operationally prudent approach.=E2=80=9D >=20 > Which does not contain an explicit recommendation, but does state a = preference with associated justification. >=20 > Where do you suggest we put this text? At the end of section 8 or at = the end of section 9.3? (They both have three paragraphs). I thought at the end of section 9.3 >=20 > I'm leery of using the exact words "operationally prudent" because = there was a vocal minority in the WG that maintained that DHCPv6 PD is = not known to be operationally feasible due to lack of deployment. = However, it's indisputable that DHCPv6 PD suffers from none of the ND = cache scaling problems that affect shared links, so we could definitely = make that statement. It also might be worth mentioning that, on networks = where the client is uniquely identified by its MAC address, such as = 802.11 networks in infrastructure mode, SLAAC with a dedicated prefix = has the same attractive scaling properties. how about: =E2=80=9C=46rom the considerations of ND cache scaling the use of DHCPv6 = PD would represent an operationally prudent approach, as would SLAAC = with a dedicated prefix to be associated with a single MAC addresses = where MAC addresses are used as link layer identifiers.=E2=80=9D would this work? Geoff =20= From nobody Wed Mar 9 18:30:03 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 198EA12DD36; Wed, 9 Mar 2016 18:29:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160310022959.12819.64807.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 18:29:59 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 02:29:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Host address availability recommendations Authors : Lorenzo Colitti Vint Cerf Stuart Cheshire David Schinazi Filename : draft-ietf-v6ops-host-addr-availability-06.txt Pages : 14 Date : 2016-03-09 Abstract: This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 9 18:37:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CED12DD3B for ; Wed, 9 Mar 2016 18:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3Dd2qS1hjkG for ; Wed, 9 Mar 2016 18:37:21 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDDA12DD36 for ; Wed, 9 Mar 2016 18:37:21 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id y66so29591313ykd.2 for ; Wed, 09 Mar 2016 18:37:21 -0800 (PST) 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; bh=tl4O3N4kEusZMupigj6IDMzzO7hidaSKc9rFWbCfHaI=; b=pFN4JnX6uw5gFHumw2uQKlBhTiqMtFnCVJivAVyGHZ1Ji+OwRg7t7XaSToNSEVhkeA 0rGv2sih6z+jG5kZgFHUJgnPBIN2tzYi3udLxCE7Gynul/3hRfzvC6Fui5LkHhLf/6wL HuESFSJUJgTybouAuQIEL5RPIAhiqw71qugZQVxFRBYnfC3InJcxDxMG7gFbiOGNdi14 wAAxfapIxLP1fDPIziJsLUToDBCxNStLPWizmTI6cwAxC5L8GNSLNEzBXhotoNTU+2wk LTxKgBo1W9pyCGTDF9vlQQOKwibcd052hNv9pXNpjI7xP+8HpXXncAmpLyVpKTHGctCh SsLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tl4O3N4kEusZMupigj6IDMzzO7hidaSKc9rFWbCfHaI=; b=DrI/FaZ5e1wus+3JQgdJxw6NRtcKglr09phSVxa4yOnAXHbuKWnYk9yu8/BzIxbJ0l dy1b97IG/JBr4/HZxgNYLUqm56s605UqW7hZ7uojgrqJY9Mhtzdyus0iiA+xADzCgkaE e+apryA4JBbDSFtiD5gIlGtS3S891K+Ij4l6y82irEC5xIG/wVR0PADS4xb3+H5WK4vm oYr0FihcYcilS+d8F8MLYIocMLzaZ0fxK4JXwQYuh+lDPmq0UAUyxGD4422rQxb9VK6X ZFO9yUFw6AoKJ6FVNtXqF2X37FzjWd2Lhrj0PqWNu0S8ILJdXue3p5kHIK7Yfh95E8OE vfGQ== X-Gm-Message-State: AD7BkJKlJ0TOZ1p6PriiFZlIc/NX/IFf0GebyuFwE1KfXsNFogqpvG5Sl5S9Xcjae3R6IHM7tEqU/nSpBuFXevcG X-Received: by 10.37.2.204 with SMTP id 195mr583160ybc.44.1457577440740; Wed, 09 Mar 2016 18:37:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.19.65 with HTTP; Wed, 9 Mar 2016 18:37:01 -0800 (PST) In-Reply-To: <20160310022959.12819.64807.idtracker@ietfa.amsl.com> References: <20160310022959.12819.64807.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 10 Mar 2016 11:37:01 +0900 Message-ID: To: internet-drafts Content-Type: multipart/alternative; boundary=001a113d477a970841052da8b1c6 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 02:37:24 -0000 --001a113d477a970841052da8b1c6 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2016 at 11:29 AM, wrote: > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-06 This version addresses the comments made in IETF last call. This includes the comments raised in the Routing Directorate and Ops Directorate reviews, and some of the comments made by Fred Templin. --001a113d477a970841052da8b1c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 10, 2016 at 11:29 AM, <internet-drafts@ietf.org> wrote:
A diff from the previous version is availab= le at:
https://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-v6ops-host-addr-availability-06

This version addresses the comments made in IETF last cal= l. This includes the comments raised in the Routing Directorate and Ops Dir= ectorate reviews, and some of the comments made by Fred Templin.
--001a113d477a970841052da8b1c6-- From nobody Wed Mar 9 18:38:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D45712DAE4 for ; Wed, 9 Mar 2016 18:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S68WYkm6nyZ7 for ; Wed, 9 Mar 2016 18:38:36 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D99612DD36 for ; Wed, 9 Mar 2016 18:38:36 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id g127so56801252ywf.2 for ; Wed, 09 Mar 2016 18:38:36 -0800 (PST) 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; bh=EVqZUWIGhlEhIulROp/SZFLpL+OEY0eArcDIWW/j6g4=; b=Y+IL7O8znVlbxwOGR3vhNK7Ny4FBGYY7562A1EI/QuuZtcJPVIjoc/QBdbm5y1NR5h VFGKfy1c3uW6XeoYGDXsURqT2uOroI7MUVj40eiqVGA56jRtct9S8HsuQdr73texm+wo 1KTe7oyrpTTKymFB1FUseC+cJVqaJ9IDtQwtwR2d38DOP1FnQWUCK9TqD/IDEgL+mAgV hCWo8AlEF9q/UvZV4C+XT04sFgE1SmsCvbSDHg5coX24QWszRFCJgZsDZYUou747zpA9 8dLF9qwsBoOYnjWA/KW8ehIt8L8cGvNcTWbiOaI3ptBQGP11yGE+wgQkCOmt/jPI6VPD UhNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EVqZUWIGhlEhIulROp/SZFLpL+OEY0eArcDIWW/j6g4=; b=AHZJljhZvDHGLlYec8fkFpNWU5mtOeMPsD/N3tAayux+zfd08kjsA/j4YTmfKsnfS0 EInRoptU0BWv1085tXd64//LY6WyIBiogLkH1e3O5+2kiat1MrYz8aQFzecm378DWIMO FHxBwtF0q17apQVn+vFpFxZkFKG3Ty9KrCnBmI2dtbBO0Y5DoR/peYDi17vGxXsIQC5h ouS4zCSfCmbu9XiBZ+xuICVGVPYC4IxdcsS8mZLN0psUuGMWrUFAN+qxe2ZcmknJjviJ ykc0sMJdG4lkUa7RYxzyaR0JTUpDfCOZN4RiceMAYHoZzXoBBevOjtUJZ1qdFmetIJ+S ehDA== X-Gm-Message-State: AD7BkJKBqw/OAdCUqaSr3SuI1fZhMk5yV5Nr8PQLRKxYhU8YLH3wYuT+HiuovC61VMs4SO0bYws+COBHUWwU0KHn X-Received: by 10.13.205.199 with SMTP id p190mr622173ywd.116.1457577515451; Wed, 09 Mar 2016 18:38:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.19.65 with HTTP; Wed, 9 Mar 2016 18:38:15 -0800 (PST) In-Reply-To: References: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> <971F196C-0A1E-4B17-ADC3-B3BD41DE3B78@apnic.net> From: Lorenzo Colitti Date: Thu, 10 Mar 2016 11:38:15 +0900 Message-ID: To: Geoff Huston Content-Type: multipart/alternative; boundary=001a114e5eb60af9b4052da8b6cd Archived-At: Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 02:38:38 -0000 --001a114e5eb60af9b4052da8b6cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 10, 2016 at 12:35 AM, Geoff Huston wrote: > =E2=80=9CFrom the considerations of ND cache scaling the use of DHCPv6 PD= would > represent an operationally prudent approach, as would SLAAC with a > dedicated prefix to be associated with a single MAC addresses where MAC > addresses are used as link layer identifiers.=E2=80=9D > > would this work? > We added text along these lines to -06, which we just uploaded and which I believe addresses all the substantive comments in this thread. --001a114e5eb60af9b4052da8b6cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 10, 2016 at 12:35 AM, Geoff Huston <gih@apnic.net> wrote= :
=E2=80=9CFrom the considerations of ND = cache scaling the use of DHCPv6 PD would represent an operationally prudent= approach, as would SLAAC with a dedicated prefix to be associated with a s= ingle MAC addresses where MAC addresses are used as link layer identifiers.= =E2=80=9D

would this work?

We added text along these lines t= o -06, which we just uploaded and which I believe addresses all the substan= tive comments in this thread.
--001a114e5eb60af9b4052da8b6cd-- From nobody Wed Mar 9 21:15:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C209A12D674 for ; Wed, 9 Mar 2016 21:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.792 X-Spam-Level: X-Spam-Status: No, score=-106.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWc5ACV2hxy6 for ; Wed, 9 Mar 2016 21:15:50 -0800 (PST) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FB912D542 for ; Wed, 9 Mar 2016 21:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=BXys0rCbKYxu07ybJUPhblX2dWHgNgXzDoHzGSYtaNo=; b=Dyr/EIWp/cb8HuToYg8F3Fvl8XRbVZpG5M6VB38DXuwlrPGRFzsMWY/JEVZMVR5EszySuM7zcmjr+ rg1cuaS68GZGp0iBrDdaHch21WvswKJcrBDOIK75o8yxqyRS/TUTwizznKTu2RPV9jc8VSrhoN9/6K iV4r2dGzq9raUdUk= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Thu, 10 Mar 2016 15:16:08 +1000 (AEST) Received: from [192.168.1.189] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 10 Mar 2016 15:15:27 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Geoff Huston In-Reply-To: Date: Thu, 10 Mar 2016 16:15:35 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <967EBC08-F004-4240-92CE-20B24E0C187D@apnic.net> <971F196C-0A1E-4B17-ADC3-B3BD41DE3B78@apnic.net> To: Lorenzo Colitti , X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: Re: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 05:15:52 -0000 All, I have reviewed version -06 of this draft and I believe that it fully = addresses all of the points I raised in my original review - my thanks = to the authors for their careful attention to the review comments. regards, Geoff =20= From nobody Fri Mar 11 02:01:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F3112DCA4 for ; Fri, 11 Mar 2016 02:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.521 X-Spam-Level: X-Spam-Status: No, score=-114.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 326LzkZ--_NF for ; Fri, 11 Mar 2016 02:01:48 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789E812DF43 for ; Fri, 11 Mar 2016 02:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1656; q=dns/txt; s=iport; t=1457690496; x=1458900096; h=from:to:subject:date:message-id:mime-version; bh=padc0UibD6nmZ6iuUSGsPajxM2ZT40PjejuPz4ELcqs=; b=MV2c+1LIzyPROGpxYdovnYQAUg6MQGTKggTwBt/Jvo7eNoOuoVBIpEHM S8gxVpqiWdDo8d1AWgJ2+1O/XK/XEc+dkV/ZVvMLQAOsGdF6tnpsW1v8H W4+hWC3zALjYCiZoAwK5RuNJ/dnjgH2u9JU0dIpABt0KIP5gEjsHJa1gO I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAwAxl+JW/5xdJa1egz5SbQa6JQ6Bb?= =?us-ascii?q?SOHFjgUAQEBAQEBAWQcC4RIgQsBgQAnBCGIFg6eWJ56AQEBAQEBBAEBAQEBAQE?= =?us-ascii?q?BAQ8EBIgLijSBDwWXQwGDGYFmbYgPgU4BjTOOcAEeAUODZGoBiVJ+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,320,1454976000"; d="asc'?scan'208";a="248029252" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2016 10:01:35 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2BA1ZHX001578 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 11 Mar 2016 10:01:35 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 11 Mar 2016 04:01:34 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Fri, 11 Mar 2016 04:01:34 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRe3z+Q4fcOK7gnE6ThSnYTouK0w== Date: Fri, 11 Mar 2016 10:01:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_B55482EA-DA73-4349-828C-5680B8269716"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 10:01:50 -0000 --Apple-Mail=_B55482EA-DA73-4349-828C-5680B8269716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The authors of draft-gont-v6ops-ipv6-ehs-packet-drops would like v6ops = to adopt draft-gont-v6ops-ipv6-ehs-packet-drops as a working group = document. Yes or no? https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03 = https://tools.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-dro= ps-03.txt --Apple-Mail=_B55482EA-DA73-4349-828C-5680B8269716 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVuKXfEayAOS/EQ8MAQLXMRAA2Ih3iraWPU8a0Y1GCN8HIdaZo2y5GRyy WsaQIkjFJd2ABkxrIRiAF6ffeIZSzjscthlKEmvRhF6kPMgN2EGqnS9USamtKjji XNZre//LWhXbk2oXbzHvJ4F7XN/pK+Ck6+Gb5itxxErwrW6eWcbxjkCN5KBiOR7z +ubF0ARuCrj59ZB08w0p5V8As5j9fvjwbkFKyaDsr9cB14c+1korKRYwi2Eby9F0 IfeLnEWVcnRnDwISr96nNe6cB/SyYbIhMMgm8LZtXtrcgdAg8k4Qkyyk7hbB+4xb wJXtHdEmAdGGxlk/e1Ge1XkGKZK9eEdDju7mm5j/myejao/Zs54qAG+LYURoIWV1 Mj7cwel+sFZjW3vXKST3QCMnlUCcorbUBpzpTDzSA0fXLtNcZEhtvMXWd6gOz/1V sN7MyiACbQI6sgf+5z2OXEhUUFSPGXrShhjlhabb0lj1nKC8C/WR5TcLLnf+j0JI Aq9pz/5twtSw9wCONydsSSEpbYj7ws3g+WYmhQJy5qkiEoxxwiYcp8+kNE25ZSMf RPCqz5IiPUuG9/g7mwxIa4879RgkjwR7wlU0JZeUAUZF0788z2PVWgOSMLxjSlnb w1B84XsgqUnv45BKRvZKZsSrKG0DCKFUta3dt/y1x6qa2AW+G9tW+qU/AyeVTch0 0q2yy5NIuKw= =sMUs -----END PGP SIGNATURE----- --Apple-Mail=_B55482EA-DA73-4349-828C-5680B8269716-- From nobody Fri Mar 11 05:02:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3412D68E for ; Fri, 11 Mar 2016 05:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8AVJxNAk4fz for ; Fri, 11 Mar 2016 05:02:11 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7E512D6C7 for ; Fri, 11 Mar 2016 05:01:43 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 01490D7884; Fri, 11 Mar 2016 05:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=awamt9kMk/KJHnTYFmmM/lP5+44=; b= YmgNX35YLLPW9vh7a27KW4iZUdHLNREx3p8Mtgzv74JchUKvUpwXC34HNmFIZUaB a4oK9CdDaQVkuV4i9zh3AdB9mRBPMlxhn9j7Sb+bpRCf0beQK3I+dZDqDQSEGxKE fo0nSpjMahkjNV0ifi+7rB8TAvgiUXaztPacNvr14rE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=KCcOIyvtNE+2aKyBlpw4gf/uIn 9sg6UE5L0b06tgE8DvJLWV/0rFBTBqanXoqblrs6rScvI153qHw/Kb+SWD+XMoPn 8Od789FfLPQ0aWnEaA4s9Bzmk5mCoZDRZUobkGl3m45F3tqsC/Dm/RKQyJ0X7HGC OO1E6fCEWVCjtJG9Q= Received: from h.hanazo.no (unknown [173.38.220.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id C5206D7882; Fri, 11 Mar 2016 05:01:42 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C56221284091; Fri, 11 Mar 2016 14:01:39 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_72B23B2A-B448-4808-8800-1C8BFD1A33D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Fri, 11 Mar 2016 14:01:38 +0100 Message-Id: References: To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 13:02:18 -0000 --Apple-Mail=_72B23B2A-B448-4808-8800-1C8BFD1A33D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The authors of draft-gont-v6ops-ipv6-ehs-packet-drops would like v6ops = to adopt draft-gont-v6ops-ipv6-ehs-packet-drops as a working group = document. Yes or no? No. Abstract: "This document summarizes the security and operational implications = of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet." The reasons why packets are dropped, and the security / operational = implications is already covered in some of the the numerous other = documents on IPv6 EHs. Best regards, Ole --Apple-Mail=_72B23B2A-B448-4808-8800-1C8BFD1A33D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW4sGzAAoJEL7aWKiYQt92VJMP/jHGXLUGWQYORklR/fwR/Zk2 ATThTwcow6yvGgzV4vOfF6bXkn0m4koS4sDZat94ihmFg/AOEr8InXMbufw/wmWi d/vBrYifHKfWZILu+E13NddA44th4QE3e3R33+GqV+cH+PFl6fugP6LAinY8Adhp WNCGVectHDlhzQefsp/grBM+egHRePBj2+KJDGMxlz9hxyGy5EdTbMtVUJ1wv+CM 25tF5k4gooXwhfEB5yv890vSC8eNfOHPV/u7evnDv1x9nwL2QP9QbbV8Kr5KQdOP uuUr6L0x3PZ17SsR8PWEcP2HS3hUNLCepNt01Jp7NiXC0aX29/8W2c0stLj1KyMd Byxt2bJ0geWw/01zFL8DDVdVG7egNaWPq7mJ4m/SU4YYApI3ThkofHOfZoZian1z LygL711Spl81wUOYqn8sGGAf3OUI8ZwYEJNsokeIuQ6MCjBywC2x8cg3WE0PYU/W PoS6u29EIssymN/Vq9wKMsKGur/+3Ow3WEObrhr/IcPv88cX72dB6eAkmINxx4g1 q3eU6joWsYiPQLwNRgK255XEz6TPchLZjKEkh0Wz4WP8nw7i2sBABYoN5moiw15X Zd3SQDv1zqykavpo5gxwOU2dLJXfmWsIJNOawdRYl1zxoIyv/HbZrE8ULoV0ELVq l9tjLZx+UpOr7H8+gxaD =mLob -----END PGP SIGNATURE----- --Apple-Mail=_72B23B2A-B448-4808-8800-1C8BFD1A33D4-- From nobody Fri Mar 11 05:29:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5095B12D6BF for ; Fri, 11 Mar 2016 05:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRpImLsllzrW for ; Fri, 11 Mar 2016 05:29:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947FE12D6A0 for ; Fri, 11 Mar 2016 05:29:53 -0800 (PST) Received: from [10.1.0.18] (dslb-094-217-017-121.094.217.pools.vodafone-ip.de [94.217.17.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A1F41801A9; Fri, 11 Mar 2016 14:29:49 +0100 (CET) To: otroan@employees.org, "Fred Baker (fred)" References: From: Fernando Gont Message-ID: <56E2C847.4000808@si6networks.com> Date: Fri, 11 Mar 2016 10:29:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 13:29:56 -0000 On 03/11/2016 10:01 AM, otroan@employees.org wrote: >> The authors of draft-gont-v6ops-ipv6-ehs-packet-drops would like v6ops to adopt draft-gont-v6ops-ipv6-ehs-packet-drops as a working group document. Yes or no? > > No. > > Abstract: > "This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet." > > The reasons why packets are dropped, and the security / operational implications is already covered in some of the the numerous other documents on IPv6 EHs. Which ones? Specifically, which document covers the stuff that is in the operational considerations section of our document? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Mar 11 10:52:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6821712DA09 for ; Fri, 11 Mar 2016 10:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeUkHK-HK0_Q for ; Fri, 11 Mar 2016 10:52:04 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DC012D6C2 for ; Fri, 11 Mar 2016 10:52:03 -0800 (PST) Received: by mail-pa0-x235.google.com with SMTP id fl4so105703976pad.0 for ; Fri, 11 Mar 2016 10:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=WnAo0NUT8E98XeTLJFFdwrVMCJBU13cfi+D16mUmur0=; b=xqnyNEErsoLdYPJV9QiUt9OscEiRi333crZKlm/ue/Fl5EP7cbfH1+mOKkIb3JjkAY J4jram1h6H1E4MXJUOabpIucsuPX51wirZrqDV1HYFtz3WJbgwQyJxcJjtDafEaRFgfj pVYz30I1950n0Wl3cwna9BGp5W8AlxIsw/u0getytdMDw5O6YaZ6z9qHe0KEbKepbzDL YqDv0yRLICSba5x0oQuvJtV+OzQLWy22ASj/7YTRjB7byPz5kpCrFIS2U3Tcdz+boCOG PjQJBvCLneoi6qTqAkCL6f/8816QH/EAX4mbokSEZJ91dMEP3dN0RfMkHMN5FzXdB/rb oKNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=WnAo0NUT8E98XeTLJFFdwrVMCJBU13cfi+D16mUmur0=; b=KmHCV8rAdlEq3AostpyLaO3j1aHbmRCEsbEHaGQF6Yxh9YATZsZ3lpTmQsCu916/tX q90MG55bGJWBz2YsBwoustAHnYWq4MhtJuFnpt+qvAqkNTJJvpBra0WpHFXXNORGUWcx O4r9KGFUxwBDUvuEN3UOGj0F4wa/bAyDSJGHYgLCqRwwdlZs5MunK5ESFNh02l/rFe1H lKyWdqCdrkxpSm1q89sumDuh36vXMuIBZLOFKC+J2WPErDIygcgnYCAxMrXWMLdF9ghv OEodNOO9jyYMBgJqae9NHzjoDnLEaBd800QjKntwrVHKqozc3PS5bZjx/iWWF8HamZOI iixA== X-Gm-Message-State: AD7BkJJTfyl5lu95458mdW0pzGLt8aDcAtFQLH+bXtQEHh7Gtlc36IORHFp/mJKh1VlbQA== X-Received: by 10.66.66.198 with SMTP id h6mr17768121pat.112.1457722323560; Fri, 11 Mar 2016 10:52:03 -0800 (PST) Received: from ?IPv6:2406:e007:5476:1:28cc:dc4c:9703:6781? ([2406:e007:5476:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h85sm14608589pfj.52.2016.03.11.10.52.01 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2016 10:52:02 -0800 (PST) To: v6ops@ietf.org References: <20160311095547.10236.56977.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E313DA.2000008@gmail.com> Date: Sat, 12 Mar 2016 07:52:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160311095547.10236.56977.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 18:52:05 -0000 > Vendors must allow for better granularity in the specification of > filters for IPv6 extension headers, such that filters for specific > EH types and subtypes (e.g. RHT0 vs. RHT2) can be specified > wthout affecting other extension header types/subtypes > unnecessarily (please see Section 4.3). Good. That is what RFC 7045 already requires. Also, draft-gont-6man-ipv6-opt-transmit suggests the same for individual options. Regards Brian From nobody Fri Mar 11 11:13:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F5C12DAA1 for ; Fri, 11 Mar 2016 11:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq8OX2H0-cBR for ; Fri, 11 Mar 2016 11:13:04 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8B212DAB0 for ; Fri, 11 Mar 2016 11:13:04 -0800 (PST) Received: by mail-pa0-x22e.google.com with SMTP id fl4so106207860pad.0 for ; Fri, 11 Mar 2016 11:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YBSAe+gJsjkJgRWG06/T+sALUw8Cu6I6SZnXLPB0XVA=; b=Cupj3EbjkqQRTmMX/8LOe9HT4rkTiN6XtW/3Pr8zdONlTEjsrJbEptZYJQbxeTxm2h VNHQEdnhbu42YHoSs+XEEvU0UxSyuVqU+mO7djo1WdQQvb4zs7eDUD+nqHd1NmOGTZyb Jw952oa+mqKn3O1aNTDokuVBC+wM1eVoSnhBUKcsmCCg+qiFFRvNyBN5vCrj68rySN0+ dJal+y/HEAoSiYqY/cxutILBipA4JKtYOzqR+ZlMAARqPO5hJ3DzJSr/6OKvpJpCT5z2 48Bx7G/0wrjq5OhBrqOz4AtPJnpVjL0dgfa/tGqtSPZmGma4Vm6AayqwJUACSVlDP4g9 KBQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=YBSAe+gJsjkJgRWG06/T+sALUw8Cu6I6SZnXLPB0XVA=; b=eNNukZm3aXeAY4UBcN0aYy/Cc6JyAVAJ4TFTdYXzY2f0N7/X1F06toEdc/Y8cxL5SY zgnUSS6oq0jeR2OWTjkBznePpRVPuhlbqx7vi8N/AWSrxUIiyemc/xP359XMIVT4b6Dp fddj/TzUk18r4EZVnK0ZWM2ONYIgJ2VRUqvvLXM6HDfJ6lOO6t2f2rdLdC/1DO6aH3Cu zweYUWl6Ab57bprsC9nWvRD+iKyX+7+CItFpBxoyumU4gb1bts2GH65z7JMHGk59YeFM rNKjV7u6kpAb0+Q6YRBdBq3Zh41jNREybL9OlFld6yGfAv/CxwVEEGZ1jg9Y82u7PC2n HGCw== X-Gm-Message-State: AD7BkJLErfvp5nMV2QhwSrE1nL+uYAxfeJ2jMrQbkNhDaz6ug6X6JbS+FpTAydW11p67qA== X-Received: by 10.66.246.234 with SMTP id xz10mr18129379pac.49.1457723583950; Fri, 11 Mar 2016 11:13:03 -0800 (PST) Received: from ?IPv6:2406:e007:5476:1:28cc:dc4c:9703:6781? ([2406:e007:5476:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u81sm14705934pfi.15.2016.03.11.11.13.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2016 11:13:03 -0800 (PST) To: otroan@employees.org, "Fred Baker (fred)" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E318C7.5020200@gmail.com> Date: Sat, 12 Mar 2016 08:13:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 19:13:06 -0000 I disagree with Ole. I think there is is useful factual information here that should be published. "Solicit input from network operators and users to identify operational issues with the IPv6 Internet" and "document IPv6 operational experience" are part of the WG charter. The new "Future Work" section is also telling us that we aren't done yet if we want to improve deployability. Brian On 12/03/2016 02:01, otroan@employees.org wrote: >> The authors of draft-gont-v6ops-ipv6-ehs-packet-drops would like v6ops to adopt draft-gont-v6ops-ipv6-ehs-packet-drops as a working group document. Yes or no? > > No. > > Abstract: > "This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet." > > The reasons why packets are dropped, and the security / operational implications is already covered in some of the the numerous other documents on IPv6 EHs. > > Best regards, > Ole > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Mar 11 16:40:40 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0DA12DE0B for ; Fri, 11 Mar 2016 16:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pluribusnetworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld08FMCvsX2z for ; Fri, 11 Mar 2016 16:40:36 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD83612D8F9 for ; Fri, 11 Mar 2016 16:40:36 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id 124so94921502pfg.0 for ; Fri, 11 Mar 2016 16:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pluribusnetworks.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=tHr3u+NW8qzNYAN3oqp0bMuPtRX9zyRRk5F+jlpE1qY=; b=MHeRwjcLy0H7k1Tcpw0a8W6LjkNQbt2c+ZkXpwDpculONHhDkCWcJSIqS8fbQlkPg4 GmcjN2xzt9EYv5FxTXbblIaYtzGWbxh75rGbBn5QWXnMlCrNXSNVocn94eCY5OrJ3tnt 3HFLA/O0KmGkQalduwO/nlyEXZ//85exbiJgs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tHr3u+NW8qzNYAN3oqp0bMuPtRX9zyRRk5F+jlpE1qY=; b=A2dARh3SQW5cQmNFMQ11IyVmECirs3ifqXSpKGh0zy9o7jraNM0/GZ4ZXfzn2V8FEY sFBd4mzWmEjM64ljCi4vajvMOIB41JSzZqD2by673n2cMywWYZT7yZdAbYVEzkUVZ2Lo QdCOfJ05dmxcS4lVgRiopHlcAi7nOxzJ7LcjInfWHUAW4xQWAilJ5xAnBTDoTC+p9bGv Pa9UdKaPWf5IKH8BiMSdzNC9/miTiqgqyaMB+IPJelUZokP8OtFf7i3aFA+xgD9mXgBw t/hSmGi6wCKFt5jSA9lQblgjfElkMwf1RuFEctc+nxNjK/xQz0+RxuFySlMUI/fvwNl/ WhjA== X-Gm-Message-State: AD7BkJJBjgN3DrvIIHGZhCRLHjQ4yFjknxQm4rg/ABHU37wE0tiWshQYROxf9dxh5ldI6GjA X-Received: by 10.98.80.206 with SMTP id g75mr12174986pfj.127.1457743236457; Fri, 11 Mar 2016 16:40:36 -0800 (PST) Received: from Sonums-MacBook-Pro.local (50-203-11-18-static.hfc.comcastbusiness.net. [50.203.11.18]) by smtp.gmail.com with ESMTPSA id v88sm15510086pfa.60.2016.03.11.16.40.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2016 16:40:35 -0800 (PST) To: Brian E Carpenter , v6ops@ietf.org References: <56D7B667.6020009@gmail.com> From: Sonum Mathur Message-ID: <56E36583.606@pluribusnetworks.com> Date: Fri, 11 Mar 2016 16:40:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D7B667.6020009@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 00:40:39 -0000 Hi folks, Have some questions from MLD Snooping switch point of view. If there are no Routers involved, it is Snooping switch responsibility to send MLD Query to keep the groups alive on the switch. What is the correct correct Source IP to use for General Queries ? Is it Src IP all 0 or some link-local Address ? Which host stack would like/accept what Source IP ? Have observed different observations with different host stacks. Also, per discussion below - what is the right behavior for snooping switch when it comes to link-local multicast groups - flood or snoop ? It would be good to have a standard practice for this. Thanks -- Sonum On 3/2/16 7:58 PM, Brian E Carpenter wrote: > Thanks to everyone who replied on and off list. > > I've confirmed with Wireshark that Windows 7 does send appropriate > MLD2 listener reports and I am assured that Linux does so too (but > I'd need to go back in the lab to confirm that personally). So I > guess the switch involved is not processing MLD correctly. Oughta > be a law against it. > > Regards > Brian > > On 03/03/2016 15:44, Stig Venaas wrote: >> Yes, the stack should take care of sending the report. In many cases >> applications don't have the privileges. Also the stack knows the aggregate >> state of all the sockets. Multiple applications could listen to the same >> group, and in response to general queries you also need the aggregate >> state. >> >> Stig >> On Mar 2, 2016 6:29 PM, "Hermin Anggawijaya" >> wrote: >> >>> On Linux, the IPv6 stack will generate MLD report (both unsolicited report >>> and as reply to queries) if a socket is set with IPV6_ADD_MEMBERSHIP or >>> IPV6_JOIN_GROUP for the given IPv6 multicast address. And looks like the >>> Python script should do the job. >>> >>> Having seen an MLD report from a host running the Python script, I would >>> have thought that the >>> LAN switch would make the host (or the switch port the host is connected >>> to) to become a member of the multicast group, and the switch should >>> forward all multicast packets for ff02::114. >>> >>> *If the corresponding multicast packets (ff02::114) are indeed filtered by >>> MLD snooping switch* - despite seeing the membership report sent by the >>> host running the script, then on some switches you could try either >>> (depends on availability of features): >>> >>> 1. disable snooping - but this could make the LAN 'chatty' >>> 2. set the default behaviour for unknown multicast address to flood, then >>> apply a filter on the MLDSnooping module so that it never 'learns' >>> ff02::114, thus keeping ff02::114 as unknown multicast >>> 3. add static MLD snooping entry for ff02::114 and make all the ports in >>> the vlan as a member. >>> 4. add ff02::114 as a 'protocol' address to MLD Snooping so that it is >>> flooded properly to 'router ports' like ff02::6, ff02:6, ff02::9 etc. >>> >>> >>> Kind regards >>> >>> Angga >>> >>> >>> >>> On Thu, Mar 3, 2016 at 10:13 AM, Mark Smith >>> wrote: >>> >>>> On 3 Mar 2016 07:00, "Brian E Carpenter" >>>> wrote: >>>>> I'm sorry to distract the group with a practical question, but I'm a >>>> bit stumped. >>>>> My question is below. >>>>> >>>>> In the thread "Further Mitigating Router ND Cache Exhaustion DoS >>>> Attacks Using Solicited-Node Group Membership (-01)", on >>>>> 24/02/2016 08:07, Brian E Carpenter wrote: >>>>>> On 24/02/2016 07:53, otroan@employees.org wrote: >>>>>>>>> MLD joins for the solicited node multicast address has turned out >>>> to have little practical purpose. I am thinking of going the other way and >>>> stop sending joins for link-local multicast groups. >>>>>>>> Yes. What is the possible use of a link-local "join"? The packets >>>> are just there >>>>>>>> on the link anyway, so "joining" is entirely an internal matter for >>>> each node. >>>>>>>> However, it is the case that some switches are not transparent to >>>> LL multicasts >>>>>>>> to arbitrary addresses. For example in some tests I did recently, >>>> the lab switch >>>>>>>> was transparent to ff02::1 but opaque to ff02::114. >>>>>>> it was presumably snooping on MLD and did forward when it had >>>> received a join for ff02::114? >>>>>> Possibly. I fixed the problem by inserting a dumb bridge that does >>>> what bridges >>>>>> are supposed to do. >>>>>> >>>>>>> the switch designers I've spoken to state that they cannot scale for >>>> the number of multicast groups, in particular solicited node multicast. I >>>> think they often do an exception for ff02::1 and treat that as broadcast. >>>>>> But why not pass all LL multicasts? >>>>>> >>>>>> Anyway, if this is common behaviour by switches it has to be allowed >>>> for. >>>>> Now my practical question. When a host starts listening to a LL >>>> multicast address, >>>>> who or what sends the MLD Listener Report? Is the stack supposed to do >>>> so >>>>> automatically, or does the socket programmer have to do something? RFC >>>> 3810 >>>>> really doesn't answer this question, and Google has been unable to help >>>> me. >>>> My expectation is the stack, and when I wrote the following a number of >>>> years a go, I'm pretty sure I saw the (Linux) stack doing it for LL >>>> multicasts. >>>> >>>> https://github.com/markzzzsmith/replicast >>>> >>>> I think the stack would have to do it unless the application had a MLD >>>> client implementation in it to send periodic reports and to respond to MLD >>>> router queries. >>>> >>>>> A Python fragment is below to show what I am actually doing. This works >>>>> perfectly, but not when the LAN switch is filtering multicasts. >>>>> >>>> Is any sort of active multicast filtering enabled e.g., MLD snooping? >>>> >>>> If not, it reminds me of some ADSL DSLAMs that will pass IPv4 multicasts >>>> but not IPv6 ones thorough "transparent LAN service" configurations. >>>> >>>> Regards, >>>> Mark. >>>> >>>>> Thanks >>>>> Brian >>>>> >>>>> GRASP_LISTEN_PORT = 1021 >>>>> ALL_GRASP_NEIGHBOR_6 = ipaddress.IPv6Address('ff02::114') >>>>> >>>>> mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) >>>>> mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) >>>>> mcrsock.bind(('',GRASP_LISTEN_PORT)) >>>>> mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_zone_id) >>>>> mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq) >>>>> mcrsock.settimeout(300) >>>>> rawmsg, send_addr = mcrsock.recvfrom(2048) >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Mar 12 08:53:40 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7065F12D797 for ; Sat, 12 Mar 2016 08:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYeYSocAXW3G for ; Sat, 12 Mar 2016 08:53:37 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA53912D7CF for ; Sat, 12 Mar 2016 08:53:37 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 66FAAD788E; Sat, 12 Mar 2016 08:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=wsqsxM1ddeEEDbLxyI8PtR8mmaM=; b= Mi0aXiMSVNcYkp5JS0J3g//ufknMjFxZojitT70HJEHzDR1F2gKuwDNcgq0eb8Ln X+vnRDktm21xbNiXWhAsV3GWq4V3gLFIAYPiHls7SU0VxPjSkxnTHzceoA7/aUyY moAxl906Xl3PYmBYRYBBxmr89nq18Q8OpdpA1mVs1WQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=MfTwyIinPD1PDQrJVAkULkqE5E 87h4hYc8wXnxjKgqmb1dANnBT4eae3fCnJO1rQPcPJUZ+u7xLhItx08rTASNNXJa XYzHJKKBDLPVxAEnz5/HZohXvAfEz7UQxHbSkn4h71BNcqSve+p0HA7uXVzJjZ+3 Vf3nYqQaJ3Rwqpf1w= Received: from h.hanazo.no (46.66.160.197.tmi.telenormobil.no [46.66.160.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B6E7FD7882; Sat, 12 Mar 2016 08:53:35 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E62341285C8A; Sat, 12 Mar 2016 17:53:27 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_76505428-2AB7-4CFB-9054-5DF893E108BF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E318C7.5020200@gmail.com> Date: Sat, 12 Mar 2016 17:53:26 +0100 Message-Id: References: <56E318C7.5020200@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 16:53:39 -0000 --Apple-Mail=_76505428-2AB7-4CFB-9054-5DF893E108BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, Let me offer the contrarian view. > I disagree with Ole. I think there is is useful factual information = here > that should be published. "Solicit input from network operators and = users > to identify operational issues with the IPv6 Internet" and "document = IPv6 > operational experience" are part of the WG charter. I've read through the document one more time. Would you be able to cite = new and useful information in this document? That isn't already described elsewhere...? - Parsing EHs is and the consequence of having to walk the extension = header chain is a well known problem. If the premise is that we want this to work well for arbitrary = middleboxes, the solution space is empty. - HBH headers is a well known problem. One draft in 6man as well as = changes in 2460bis. - The ECMP problem is well known. We tried to solve it with flow label, = in practice the IP header has evolved to be 24 / 44 bytes respectively. - The MTU attach is already described and resolved in 2460bis, 6145bis, = 1918bis > The new "Future Work" section is also telling us that we aren't done = yet > if we want to improve deployability. Enforcing a cap on the extension header chain isn't going to make the = slightest difference. Vendors can build whatever you like, but are you willing to pay the = price? Especially given that real, deployed applications aren't using = EHs. This reminds me of the ngtrans/softwires/v6ops/6man saga, where we had = the belief that the reason IPv6 wasn't deployed was because we didn't = have the right transition mechanism, or the right interface id = generation mechanism or at least 3 different ways of assigning DNS = recursive resolvers... History has shown us we were wrong. Given that EHs are rarely used, all the time already invested into = clarifying and tweaking them (we've publish 10+ documents on EHs = already), is it really good use of the IETF's time to publish yet = another document, that rehashes the same problems? I think no. I think we should let the EH "problem" rest for a few years = and see if it is anything worth revisiting in say 2020. Best regards, Ole --Apple-Mail=_76505428-2AB7-4CFB-9054-5DF893E108BF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW5EmHAAoJEL7aWKiYQt92VVcP/iZ58v5DbyLzFUN75MzawZfz C5RGZGCp96Dr/exb6cteOfGgA9UVCdeUMUh3Ik+ecLM9dpm4Hghe8ghBT1pmwmVP v09NCfazJ1NZIlObUIXbHz8CHc8SADKLc57AXwv1dqjJpjwcV/Bn9YqCxx3UQps8 Cx8BdnUyiZdh0/ymn1x3TPy6JYDRgzMUbjvqYxYZjayi2+VvasSxL2dbIbzBCiJs uRz33PIvDVIOXVoxc+YWj1+BIll2mWxcfSI1ENo4DEni7vGCPlPTd8t0JhewfKbz 7O6yFrIDIf06UVFkeMHF/jhZpj79ezqJp//t67dRMPJWkpQDBBSOicAN4OEccBid XrdPHIS4zKDEvuoRxh4GYNiPdokkL2pBQvSGVEPBNPPibqKwIsuDyoGzE3treUVz 0DQm4PtUjROKhd26IAYGO2uHpevDPD7OOpVKj41VWlh+XXIlMhoSeL7+NV+7IE2I RpA8rOBBL12121dUhHd9uWVXE+PyU+gU2tbv+zRQWJ524ziCzvtvLE6s/TkenvcM 3nJvxZOO3653gz5pITcFmaQD1R5OeZ/yTfmyB8RcxEUE9Iy0bQS389xvums2rBq3 YBin8/7+vRxe0RxRcR35N2TGLeviKxnutGjPf4E8OI79lKdMGGUJTkdow/L7lbdD I5ev5IYRlcZKGoV5AH6v =NKQh -----END PGP SIGNATURE----- --Apple-Mail=_76505428-2AB7-4CFB-9054-5DF893E108BF-- From nobody Sat Mar 12 09:24:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF5712D567 for ; Sat, 12 Mar 2016 09:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwl94VKriwLZ for ; Sat, 12 Mar 2016 09:23:59 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEC912D558 for ; Sat, 12 Mar 2016 09:23:59 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EFF2FD78A1; Sat, 12 Mar 2016 09:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=FZF4826F94sgUKm8W7682RjZl5Q=; b= bWK5gGbhZ0U3uNROxiBtVqDOawpbcKWh+udTd05+Ayq2eyybV7hfPLNnvvXhzIrQ kWa9dkSuJGhLYExrWtGmY7hM+wzCRHaY7bRvYbJuodsygOoJ0WDazW5Q/dsrCFcc rUhPJaGt0IVAHqTL8EdPbRkPraoj0xbT8FrxzBgQJOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=ccuZZQU1r3ezmc1Q8ZupjeYrtR xL9dTayj0jz0ISl0C+J4l+82ZRC4N7zcfk1ssIaRPxIZbkRbr8mRi28NHzr9Nf6R da+vFcevC3KH9PbY9k3xIwy0O793g+RisFxyD4uIPvQPwqL8dDKR1JU5xQNsgcgO nXazqKvbk8hIjbT1E= Received: from h.hanazo.no (46.66.160.197.tmi.telenormobil.no [46.66.160.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A0337D789D; Sat, 12 Mar 2016 09:23:57 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 455EC1286AB0; Sat, 12 Mar 2016 18:23:51 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_04A7B16E-4DAE-4C26-B514-9C4C3858E771"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E36583.606@pluribusnetworks.com> Date: Sat, 12 Mar 2016 18:23:50 +0100 Message-Id: <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> To: Sonum Mathur X-Mailer: Apple Mail (2.3112) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 17:24:02 -0000 --Apple-Mail=_04A7B16E-4DAE-4C26-B514-9C4C3858E771 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sonum, > Have some questions from MLD Snooping switch point of view. >=20 > If there are no Routers involved, it is Snooping switch responsibility = to send MLD Query to keep the groups alive on the switch. > What is the correct correct Source IP to use for General Queries ? Is = it Src IP all 0 or some link-local Address ? Which host stack would = like/accept what Source IP ? Have observed different observations with = different host stacks. see rfc4541. > Also, per discussion below - what is the right behavior for snooping = switch when it comes to link-local multicast groups - flood or snoop ? = It would be good to have a standard practice for this. it depends on the platform and how big forwarding table your switch can = handle. as far as I many switches flood,( and if you want my personal opinion, = we should change hosts so that they no longer send MLD joins for = link-local groups.) Best regards, Ole --Apple-Mail=_04A7B16E-4DAE-4C26-B514-9C4C3858E771 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW5FCnAAoJEL7aWKiYQt92ZCUP/Ro2VrTGgShdHUV79yDbq19W bO8awsS410OhGjm0HWR7IgwiyxsZX5gGnoZ+6p4iFBZNV3J9DlmDoEGLeh6z7Eos PHjDLLUzp9T0wYxeGbr9w31hRQm50aLqF/RY5BvgH0EqXbMnXlSXluiCFSZV/Hjf hLQ32K8HhKSynnqcPYMRACNOauuJfA9d8dnWGC90HcHH+f4jKebwH1IGG6KjbpGD pBHDdyVG1+zXlVSmoTV8xj4kUQB2qHexVEgkQjsUihk9TwDbzWgeaw0yrB4yq76y 94pBUOedn5hu1XVOOXFoVQ0Nt+re5P5oSIdCZnYHHiQM2ycoAe+jfb1PFUlN+us8 8T7jDef1JYUQnM+SK0QdsPUnGigJ3S5JMY8p4eAZbZiqu+/lOqEZDVv9fnD4rRk3 Nqiy1vwFhNmMt/kCSdVW8T00VJHpnGxg1PxqB3K7R6T5NFMJf7XHeGmsxPJPYpmY bZ/gfa2H3+VblWg0IlKLn5t/RZkjtBDy8hnTpDKYttkkpNQzDbc+p61POB9sqD5U 5qaNF17ooglenR7Ei2diBJgRsDezlPDvHih3F8Lua/MzZfFtDOqW2Oy+Rwlj3i7r a0eEa9VsQDU1OQBuUHzoJ9Ljcr27TYZiUiTGFiMZ4wHFzq76FGthgbMaWfU/rg9t wMlGCqssF9zMchnSmqV/ =jyyY -----END PGP SIGNATURE----- --Apple-Mail=_04A7B16E-4DAE-4C26-B514-9C4C3858E771-- From nobody Sat Mar 12 10:30:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4812312D716 for ; Sat, 12 Mar 2016 10:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OV3JBzzCzLm for ; Sat, 12 Mar 2016 10:30:11 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F17312D75C for ; Sat, 12 Mar 2016 10:30:11 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id fl4so124302064pad.0 for ; Sat, 12 Mar 2016 10:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=q8ahwZFAhn22RcnolyLPR9yYzkccOQ663wane8+qHP8=; b=A/b2P7YzVZ4IG9JLTZP5mTOC9Osv1+RxLqAQD9b0/+Syt8AvSLB09fgw+l0WCBNIbm wcOWX1fAm0DoQ/4fCQBsVURLA/GHf3mYh9iIBH9qjTB3VPqABMxMJjVGR7SsC9A4YnGi 25XCi9Ob+r/NpipLY0zqSIY8DRaL/O7nbD22nU4ZGKwXk84IdostyhsV3hCtfIxEpkUm NY8LrUzN5N5QEVT+2zS425F2qUub1ZgTGvehc7gFE/WZ6QCYGRxo+hDY850O6AD9zjWY EpdfjOBPOb95SDoI+IUEed8jsV5jDwjZTg07iTo7RZmIMGGR02xHcunrW7ZXvH5dLbAm yGOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=q8ahwZFAhn22RcnolyLPR9yYzkccOQ663wane8+qHP8=; b=iriqZ5+AG72XT07KYUgENszAfZ7vIZgR6MIgNVZibMw1vSSmtUUVWTPkAYQ307QvnP YkYXr1UT+rSglszRzrQOLmSfZX85TTPfPG4T7vqitiKbxe+Vo2Wg30FHcWLpJ+oOHTTW TNpMruNHa6m2erL7LVQ+XHDMSVOeM7b+XXmsHHOff9lUMw8/312XOP8XCDnriH+uNXLx QzvBNMjApQN9bzqVVg3nI3HnMqc86YqRBk+D0GgHWZOU/0v5E1rUWdnzZlJ7L/4k0acU FR5UgCENQZMdDJ/VvbG9Gk3V5BBRMr/nxm7zxU6qqDGb7nndnv0CMHSFU6TujdGvda4r NLNQ== X-Gm-Message-State: AD7BkJIWaT85fyw9qDDulSPSVJcOfBXxr2oOsWWb1LpAGZbyprvHdiriTTF4lB5gGmYOIQ== X-Received: by 10.66.146.39 with SMTP id sz7mr25644928pab.76.1457807410592; Sat, 12 Mar 2016 10:30:10 -0800 (PST) Received: from [192.168.88.117] ([103.29.31.50]) by smtp.gmail.com with ESMTPSA id tp9sm21314235pab.14.2016.03.12.10.30.07 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 10:30:09 -0800 (PST) To: otroan@employees.org, Sonum Mathur References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E4603A.4080200@gmail.com> Date: Sun, 13 Mar 2016 07:30:18 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 18:30:13 -0000 ... > it depends on the platform and how big forwarding table your switch can handle. > as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.) But we can't do that unless all switches flood. Brian From nobody Sat Mar 12 10:42:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB9F12D710 for ; Sat, 12 Mar 2016 10:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvn6KWLzIlSZ for ; Sat, 12 Mar 2016 10:42:17 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA6B12D6F9 for ; Sat, 12 Mar 2016 10:42:17 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id u190so76705251pfb.3 for ; Sat, 12 Mar 2016 10:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pTf4pWuU9r0j0wT0jtghN9ZFVbD9HR8D5vaAA2DIqwA=; b=H9OByhSE+7lg2QUQhfFlXDFcWOuQZDPEsy8EueTfL8LmnYJifbBuAWj9hQvfY88ZbW qEMay0lw2sJK8uWW4rvE8SQJveq/HELyjbhMUOzzzD54euxNswC/ZxhqKdnQp7cuvzTf 4QcPqzi6J/Qua3VqZXK5MejigaOYqGfasFGleKYkTQOxjaj2HBC/X+8HjmuhbtqAcwaO K1DU2MsLvDwG62aIyiped1Vtl7mCmlQd9az1Pqs0a2Pb9va7aD6Q7j4yB8yIMYLuGcDb LpEr1GLY5XRZXrWuR/3HeaQxKLdxQ9pWc1CrRgNIMbGBsd7In1zK+ifEdK4Z8Eas5E3X iM3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=pTf4pWuU9r0j0wT0jtghN9ZFVbD9HR8D5vaAA2DIqwA=; b=jNLfeE2rBVwxhYzBE8JezYeagsHrI5oGhcBd455y1gO6SHCqgiUH2l+8dh44elCU5t qpxsvKAtJjVzjeuXjR1LY7DVRzbWIk0oMApbkUvtMphUWbWos8Oxu7L02byu0YySMvb8 RWcBW2QHUqry8xx3hNiyZF9tNvFfrG2mMTQyXrPHsLiSQdQMrYAtnDVn7UYgPzbkJAsJ 63OFSjnw/WcEKIb1DMXFRpvnW+zOB9T4IShlsjaFBNeXxWA0BXE2YjooViNE7zj/nfz7 HW9MQWAYVm3aEgWPVnO4zJkMrFS2372ZXOPsGwsdFpVkoR9VuPciDk8YKiMiU/Hr+e70 bBdA== X-Gm-Message-State: AD7BkJJy6z4pbIU+UDLX+Etzgn5TZuF21i9RJoPuaVRd2aIqtE9f4wkiVDwSpX4jINvSfg== X-Received: by 10.98.16.4 with SMTP id y4mr17243292pfi.45.1457808137042; Sat, 12 Mar 2016 10:42:17 -0800 (PST) Received: from [192.168.88.117] ([103.29.31.50]) by smtp.gmail.com with ESMTPSA id x64sm21295395pfa.72.2016.03.12.10.42.13 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 10:42:15 -0800 (PST) To: otroan@employees.org References: <56E318C7.5020200@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E46311.8060602@gmail.com> Date: Sun, 13 Mar 2016 07:42:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 18:42:19 -0000 On 13/03/2016 05:53, otroan@employees.org wrote: > Brian, > > Let me offer the contrarian view. > >> I disagree with Ole. I think there is is useful factual information here >> that should be published. "Solicit input from network operators and users >> to identify operational issues with the IPv6 Internet" and "document IPv6 >> operational experience" are part of the WG charter. > > I've read through the document one more time. Would you be able to cite new and useful information in this document? > That isn't already described elsewhere...? The observational data, which for some reason people wanted to push into an Appendix. For me that's the main point of the document. > > - Parsing EHs is and the consequence of having to walk the extension header chain is a well known problem. > If the premise is that we want this to work well for arbitrary middleboxes, the solution space is empty. > - HBH headers is a well known problem. One draft in 6man as well as changes in 2460bis. > - The ECMP problem is well known. We tried to solve it with flow label, in practice the IP header has evolved to be 24 / 44 bytes respectively. > - The MTU attach is already described and resolved in 2460bis, 6145bis, 1918bis > >> The new "Future Work" section is also telling us that we aren't done yet >> if we want to improve deployability. > > Enforcing a cap on the extension header chain isn't going to make the slightest difference. I tend to agree on that specific point. But we need that restriction anyway to reduce security risks. > Vendors can build whatever you like, but are you willing to pay the price? Especially given that real, deployed applications aren't using EHs. > This reminds me of the ngtrans/softwires/v6ops/6man saga, where we had the belief that the reason IPv6 wasn't deployed was because we didn't have the right transition mechanism, or the right interface id generation mechanism or at least 3 different ways of assigning DNS recursive resolvers... History has shown us we were wrong. > > Given that EHs are rarely used, all the time already invested into clarifying and tweaking them (we've publish 10+ documents on EHs already), is it really good use of the IETF's time to publish yet another document, that rehashes the same problems? Again, I believe that publishing the observational data is useful in itself. The rest of the document is context. > I think no. I think we should let the EH "problem" rest for a few years and see if it is anything worth revisiting in say 2020. But then what do we do when people come along proposing to standardise more extension headers? This document will be helpful, I believe. I do agree with you that once this and the current drafts in 6man are resolved, there's little point in doing more for now. Brian From nobody Sat Mar 12 11:07:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6170612D723 for ; Sat, 12 Mar 2016 11:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.522 X-Spam-Level: X-Spam-Status: No, score=-114.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9gO7XllwGgI for ; Sat, 12 Mar 2016 11:07:12 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9497312D714 for ; Sat, 12 Mar 2016 11:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1846; q=dns/txt; s=iport; t=1457809632; x=1459019232; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bWfGPA2BBLcP+avI35/G46nX5pLWGdrtnYL2Os6OEFY=; b=XfbGhi7ya/OZ3wjHi8+kHB///SD++7ICQI8jsdGWpDZcMdCRlZaMCt48 Qk9b00kRLSq+jSLzD98fDDxCUtRCxuUlB8qrGIBm8xDYEwLijYfl6GT24 RUTrLsvwTwWbI6/ijO8C+/yCPPbjANEV+Dn/GOoEDa5wtnWraaTb8e/dk s=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAgD0Z+RW/49dJa1dgz6BPwa6KA6Bb?= =?us-ascii?q?YYNAoEnOBQBAQEBAQEBZBwLhEEBAQEDAXkFCwIBCBguMiUCBA4FDogOCLx0AQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDQiIC4JPh2WBDwWXSwGDGoFmiH+BT402jnwBH?= =?us-ascii?q?gFDg2RqiHZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,326,1454976000"; d="asc'?scan'208";a="246826170" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2016 19:07:11 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u2CJ7BjD025224 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 12 Mar 2016 19:07:11 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 12 Mar 2016 13:07:10 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Sat, 12 Mar 2016 13:07:10 -0600 From: "Fred Baker (fred)" To: "otroan@employees.org" Thread-Topic: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRe3z+jjdZn/af1k6rS4wakEAZsw== Date: Sat, 12 Mar 2016 19:07:10 +0000 Message-ID: <988AECA3-61E1-4B45-AC39-A9EFF086854A@cisco.com> References: <56E318C7.5020200@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_4836A0D0-E26E-46AC-9BA8-286EA742FDB8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 19:07:14 -0000 --Apple-Mail=_4836A0D0-E26E-46AC-9BA8-286EA742FDB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 12, 2016, at 8:53 AM, otroan@employees.org wrote: >=20 > Given that EHs are rarely used One specific point that worries me in this discuss is the indiscriminate = reference to extension headers. One of the is the Security Header; I use = the IPv4 variant of that (I believe along with UDP) when I use = AnyConnect or Cisco CVO, which is to say "pretty much invariably". If = the call is to deprecate extension headers, do we deprecate IPsec? What = other instance of "baby vs bathwater" are there? --Apple-Mail=_4836A0D0-E26E-46AC-9BA8-286EA742FDB8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVuRo3UayAOS/EQ8MAQI3txAAv7nwSVv+CTCp23rfncc3Bj5Q1U5z7E6x nZiM6h/7nVIK8ajHrCeQXWPtoiA2Q1sR8TYy6wVc4W5/CFmZAtX2f2HrHYvKyeqN 1RtJwT0HkAXJm3I7T6Z5JxHh4dBOoEt0IDbea/MH+7ZI/uGejqtEsTCQZdiTI2IT yP5pDDdlPRo+dnbCFyc8OhsNuXjA1UAnxAuRl7MF6tfTUBvWgixOtLy/hK5WmxuR OApEOsTL9Om/3vVYnGYUHzrtovLpakB6S7r0Zm65IFIQFbSm3btrSARzm1Z1ICc+ zQc0zGMwkaAmpoXrfuq5rRjUCHcuZswm/pwpQbWORtQ5eL8mV3yYUMjQk1MbGDSl SURiI71oSBHjpg+zyO3+e3lbOVVq912KdqPDbj1A2gzseBOdVPBfdrwHVvLuVVXx iuU6cpm0Yk0mHbj+Ia9rJn8mymDozzzBg3792HjTIEjSzMDixTcjkwSf3rA8VL37 h3nJvOeMBLiuyEkEeOqqQfC97sfDv0tHckoy22PoJg06tPCKrDv9hFZeg1DLlaHh Mq+Kdt9qMwq9J9qLZwqwcpdqHQDJzdHfqe38R4IdiaXRhlw9r8tVVL6guroiernN wsUeC918IUma5Bu4paAa6iwt8W+KOEHUI8dWeO/EBAS7xScNWja9JBAW8GTMQPH2 1CDMpC1TNkI= =BvoE -----END PGP SIGNATURE----- --Apple-Mail=_4836A0D0-E26E-46AC-9BA8-286EA742FDB8-- From nobody Sat Mar 12 11:22:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F5B12D5B5 for ; Sat, 12 Mar 2016 11:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2m33Bwn0GDv for ; Sat, 12 Mar 2016 11:22:04 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF4712D545 for ; Sat, 12 Mar 2016 11:22:04 -0800 (PST) Received: from [10.1.0.55] (dslb-094-217-017-121.094.217.pools.vodafone-ip.de [94.217.17.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 33E0C8024B; Sat, 12 Mar 2016 20:22:01 +0100 (CET) To: "Fred Baker (fred)" , "otroan@employees.org" References: <56E318C7.5020200@gmail.com> <988AECA3-61E1-4B45-AC39-A9EFF086854A@cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56E46C52.5040505@si6networks.com> Date: Sat, 12 Mar 2016 16:21:54 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <988AECA3-61E1-4B45-AC39-A9EFF086854A@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 19:22:07 -0000 On 03/12/2016 04:07 PM, Fred Baker (fred) wrote: > >> On Mar 12, 2016, at 8:53 AM, otroan@employees.org wrote: >> >> Given that EHs are rarely used > > One specific point that worries me in this discuss is the > indiscriminate reference to extension headers. One of the is the > Security Header; I use the IPv4 variant of that (I believe along with > UDP) when I use AnyConnect or Cisco CVO, which is to say "pretty much > invariably". If the call is to deprecate extension headers, do we > deprecate IPsec? What other instance of "baby vs bathwater" are > there? I don't think anyone is calling to deprecate EHs... quite the opposite: the idea is to try to make them deployable. Regarding IPsec EHs, they are filtered in a similar ways as other EHs. Hence it does make sense to reference the whole bunch as "extension headers". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Mar 12 11:22:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AED12D545 for ; Sat, 12 Mar 2016 11:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8GRup6TsNO5 for ; Sat, 12 Mar 2016 11:22:04 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6CA12D528 for ; Sat, 12 Mar 2016 11:22:04 -0800 (PST) Received: from [10.1.0.55] (dslb-094-217-017-121.094.217.pools.vodafone-ip.de [94.217.17.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 52CD180168; Sat, 12 Mar 2016 20:21:58 +0100 (CET) To: otroan@employees.org, Brian E Carpenter References: <56E318C7.5020200@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56E46B94.1040004@si6networks.com> Date: Sat, 12 Mar 2016 16:18:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 19:22:07 -0000 Ole, On 03/12/2016 01:53 PM, otroan@employees.org wrote: > > Let me offer the contrarian view. > >> I disagree with Ole. I think there is is useful factual information >> here that should be published. "Solicit input from network >> operators and users to identify operational issues with the IPv6 >> Internet" and "document IPv6 operational experience" are part of >> the WG charter. > > I've read through the document one more time. Would you be able to > cite new and useful information in this document? That isn't already > described elsewhere...? Quite a few times in this discussion you argued that when use of the Flow Label for ECMP is widely deployed, there would be no need for routers/middle-boxes to process the EH chain. Among other things, this document clarifies why that's not the case. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Mar 12 11:27:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264F012D7EE for ; Sat, 12 Mar 2016 11:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JSndqllsJDA for ; Sat, 12 Mar 2016 11:27:07 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8C512D7DC for ; Sat, 12 Mar 2016 11:27:07 -0800 (PST) Received: from [10.1.0.55] (dslb-094-217-017-121.094.217.pools.vodafone-ip.de [94.217.17.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E36DF80168; Sat, 12 Mar 2016 20:27:05 +0100 (CET) To: otroan@employees.org, Brian E Carpenter References: <56E318C7.5020200@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56E46D83.5070601@si6networks.com> Date: Sat, 12 Mar 2016 16:26:59 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 19:27:09 -0000 On 03/12/2016 01:53 PM, otroan@employees.org wrote: > Enforcing a cap on the extension header chain isn't going to make the > slightest difference. Vendors can build whatever you like, but are > you willing to pay the price? Especially given that real, deployed > applications aren't using EHs. If that's your take, then I guess you should be arguing for deprecation. Because the "EH" feature requires code, and that code has been the source of trouble in a number of places (including evasion of security controls, DoS vectors, and others). I should note, though, that IPsec uses EHs... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Mar 12 12:19:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1813B12D831 for ; Sat, 12 Mar 2016 12:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7NXZQj2DfdG for ; Sat, 12 Mar 2016 12:19:26 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7963B12D775 for ; Sat, 12 Mar 2016 12:19:26 -0800 (PST) Received: from [192.168.0.179] (104-180-168-206.lightspeed.irvnca.sbcglobal.net [104.180.168.206]) by dougbarton.us (Postfix) with ESMTPSA id F3A4F3A0BD for ; Sat, 12 Mar 2016 20:19:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1457813966; bh=5kwDsftxC45foFzMYITxPPMRJPw4plZ7zlt7PLNMqiE=; h=Subject:To:References:From:Date:In-Reply-To; b=kMVLmISVydcaw9hrWfUpwbp2pyF6gNlXrIQ0qWoF9marqR9wA55aC2Y6W5pb5eyOc 7FhajT8P5MA2yEZbTLAh3jVSbReUq7L0SAhl9c6fVJHrmVy8QkZDOzbd5s3NG1zuwE fXb4mVzBWZFkLhivQTxQDNXzGVP03wfuIRSZqLtk= To: v6ops@ietf.org References: <56E318C7.5020200@gmail.com> From: Doug Barton Openpgp: id=E3520E149D053533C33A67DB5CC686F11A1ABC84 Message-ID: <56E479CC.4060302@dougbarton.us> Date: Sat, 12 Mar 2016 12:19:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 20:19:28 -0000 On 03/12/2016 08:53 AM, otroan@employees.org wrote: > I've read through the document one more time. Would you be able to cite new and useful information in this document? > That isn't already described elsewhere...? IPv6 has suffered from the "too many drafts" problem for over a decade. Assuming that the derivative material is given sufficient citations there is great value for implementors in a document that summarizes the current state of the art, combined with actual observations of said problems. Doug From nobody Sat Mar 12 13:43:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC8D12D87C for ; Sat, 12 Mar 2016 13:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzj8Scmt80U9 for ; Sat, 12 Mar 2016 13:43:36 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34CF12D872 for ; Sat, 12 Mar 2016 13:43:36 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 337F6D789D; Sat, 12 Mar 2016 13:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=nciWnz9x/WrDX52LI8ku+uaUrZA=; b= Lf1e5lDpDp22h9MA3Fx/3QRmLZaZgrbMwZwaZHupPROp8MFJPZKijOcZpPMOQRRA wXIFdWEiYrvUiqf2k/GfEJeO1WF2UhpVfwswMNTLzbxs7JZR4qfE4dSkOpQLGrap JQSPUqr1dliml74LsDVEfZTR1MmQhhzGEHqKRNBeb+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=DsIjfci2PqAHquhk/pIsnUzvtA 6XzATjjwCiE3HahkOh3fvtXs50K01eYewNa4XPZJYkCUrp5KJbrzTCphGbCS8+HD YlTac7G7vCyMDW3YEwUGbaEc1lZjo/y1aQyhSiDJ6rpXJp8Um6k9PfUrLe+rdbSD q5a0x/y/4fYI3UOXQ= Received: from h.hanazo.no (77.18.136.136.tmi.telenormobil.no [77.18.136.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id D03EBD788E; Sat, 12 Mar 2016 13:43:34 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BE35412892A0; Sat, 12 Mar 2016 22:43:28 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A1D129C7-8BF7-43A9-8869-C064BB429B09"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E46311.8060602@gmail.com> Date: Sat, 12 Mar 2016 22:43:27 +0100 Message-Id: <7803B999-31E8-490A-A595-FB5B36E7CFDB@employees.org> References: <56E318C7.5020200@gmail.com> <56E46311.8060602@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 21:43:39 -0000 --Apple-Mail=_A1D129C7-8BF7-43A9-8869-C064BB429B09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, [...] >> I've read through the document one more time. Would you be able to = cite new and useful information in this document? >> That isn't already described elsewhere...? >=20 > The observational data, which for some reason people wanted to push = into an Appendix. > For me that's the main point of the document. Which observational data are you thinking of? I looked and couldn't find any, you aren't thinking of = draft-ietf-v6ops-ipv6-ehs-in-real-world? [...] Best regards, Ole --Apple-Mail=_A1D129C7-8BF7-43A9-8869-C064BB429B09 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW5I2AAAoJEL7aWKiYQt92ghwQALMsWCwZm3JpjIWZqsU4VFaU hwykJHtmcLRFVXtpV5x0kvU/VtMoKakGtU3mjTbjVYLkcU1jtI5HI/wCyBgR+s7E pDVnwqzlz0f2ymfp27eECl4fYijScFa5HRzyFYTa+kMuHuLEXPSyZqsZKcZ1nZ5b o/7C0tAewnHTzp1BgxsCdE4sMqrda/Yj3zhOGn54LDFEcInWnGR8eY1xBnsE6mpo R5As0DvvLy/fkQQxHPVrudE8vFnzFkGfJlWvjN/Oau2/GcaKn4Uk78NOSVArUcEA gaTwA1gKwlBU+Of/ZU2tkO4UzYKkUuPWQTlQYfjjCC1m3Na7adWC4SrVqyi2D8gc k6ZhElpMoqvEEn6GBgu8z0g4igO8i1mCr+TYIYKAsvqgeiM7pGaYuFvvXaLACFyh 0kXQYFOYCuBxDNQ/+Joz+QTO5+y3yWYb3DZR/z2Ao6MFFq5J7Fvw5ThPQRy9cIEW /RyZIXjBRd4dsN9EwlieVzW1DDUeOrCO8IyYKiry1dkxhxo9BKiYRvW4VnifCZlt WnWj0s+cSJOWXZ7M9H6Nb50L3wFYymfRD6pkTKDPJj4qdcopk9djD1RrhQ5RMFWC M1p+txmslMSy6tcLX+pctL+dVzxiqexOY9tzTu+6foY437tIAzvBUhCevc9Opalw kDMC2M+C7SLx4t0RaayA =DbB5 -----END PGP SIGNATURE----- --Apple-Mail=_A1D129C7-8BF7-43A9-8869-C064BB429B09-- From nobody Sat Mar 12 13:48:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9612D883 for ; Sat, 12 Mar 2016 13:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BUTX5vbG0Xa for ; Sat, 12 Mar 2016 13:47:59 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F78C12D880 for ; Sat, 12 Mar 2016 13:47:59 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id E081BD789D; Sat, 12 Mar 2016 13:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=ViPQmOmZsbtJq8OIg2GOYjWF8Tw=; b= gBWAeBy2XLx2ndA25GPb0YhV9MIQf8nDktETIJHOahRAWFOhAW1zEfjoPHsO5iwG +mzR4F+vcyzB2ChnrqUKkMonI9xZGhZjaIdoBxG3CN7wQIOmAY0SMLC3XtG5mQVq lw2wnW0C7s6R8HLxSUe+gbXRP7oSApnOnyFfDpqrqko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=Ffc1xK9Qn7jSj23LYc2lTiUDAq bnjDb2iiaaa3Cvbnj1LFkVN5p/G60GdB1YOfXmOleuDQFUJ5Po1N/GGNn1Jksq9z Sh/0raf8GMCGv0YDQ/kpi/iCl4gDgNa3pCXevVDlVHBYGvFxjgz+fG61Q0z+sJu/ rU1MQhkN9Kl9DPzm4= Received: from h.hanazo.no (77.18.136.136.tmi.telenormobil.no [77.18.136.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 7EA64D7882; Sat, 12 Mar 2016 13:47:58 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 451F81289353; Sat, 12 Mar 2016 22:47:51 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2B65BDB9-A554-4207-9BF2-F89AD0E8B9C9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E46B94.1040004@si6networks.com> Date: Sat, 12 Mar 2016 22:47:50 +0100 Message-Id: <355ECDE7-13B5-43FB-9AA9-B465AB4F966D@employees.org> References: <56E318C7.5020200@gmail.com> <56E46B94.1040004@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 21:48:00 -0000 --Apple-Mail=_2B65BDB9-A554-4207-9BF2-F89AD0E8B9C9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 Fernando, >> Let me offer the contrarian view. >> >>> I disagree with Ole. I think there is is useful factual information >>> here that should be published. "Solicit input from network >>> operators and users to identify operational issues with the IPv6 >>> Internet" and "document IPv6 operational experience" are part of >>> the WG charter. >> >> I've read through the document one more time. Would you be able to >> cite new and useful information in this document? That isn't already >> described elsewhere...? > > Quite a few times in this discussion you argued that when use of the > Flow Label for ECMP is widely deployed, there would be no need for > routers/middle-boxes to process the EH chain. Among other things, this > document clarifies why that's not the case. Sorry I don't get that, can you point that out to me? Best regards, Ole --Apple-Mail=_2B65BDB9-A554-4207-9BF2-F89AD0E8B9C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW5I6HAAoJEL7aWKiYQt927W8P/3k1D16XBMxX+LvWpYe1D+RW B4n+4OmnufcXswRdIlthF08ewCfGZvx85BEn3NA9MFF3IX8Ht4grWqv2cZju7liC QXU4+S3gs7PUUTtrTbC7n5Dg7E0Op4oE1GZjDonTjmS0fO23PN7cUcfzyyYpzMEJ guuzFvFYwXn0GTHdDHea66YDNazXpZMOvLOcSUbwwBKf9IBc1p4UtrhfwZkI6JLW fye6RmVtEXmrON/5sXRg44wFlVaCxT9VBHQTSgpzm0tlrCDqhPAIZUVdMYrEAeDW FcxcfQwcRHWNBcRqAeqryZ3eB87NLPc18xkQVr3oI21pnSyjdRB28tJQ6bpjFbuq P8k0DpMvPXZiAPmv5b9wEQZZMqpwQqdKkDNDnPyI4Ycn0WsooRyB3pRPK2lEchVz J+buy7luZOtIF6ZENGWyVChQ7ly/IMN21YtrXPCIMUGfbph+oF7izyj/otkGl/pO e6ZtrTU/pPuhfIxXwpqR9btnqRiiuWdiI1i/sofe8DGomSaa7ciREbfpAzR6wv8h Qw3YpfbO1p2B4z5mV8rQGuNkrG6x0jkvZ7988OSSSyNY9tiYZDaIsTCuYEWygap+ skCTOzRe/HeGVVZkJj6F0cwnNFL4C70H/dAUHB3thDoeI5XFkmQoHCIeGNmVuyew VS+TFrIC1gJfE74sJsGX =S+Xx -----END PGP SIGNATURE----- --Apple-Mail=_2B65BDB9-A554-4207-9BF2-F89AD0E8B9C9-- From nobody Sat Mar 12 14:16:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF1912D570 for ; Sat, 12 Mar 2016 14:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF4eDhidmxdm for ; Sat, 12 Mar 2016 14:16:09 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4982012D723 for ; Sat, 12 Mar 2016 14:16:09 -0800 (PST) Received: from [10.1.0.55] (dslb-094-217-017-121.094.217.pools.vodafone-ip.de [94.217.17.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 442A78015E; Sat, 12 Mar 2016 23:16:05 +0100 (CET) To: otroan@employees.org References: <56E318C7.5020200@gmail.com> <56E46B94.1040004@si6networks.com> <355ECDE7-13B5-43FB-9AA9-B465AB4F966D@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56E4950C.4010908@si6networks.com> Date: Sat, 12 Mar 2016 19:15:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <355ECDE7-13B5-43FB-9AA9-B465AB4F966D@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 22:16:12 -0000 Hi, Ole, On 03/12/2016 06:47 PM, otroan@employees.org wrote: > Fernando, > >>> Let me offer the contrarian view. >>> >>>> I disagree with Ole. I think there is is useful factual information >>>> here that should be published. "Solicit input from network >>>> operators and users to identify operational issues with the IPv6 >>>> Internet" and "document IPv6 operational experience" are part of >>>> the WG charter. >>> >>> I've read through the document one more time. Would you be able to >>> cite new and useful information in this document? That isn't already >>> described elsewhere...? >> >> Quite a few times in this discussion you argued that when use of the >> Flow Label for ECMP is widely deployed, there would be no need for >> routers/middle-boxes to process the EH chain. Among other things, this >> document clarifies why that's not the case. > > Sorry I don't get that, can you point that out to me? Sure. This was your question: This was e.g. Joel's response: Section 4 (and subsections) of our document is all about that. Every time the issue of EH packet drops comes up, discussion eventually becomes about "but hey, why are you looking deep into the packet?". -- And a large part of our I-D talks exactly about that. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Mar 12 14:32:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759E612D570 for ; Sat, 12 Mar 2016 14:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRTDcPhYAmmX for ; Sat, 12 Mar 2016 14:32:41 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0E812D545 for ; Sat, 12 Mar 2016 14:32:41 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id ig19so36886572igb.1 for ; Sat, 12 Mar 2016 14:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=1zMIsDjmXIArIA8V87wRYHBU1XffpAolJRUF6ruU6cQ=; b=QhO/kGcA2dZ3BYHjiRN5MaU51nuhpQT7hfHvUJ/J3mXLqsb4aFYv6q/+42MV9RhOca 8vxjLqzPQDNMPFpe8H8h8pqj+y8dPTj4EaYrkhSh6cDn+WAC5VmsHoYWWBBU5FyZTbew GJbwc5TG+pA+NTR5Tb7t23LlQQmkAW4ooTUNSMk4br5QKmiis2h7aZjhIzxHydxE4dja iCj4g68Qb/qj0xt2H/Z8sdNcv7T8mWLp54tJKg4bQHH8j9/Z+barz4nPfdI6Mp8Qhqn8 S5QcMb+wX9vV/Gz0Jc0xiStAtB9Sr+cDGXhBsN1vRxToc4z04iovpDmgFFlB5O735Opd 0PPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=1zMIsDjmXIArIA8V87wRYHBU1XffpAolJRUF6ruU6cQ=; b=f2MGq4WiQiz0L3Zv+vaQntFIcD0wmCoDAJDENIEgCL/RzhHWPYB/ADXwWFQPF+82hk QDOQhQX1K95pBW9wByVZtcO6PG9urteWlBtm5b7RbhoTll3zPARXn5to3hiyVEXsFsKy jWWYaWWzGHTAGr9FUehjwO/EICcc0zLe9wLR5JAUiNemKyCH3ID7ZkcTEskyJGwg/b3g +vIhc91i/luqRrDi8pBycNNcyGY2qVSM9omPCgWjyvYewyxCb7Hw/iDNYqohBelDHO2T gWhuLEBZQZ8n97fLw/iEqkgpYmZXN4wo4rcpUlU3ApAuKPlljhsHVnKAj9kltLP2NOp1 D2pA== X-Gm-Message-State: AD7BkJITpYkgL1dBwMtmX5JyHrtaptS7Upp95LLqOsvkc8UtDf5O+lc+JMBB1e3kcl90ebLyqqPutuasTRrNRA== MIME-Version: 1.0 X-Received: by 10.50.28.105 with SMTP id a9mr11214315igh.94.1457821960881; Sat, 12 Mar 2016 14:32:40 -0800 (PST) Received: by 10.107.160.203 with HTTP; Sat, 12 Mar 2016 14:32:40 -0800 (PST) In-Reply-To: References: <56E318C7.5020200@gmail.com> Date: Sat, 12 Mar 2016 14:32:40 -0800 Message-ID: From: Tom Herbert To: otroan@employees.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 22:32:43 -0000 On Sat, Mar 12, 2016 at 8:53 AM, wrote: > Brian, > > Let me offer the contrarian view. > >> I disagree with Ole. I think there is is useful factual information here >> that should be published. "Solicit input from network operators and user= s >> to identify operational issues with the IPv6 Internet" and "document IPv= 6 >> operational experience" are part of the WG charter. > > I've read through the document one more time. Would you be able to cite n= ew and useful information in this document? > That isn't already described elsewhere...? > > - Parsing EHs is and the consequence of having to walk the extension head= er chain is a well known problem. > If the premise is that we want this to work well for arbitrary middlebo= xes, the solution space is empty. > - HBH headers is a well known problem. One draft in 6man as well as chang= es in 2460bis. > - The ECMP problem is well known. We tried to solve it with flow label, i= n practice the IP header has evolved to be 24 / 44 bytes respectively. Where are these 24 / 44 byte IP headers described? > - The MTU attach is already described and resolved in 2460bis, 6145bis, 1= 918bis > >> The new "Future Work" section is also telling us that we aren't done yet >> if we want to improve deployability. > > Enforcing a cap on the extension header chain isn't going to make the sli= ghtest difference. > Vendors can build whatever you like, but are you willing to pay the price= ? Especially given that real, deployed applications aren't using EHs. > This reminds me of the ngtrans/softwires/v6ops/6man saga, where we had th= e belief that the reason IPv6 wasn't deployed was because we didn't have th= e right transition mechanism, or the right interface id generation mechanis= m or at least 3 different ways of assigning DNS recursive resolvers... Hist= ory has shown us we were wrong. > > Given that EHs are rarely used, all the time already invested into clarif= ying and tweaking them (we've publish 10+ documents on EHs already), is it = really good use of the IETF's time to publish yet another document, that re= hashes the same problems? > > I think no. I think we should let the EH "problem" rest for a few years a= nd see if it is anything worth revisiting in say 2020. > > Best regards, > Ole > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sat Mar 12 14:47:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A0612D660 for ; Sat, 12 Mar 2016 14:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNnGmmMlZJeb for ; Sat, 12 Mar 2016 14:47:44 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD1712D4FF for ; Sat, 12 Mar 2016 14:47:43 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id e6so172015134vkh.2 for ; Sat, 12 Mar 2016 14:47:43 -0800 (PST) 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; bh=U5zYUJ2x5fPN2H49PVRaWoy6dr0Hqcj9EoWZipLHr5M=; b=TihA42GrJbQetYtsHo7zQYaoZW012H0540m5cqGqzqnhwB39StQg9TeQ7VoALwI0zs q84+d6SW3bu51j+YxaSxpj3YZypq3L0YkoU/TqzQwX00ku+pmXuZi8KlmhOLaId0/BKJ S1sXpkDgfmdqjfcsio6lpEno0ddtil+wKkdln7w5d8Azwd3jFpV/4rntNK8QUwW4gZZa ticYvDRA25z253Enag+xYYVHSXjWcSJLp5smRyadafsxvy2GBOn/AM6j9vjjd43DH4cz SVCxv7JSYFS9oSa9DdSVkkuDLuLccD9ZI5RKUsLL0um0X+wqg16cJ5f0rZXV4M14I9eO F/TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=U5zYUJ2x5fPN2H49PVRaWoy6dr0Hqcj9EoWZipLHr5M=; b=IlnUKas8CVuxUkylQoM5zkmHJ87wSWNfJqD37KPmwlnqB3pa03M44Dvv+L0xt6RCtA 6FWwQg5OlaotMp66SwRYMmWN6KJKquE0O1OZ9kpmf1L6VvJzgiaVQ5w6InKh5HVdFAVo T2EA8kdSJlu7thaVKBjaTUZMl34NzFd+QgJK/1Ef0cWd9ZGj7R36vxbpXZ92V+C1/ki9 ld6l8fE6tfW8t3/Eg3q51V7HZMzG4lt6ulUKzYWa622bjGd8IO7mvEP4VH0FSkI40lH6 5GyfQYgK4l9PL5mVybCmJNh9jsmCOZd5rUmhxjbpcE6DRGWH/zbnAyzPLExB7i520kbW ycrQ== X-Gm-Message-State: AD7BkJJzHoe+5fi2WvmiSK1nhrDeib5Z74jmTy51kLt9ti99QCyFzENuGRIk259WXNxlN40FZwppLNLNXJyFBw== MIME-Version: 1.0 X-Received: by 10.31.194.10 with SMTP id s10mr18072917vkf.72.1457822862768; Sat, 12 Mar 2016 14:47:42 -0800 (PST) Received: by 10.176.5.68 with HTTP; Sat, 12 Mar 2016 14:47:42 -0800 (PST) Received: by 10.176.5.68 with HTTP; Sat, 12 Mar 2016 14:47:42 -0800 (PST) In-Reply-To: <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> Date: Sun, 13 Mar 2016 09:47:42 +1100 Message-ID: From: Mark Smith To: Ole Troan Content-Type: multipart/alternative; boundary=001a114661dce18124052de1d5fb Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 22:47:45 -0000 --001a114661dce18124052de1d5fb Content-Type: text/plain; charset=UTF-8 On 13 Mar 2016 4:24 AM, wrote: > > Sonum, > > > Have some questions from MLD Snooping switch point of view. > > > > If there are no Routers involved, it is Snooping switch responsibility to send MLD Query to keep the groups alive on the switch. > > What is the correct correct Source IP to use for General Queries ? Is it Src IP all 0 or some link-local Address ? Which host stack would like/accept what Source IP ? Have observed different observations with different host stacks. > > see rfc4541. > > > Also, per discussion below - what is the right behavior for snooping switch when it comes to link-local multicast groups - flood or snoop ? It would be good to have a standard practice for this. > > it depends on the platform and how big forwarding table your switch can handle. > as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.) > And I think the people complaining about MLD for LL groups may then complain when their hosts start receiving too many multicasts because they're flooded. I'd like to know more about these sorts of issues. What specific resource is being exhausted in the switch? TCAM? How many hosts are attached to the link - I'm wondering if, as a /64 effectively provides no limits at layer 3, people are now expecting to attach many more hosts to a link than they would and have with IPv4. Regards, Mark. > Best regards, > Ole > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114661dce18124052de1d5fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 13 Mar 2016 4:24 AM, <otroan@= employees.org> wrote:
>
> Sonum,
>
> > Have some questions from MLD Snooping switch point of view.
> >
> > If there are no Routers involved, it is Snooping switch responsib= ility to send MLD Query to keep the groups alive on the switch.
> > What is the correct correct Source IP to use for General Queries = ? Is it Src IP all 0 or some link-local Address ? Which host stack would li= ke/accept what Source IP ? Have observed different observations with differ= ent host stacks.
>
> see rfc4541.
>
> > Also, per discussion below - what is the right behavior for snoop= ing switch when it comes to link-local multicast groups - flood or snoop ? = It would be good to have a standard practice for this.
>
> it depends on the platform and how big forwarding table your switch ca= n handle.
> as far as I many switches flood,( and if you want my personal opinion,= we should change hosts so that they no longer send MLD joins for link-loca= l groups.)
>

And I think the people complaining about MLD for LL groups m= ay then complain when their hosts start receiving too many multicasts becau= se they're flooded.

I'd like to know more about these sorts of issues. What = specific resource is being exhausted in the switch? TCAM? How many hosts ar= e attached to the link - I'm wondering if, as a /64 effectively provide= s no limits at layer 3, people are now expecting to attach many more hosts = to a link than they would and have with IPv4.

Regards,
Mark.

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

--001a114661dce18124052de1d5fb-- From nobody Sat Mar 12 18:47:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104E412D945 for ; Sat, 12 Mar 2016 18:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvOMXd5hIDWK for ; Sat, 12 Mar 2016 18:47:33 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0B012D86F for ; Sat, 12 Mar 2016 18:47:33 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id u190so81188353pfb.3 for ; Sat, 12 Mar 2016 18:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gGFN8aUzZvEWGp7FnWNSigz8CamUMhmBQOKI3u84/t0=; b=G+h0H/LfDCpYiuP8BcMtDWQKsEfyoIsdlGVWh0DO3/jaUEYakss9vj4N4Nx0AB5wBY m3lNx6ryj2tlbhbe2hyJ4yckBaCoTel6EIf4yRXLVsrX/26PG1rwi5ZQM6+2swVB70/s N55PYQcxLg1kADxAuazRbLJG+H2TCf8IrIlBSjWYjpAl4duq6G1qGWiCP04ZpmynDPpN aPUKKVF/fz+O0hxPvVixTWD5p1Nbui4xPdiFoHoz3Gbyhc8sK2Z4UQynAhodhNPdyzNo OAhk+6J+r62axwgl73R5xhUnzP40e9Ugv2aM16e87jYUqBVPCA0GAzofAUcDLfIuZtMH cI+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=gGFN8aUzZvEWGp7FnWNSigz8CamUMhmBQOKI3u84/t0=; b=egfUb87YeIL9Y7bQSCQF06jcfKjG41q1GCSNVsthDnJycUNywQLoD+wmbA91rHxGAn qG7tOq1YojBybmTjP0DsdBxxXWb8EepGOAaTUToip4EG6hY4aSAFeW7E9DVu7U9aHQok WI06FgtIPhqIvleDog54QSAFS5KRnxtZORlvzYu6bHcnRpi3bjtrahOe2j4tmJTnJ9ak Y4CWDK9CHhw1aNot0zwaww8pku5ra1uB1bHpeObMWnJsJkwwk64KGpnd93Y2Y2INUeM5 mhbFWaP5rhWyGX2ygZhzm8Ck4FhG0ruSSVu2xQydygYbD+GNXDSh2mjkfvjZcAdm4jR6 sh+g== X-Gm-Message-State: AD7BkJLfiYl0j8f84zCW8A64GFj3ETSiRYRPBduqzNZrfrk4Ot+/S5Ifq2zDB959tDfK3A== X-Received: by 10.98.32.136 with SMTP id m8mr17060625pfj.11.1457837253043; Sat, 12 Mar 2016 18:47:33 -0800 (PST) Received: from [192.168.88.117] ([103.29.31.50]) by smtp.gmail.com with ESMTPSA id f8sm22508823pfj.49.2016.03.12.18.47.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 18:47:31 -0800 (PST) To: otroan@employees.org References: <56E318C7.5020200@gmail.com> <56E46311.8060602@gmail.com> <7803B999-31E8-490A-A595-FB5B36E7CFDB@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E4D4C0.1060405@gmail.com> Date: Sun, 13 Mar 2016 15:47:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7803B999-31E8-490A-A595-FB5B36E7CFDB@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 02:47:35 -0000 On 13/03/2016 10:43, otroan@employees.org wrote: > Brian, > > [...] > >>> I've read through the document one more time. Would you be able to cite new and useful information in this document? >>> That isn't already described elsewhere...? >> >> The observational data, which for some reason people wanted to push into an Appendix. >> For me that's the main point of the document. > > Which observational data are you thinking of? > I looked and couldn't find any, you aren't thinking of draft-ietf-v6ops-ipv6-ehs-in-real-world? Zut alors! (which Google translates to Norwegian as "Shucks!"). Yes, I was momentarily confused between the two documents, sorry. That said, where else will an implementer or an operator find this collection of information about operational practice or limitations? Brian From nobody Sun Mar 13 12:52:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE19412D7D7 for ; Sun, 13 Mar 2016 12:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9ApciXvmxIL for ; Sun, 13 Mar 2016 12:52:44 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F092412D7D1 for ; Sun, 13 Mar 2016 12:52:43 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 77171D7887; Sun, 13 Mar 2016 12:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=ikTRvxDVTyMh0x3+G89C00UJpEk=; b= qybWucnqNwYx4tsdbEkqKWkvDTmH1CrHSCNXsO01pCGLoO9bfK7+8rnsyTRl/UQ4 vVdHA1rkd5sTxmqQm+G9I2J0rRObGHlTLxfISPNoNb6E8q9WpIr+D7HazkY6Gp3S ig19L0b7wcNtratn7NEIDcEUdhIXnYzEIKALorG62kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=Eft37Lns4YkEJ36plp/aNwYdly FyTkiT1lXqn+6ZhfIuXnvfYIE4NMMyUvRNyvqkW348lhl3ZDY8Eh8i0o7GEp7uVG sFoQbIRbb98i23zOJyakxqenlPqeIn0t+mRzxxh/A9w9kyEldFVh+kvTo+boZUvs 2WjOaEqA7ag6T4rSs= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id EA6A4D7885; Sun, 13 Mar 2016 12:52:41 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7B388128AFD8; Sun, 13 Mar 2016 20:52:37 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_56239934-257D-4B0D-A457-20F99DC399B0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Sun, 13 Mar 2016 20:52:36 +0100 Message-Id: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> References: <56E318C7.5020200@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 19:52:46 -0000 --Apple-Mail=_56239934-257D-4B0D-A457-20F99DC399B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, >> - Parsing EHs is and the consequence of having to walk the extension = header chain is a well known problem. >> If the premise is that we want this to work well for arbitrary = middleboxes, the solution space is empty. >> - HBH headers is a well known problem. One draft in 6man as well as = changes in 2460bis. >> - The ECMP problem is well known. We tried to solve it with flow = label, in practice the IP header has evolved to be 24 / 44 bytes = respectively. >=20 > Where are these 24 / 44 byte IP headers described? in every router / middlebox on the planet. (and somewhat tangential for = any RFC describing shared IPv4 addresses) e.g (from VPP): /* Compute flow hash. We'll use it to select which Sponge to use for = this flow. And other things. */ always_inline u32 ip6_compute_flow_hash (ip6_header_t * ip, u32 flow_hash_config) { tcp_header_t * tcp =3D (void *) (ip + 1); u64 a, b, c; u64 t1, t2; uword is_tcp_udp =3D (ip->protocol =3D=3D IP_PROTOCOL_TCP || ip->protocol =3D=3D IP_PROTOCOL_UDP); t1 =3D (ip->src_address.as_u64[0] ^ ip->src_address.as_u64[1]); t1 =3D (flow_hash_config & IP_FLOW_HASH_SRC_ADDR) ? t1 : 0; t2 =3D (ip->dst_address.as_u64[0] ^ ip->dst_address.as_u64[1]); t2 =3D (flow_hash_config & IP_FLOW_HASH_DST_ADDR) ? t2 : 0; a =3D (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t2 : t1; b =3D (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t1 : t2; b ^=3D (flow_hash_config & IP_FLOW_HASH_PROTO) ? ip->protocol : 0; t1 =3D is_tcp_udp ? tcp->ports.src : 0; t2 =3D is_tcp_udp ? tcp->ports.dst : 0; t1 =3D (flow_hash_config & IP_FLOW_HASH_SRC_PORT) ? t1 : 0; t2 =3D (flow_hash_config & IP_FLOW_HASH_DST_PORT) ? t2 : 0; c =3D (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? ((t1<<16) | t2) : ((t2<<16) | t1); hash_mix64 (a, b, c); return (u32) c; } Best, Ole --Apple-Mail=_56239934-257D-4B0D-A457-20F99DC399B0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW5cUFAAoJEL7aWKiYQt92GHIQALEWYVNLbwCHFSY/nEb/yTBU nQK/G2whvxGvGyV8Y4PQbZlv9zjhS0SdMBWdoqaWaVJMGe6MnqUw02B9Gs/SpH9u sTJ9ZHIEt+mvI2hoCw18UPfjT3eBxHCP3e9j72nFv49LDLQlby9Pb0zXDPJKCf4R sS8ARa0Rx8NV9sOXf4AnxtF5n8wg4el8tNykIhCpYbmxvV9LTZnvqMS3px7uOF7m uec6MjiyHNmW5a4om/UP9POxOeuOYI0zet83hPV10mC9OP3aOiXdAbH8H7rfhPLN 79NvN2kGr4WwogtbDKrvERgrcTNngYnpvtAt6lOzhckOUY6AfMlZH1s4jHYPKp/X XgjK45cBtKYqCx4nRxWS2jlHtyawaWh/L+g39DB7fhG+AHknDOJlrOPQl5JOY9JW Y93/NeO3Nv+lfGoOz66GM+hqPma2bKfJPOsWCMobZnwdgJTEMR51o84Sx7ZEDbEp oVaooSiEplwfYKeTmmXuMmcJZcXfVK031JJ8vDQ8IlnzOubMxfmxY2aKNl5WGiWV Jqrm5xciaqHruzx2wJtqKn3lJwWtfIXTyb+aeu+eVHaoop6MV/5M0BdPOa4iw3dQ V6IqlCHPwfmElH4iJc5h7PmsLkpXtc9YS0pBsX0Re0TAuz1+xrse4inIKxBSYYuJ A7JlCkcCw0J5QdGrwBN7 =ior/ -----END PGP SIGNATURE----- --Apple-Mail=_56239934-257D-4B0D-A457-20F99DC399B0-- From nobody Sun Mar 13 13:34:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3669312D805 for ; Sun, 13 Mar 2016 13:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw10G0u2NWHJ for ; Sun, 13 Mar 2016 13:34:37 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4947912D820 for ; Sun, 13 Mar 2016 13:34:36 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id C5E8BD7885; Sun, 13 Mar 2016 13:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=uVDBS1e34fUt1AwDaV3Bo7uyp7U=; b= qRCE5v2GLPMEl05QV3fMdV7SAB6L50QY8orVChF8u8dZjUIL4WB8dzGJKXhE0WQS zVl/KPYCpoVcYkhdCEbXwmrAA93x5kreq/xFfx5/K1WZK89j6frmUEpSxRsa5H6w Z15ofzc1saHzMRAdIiKvbbKxqHJ5MMlg1vodCUrX5Hw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=Fu7pp054W6zVgbGKetyuxyHV7Z plFyMmeRSnaDkFsZbG5i90tma/5F+On2DwJ/2OoZ7lX6yqmRG7psKbrNSpzGUQXc lorivtvBWIdz6Okn0BFI4MV7/F9SYVhGYbkLmU9V3SwyJzBrfTh876C1CZpkIWzX ZQYLOZaLkt06MVK34= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 4C61BD7882; Sun, 13 Mar 2016 13:34:34 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1A5C7128D139; Sun, 13 Mar 2016 21:34:31 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3A8836F7-6345-4F42-A400-728DCE07CDB9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Sun, 13 Mar 2016 21:34:30 +0100 Message-Id: <6B813E27-F848-44DD-A504-C465AE196127@employees.org> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> To: Mark Smith X-Mailer: Apple Mail (2.3112) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 20:34:39 -0000 --Apple-Mail=_3A8836F7-6345-4F42-A400-728DCE07CDB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, > > > Have some questions from MLD Snooping switch point of view. > > > > > > If there are no Routers involved, it is Snooping switch = responsibility to send MLD Query to keep the groups alive on the switch. > > > What is the correct correct Source IP to use for General Queries ? = Is it Src IP all 0 or some link-local Address ? Which host stack would = like/accept what Source IP ? Have observed different observations with = different host stacks. > > > > see rfc4541. > > > > > Also, per discussion below - what is the right behavior for = snooping switch when it comes to link-local multicast groups - flood or = snoop ? It would be good to have a standard practice for this. > > > > it depends on the platform and how big forwarding table your switch = can handle. > > as far as I many switches flood,( and if you want my personal = opinion, we should change hosts so that they no longer send MLD joins = for link-local groups.) > > >=20 > And I think the people complaining about MLD for LL groups may then = complain when their hosts start receiving too many multicasts because = they're flooded. >=20 > I'd like to know more about these sorts of issues. What specific = resource is being exhausted in the switch? TCAM? How many hosts are = attached to the link - I'm wondering if, as a /64 effectively provides = no limits at layer 3, people are now expecting to attach many more hosts = to a link than they would and have with IPv4. with IPv6 it isn't the number of hosts connected, it is the number of = addresses used. (and it is sometimes quite hard in IPv6 to know which addresses are = still active). it is all about carving of TCAM space. see e.g. = http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-x-= series-switches/data_sheet_c78-584733.html?cachemode=3Drefresh look for "scalability numbers" I would assume this is a quite typical switch. cheers, Ole --Apple-Mail=_3A8836F7-6345-4F42-A400-728DCE07CDB9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW5c7WAAoJEL7aWKiYQt92K9UP/jUytlHnLxQNfkseYyv74eyG /JgWyxjVkPkmv4DcMJ007rPk432oScoOkUEfonnGNvCA6z049Tj0hp+QqwLPourw KCQtsXJ0vk/03OZAeCwtaFaqmFMpORgYtpgPLH14bEIk8se7DXZPn0FDxoKRpoLe kh2cCHirr2wWB7/DnBLj2mVU8SDbXGMjjTWEnG76rAb/wOJQhE4Sr19qz/T7au91 H8w1hRnR3INJkxOtkfulNhvo2vFHvecmjxHHjp4IpK1C23pJbMmMafQiwG7mlaqO Un2eBEA/1ARhLoD9I2nVwBZelOsZWNrFQ81GOho7455Mwut79LBljySk1pkXFd+p 9e4uPZejQA+ijcGrHUm1F0wdq2gJWmjN89mDOfr8bn4arL9y205cOtZeW9y8AfOk Zq8I7h19DqF5fo63YPo75Lu8X6ytZZk3tlbc+kNOCdXGwPRAkVyAxJi8w5Xinpfj iAbiHlVOW5CwV0v6JUTsxpbEvzoHVYnnnZV+JBCD9u04O5XZ2g1hWgTavOo5+Eiz tqHmbv9Rrze6WycOqfm4atPhi2X2xG/6BpMN32GQNamaOjlGMGr1LtZQLdmAgq2V woiGmZqo9bqfSLlOMebP24hKuwdlc4LL550w8PDd3CdQUuzEsI3DbwTb5DKFNg/b skfHZFMhyu28cO6gNOHI =gufC -----END PGP SIGNATURE----- --Apple-Mail=_3A8836F7-6345-4F42-A400-728DCE07CDB9-- From nobody Sun Mar 13 13:54:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43612D898 for ; Sun, 13 Mar 2016 13:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OwIJxrI4Z8l for ; Sun, 13 Mar 2016 13:54:50 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A1112D7F7 for ; Sun, 13 Mar 2016 13:54:49 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2DKseEu035315 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Mar 2016 20:54:42 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org Message-ID: <56E5D38F.7080507@foobar.org> Date: Sun, 13 Mar 2016 20:54:39 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: otroan@employees.org References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> In-Reply-To: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 20:54:53 -0000 otroan@employees.org wrote: > in every router / middlebox on the planet. (and somewhat tangential > for any RFC describing shared IPv4 addresses) > > e.g (from VPP): i.e. when the packet processor can see the tcp/udp ports, the flow hash generally ends up being an n-tuple similar to: fh(flowlabel, srcip, dstip, srcport, dstport) In this case, protocol is also added in, but this value will be tied tightly to similar srcport and dstport values, so its overall contribution to entropy is low. If the packet processor can't see the tcp/udp src/dst ports due to excessive amounts of EHs, then this n-tuple drops to: fh(flowlabel, srcip, dstip, 0, 0) In practice, the flow label is often set to zero, giving: fh(0, srcip, dstip, 0, 0) The point of the draft is to note that excessive EHs will contribute to a deterioration of entropy in flow hash inputs and that this has operational consequences. Nick > > /* Compute flow hash. We'll use it to select which Sponge to use for this > flow. And other things. */ > always_inline u32 > ip6_compute_flow_hash (ip6_header_t * ip, u32 flow_hash_config) > { > tcp_header_t * tcp = (void *) (ip + 1); > u64 a, b, c; > u64 t1, t2; > uword is_tcp_udp = (ip->protocol == IP_PROTOCOL_TCP > || ip->protocol == IP_PROTOCOL_UDP); > > t1 = (ip->src_address.as_u64[0] ^ ip->src_address.as_u64[1]); > t1 = (flow_hash_config & IP_FLOW_HASH_SRC_ADDR) ? t1 : 0; > > t2 = (ip->dst_address.as_u64[0] ^ ip->dst_address.as_u64[1]); > t2 = (flow_hash_config & IP_FLOW_HASH_DST_ADDR) ? t2 : 0; > > a = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t2 : t1; > b = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t1 : t2; > b ^= (flow_hash_config & IP_FLOW_HASH_PROTO) ? ip->protocol : 0; > > t1 = is_tcp_udp ? tcp->ports.src : 0; > t2 = is_tcp_udp ? tcp->ports.dst : 0; > > t1 = (flow_hash_config & IP_FLOW_HASH_SRC_PORT) ? t1 : 0; > t2 = (flow_hash_config & IP_FLOW_HASH_DST_PORT) ? t2 : 0; > > c = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? > ((t1<<16) | t2) : ((t2<<16) | t1); > > hash_mix64 (a, b, c); > return (u32) c; > } > > Best, > Ole > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Mar 13 13:59:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF98212D804 for ; Sun, 13 Mar 2016 13:59:12 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h81EhpTiYEQ0 for ; Sun, 13 Mar 2016 13:59:11 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8CF12D81F for ; Sun, 13 Mar 2016 13:59:10 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id m184so202067033iof.1 for ; Sun, 13 Mar 2016 13:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=12baghABN9VttuCinXyu/PfXljskPINZoqqyhP+dHuc=; b=Yzq1Pf9gw0I1s22gP+7hD6X2UFlZkqZmRfy+LJKc2CEJHodpbA/9o98JeU5QgpYWpC 257ymQVluF2ctqI99sQGthmvOn5cQGeJtyZ13FtaM/pKN9EPqtbizKVk/i9iz+Ekittx 8Nrc1z35SOx8zZt5EkwcP4sBBaPHacoMPj1QvCzoVRcYXKeceMKGFLd7y7Wg66fOnufc ZBGkmbn/XcSPC2DBJVesT87CslZRcxmjyAGO8b2twzxTBfLMYVJCurNZjAskeQh2xkND Kh509vpHuGeqtMqos38BGw+DBJtmle5/tMxJXqTDr9it+mTHOoLa40HjqiY/hrtN8ccG LIoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=12baghABN9VttuCinXyu/PfXljskPINZoqqyhP+dHuc=; b=XFO8N/bk5A81L+4xqnpc0l1lArUKD3kKT4hn9oE7TqIcfTXOWdn5aUR2VCHLKmsfjy m68aj5D7ogFNo/zzkyn4ilrprFpYhhxXRJwv7P2VZIdTU5hoCKfTqQeHSwdHry23CJVx 7+ldHDlbCm9wGmn5q4JhbtbsTzDG3L6g0T1jMANf+8rmY/C6bvc85mBopbwD2ibWO78u 9PWTdMGtTjKPmK1kID0Kx7Qh7rZn9yMJWy3l4aHopEYx3RN7rULsjFFeh5WhnvDqpFAe pUfxfqgWMKtT99bz4w9y0VbZEtgx/EYrRSSC5v5VXN5cLf+rh60Xg6k23pfYIC+c0hCX aVyg== X-Gm-Message-State: AD7BkJIbjm7rgYJndbsax0TrEsDgHLsqoJAycAXEaYK28GoT5J8HCNvoOPEUEDz+jRrFdf6ERW7NyszjhIuyTQ== MIME-Version: 1.0 X-Received: by 10.107.158.12 with SMTP id h12mr23129786ioe.107.1457902750341; Sun, 13 Mar 2016 13:59:10 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Sun, 13 Mar 2016 13:59:10 -0700 (PDT) In-Reply-To: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> Date: Sun, 13 Mar 2016 13:59:10 -0700 Message-ID: From: Tom Herbert To: otroan@employees.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 20:59:14 -0000 On Sun, Mar 13, 2016 at 12:52 PM, wrote: > Tom, > >>> - Parsing EHs is and the consequence of having to walk the extension header chain is a well known problem. >>> If the premise is that we want this to work well for arbitrary middleboxes, the solution space is empty. >>> - HBH headers is a well known problem. One draft in 6man as well as changes in 2460bis. >>> - The ECMP problem is well known. We tried to solve it with flow label, in practice the IP header has evolved to be 24 / 44 bytes respectively. >> >> Where are these 24 / 44 byte IP headers described? > > in every router / middlebox on the planet. (and somewhat tangential for any RFC describing shared IPv4 addresses) > Ole, This is not the way it works for *every* middlebox on the planet. For instance, in Linux we can deduce a flow hash from ports-- not just for TCP and UDP but for SCTP, DCCP, UDP-lite, etc.--, GRE key ID, MPLS entropy label, IPv6 flow label, SPI in AH and ESP, parse over extension headers, and also can parse into several encapsulation protocols to find L4 information (GRE, IPIP, IPv6/IP). See http://lxr.free-electrons.com/source/net/core/flow_dissector.c#L121. Even if I accepted that we are pragmatically limited with only ever using TCP and UDP without extensions headers on the Internet, I will never accept these as constraints in my private networks! We are and will using other IP protocols, encapsulation, EH, etc. IPv6 flow label is therefore a general solution; it works with any IP protocols we might use, extension headers, etc., it is straightforward to add into hash computation in devices. With the flow label, none my fabric switches need to parse beyond the 40 byte IPv6 header in order to provide ECMP. Most of the arguments against extension headers seem to be because they are difficult to parse, however the point of using flow label is that it eliminates the need to parse extension headers in the first place for the ECMP use case. It would be nice if this benefit was and the need for flow label support were better enunciated in the draft. IMO any opportunity we have to get intermediate devices to do less deep packet parsing without loss of functionality is a good thing! Tom > e.g (from VPP): > > /* Compute flow hash. We'll use it to select which Sponge to use for this > flow. And other things. */ > always_inline u32 > ip6_compute_flow_hash (ip6_header_t * ip, u32 flow_hash_config) > { > tcp_header_t * tcp = (void *) (ip + 1); > u64 a, b, c; > u64 t1, t2; > uword is_tcp_udp = (ip->protocol == IP_PROTOCOL_TCP > || ip->protocol == IP_PROTOCOL_UDP); > > t1 = (ip->src_address.as_u64[0] ^ ip->src_address.as_u64[1]); > t1 = (flow_hash_config & IP_FLOW_HASH_SRC_ADDR) ? t1 : 0; > > t2 = (ip->dst_address.as_u64[0] ^ ip->dst_address.as_u64[1]); > t2 = (flow_hash_config & IP_FLOW_HASH_DST_ADDR) ? t2 : 0; > > a = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t2 : t1; > b = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t1 : t2; > b ^= (flow_hash_config & IP_FLOW_HASH_PROTO) ? ip->protocol : 0; > > t1 = is_tcp_udp ? tcp->ports.src : 0; > t2 = is_tcp_udp ? tcp->ports.dst : 0; > > t1 = (flow_hash_config & IP_FLOW_HASH_SRC_PORT) ? t1 : 0; > t2 = (flow_hash_config & IP_FLOW_HASH_DST_PORT) ? t2 : 0; > > c = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? > ((t1<<16) | t2) : ((t2<<16) | t1); > > hash_mix64 (a, b, c); > return (u32) c; > } > > Best, > Ole From nobody Sun Mar 13 14:17:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248B712D835 for ; Sun, 13 Mar 2016 14:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQOG23gusygA for ; Sun, 13 Mar 2016 14:17:06 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1076612D805 for ; Sun, 13 Mar 2016 14:17:05 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 95234D7887; Sun, 13 Mar 2016 14:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=QxgoCje4IvwReInZg9qvDymnNtI=; b= e//7u+Fgv64Ti7/hPaQmRKnt4d2kwt1TPBHO6A4nomTY7W3lt8/b1yhez+Zg4jCi +YyDaOPvC8pGPwkOeq8tfnOCJd1jMJwqe+YjhmTTWunWjHTtC1BA88dfTL8QHvSB /R3ToQjiZHwKJxef7ktv2+uHK3W+mQtJ9H5AxbkntL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=jJ1pfL+H9kIrRasiN8/Ao7kYI5 Qu2WH5OqR3uve4wOHjOVo1OPBcMPbNrXOPfnFUQ+FxzL/60GsitPjaDXmMd1qKv/ ogAWcsy4JMZwQVZSiBLZ/UvtQzmatGCbgEPFW6OPturgHosGh0eEHcB+Ww/EA+t3 FEhGWXMp4J7eOOcno= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 12918D7885; Sun, 13 Mar 2016 14:17:04 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2F7AE128D7CD; Sun, 13 Mar 2016 22:17:02 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E2EA1010-5E12-47A3-91E3-8B172A58E76A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Sun, 13 Mar 2016 22:17:01 +0100 Message-Id: <718B2297-9FE1-40F6-923F-1C7D9C43AC29@employees.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> To: Tom Herbert X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 21:17:09 -0000 --Apple-Mail=_E2EA1010-5E12-47A3-91E3-8B172A58E76A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Tom, > This is not the way it works for *every* middlebox on the planet. For > instance, in Linux we can deduce a flow hash from ports-- not just for > TCP and UDP but for SCTP, DCCP, UDP-lite, etc.--, GRE key ID, MPLS > entropy label, IPv6 flow label, SPI in AH and ESP, parse over > extension headers, and also can parse into several encapsulation > protocols to find L4 information (GRE, IPIP, IPv6/IP). See > http://lxr.free-electrons.com/source/net/core/flow_dissector.c#L121. > > Even if I accepted that we are pragmatically limited with only ever > using TCP and UDP without extensions headers on the Internet, I will > never accept these as constraints in my private networks! We are and > will using other IP protocols, encapsulation, EH, etc. IPv6 flow label > is therefore a general solution; it works with any IP protocols we > might use, extension headers, etc., it is straightforward to add into > hash computation in devices. With the flow label, none my fabric > switches need to parse beyond the 40 byte IPv6 header in order to > provide ECMP. > > Most of the arguments against extension headers seem to be because > they are difficult to parse, however the point of using flow label is > that it eliminates the need to parse extension headers in the first > place for the ECMP use case. It would be nice if this benefit was and > the need for flow label support were better enunciated in the draft. > IMO any opportunity we have to get intermediate devices to do less > deep packet parsing without loss of functionality is a good thing! Fully agree. Wouldn't it be nice. I don't see how this particular draft helps here though. Best regards, Ole --Apple-Mail=_E2EA1010-5E12-47A3-91E3-8B172A58E76A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW5djNAAoJEL7aWKiYQt928IoQAJUgaJMD/IgH7VcftmQsFajX Y+jXi2s6xUv7eLoLuW+m/ajCdw8rEnnYeuOV/cehQFYJ+DbLbq+3RCwSAkpMOX7n 7IKpxf9jgLNadZ5IcyT88hIU/6cm+qzIhzLJnSe7RG5tKN3qySCvp0xhG73vCyx0 2ttqzyrAz19dILnwo4Ea1oxixO6k716wBBVVuLTTeba32gvbdsnd/IDpadyiwruH PrxIB180MNWhU/38GkwUixpYhD9p/95ZX+YCybOkWUBtDj0oW7aVHssyUEE/KHoc ZQlEYYepXprkmNGkKDUAQujtG3G/fLwmt9Avol0T9WD0OxPDaac0b9EJbe6dlQNf bPRshfio0TAJfauet3RnCyucW5rrRSgE1hQ94u9qDBHbkmEeMUTI2VFanVmnb6MC W+wIo2lyb0fLJVlRtEDff+evTEa1faVAOOmHnlj7TOIehpmlRtfpsDNib1Wc9Xae et3pHWHBsT5fxHRmEvMiJWwCY7ULQbUvMyPzXskjDB30LwDyT9kkpBhmbyBMVIxh DjXKv523Aqb/VcWqRhpUr9avIEmYrMW/H0jfKKBF6OnQV+W6FlySQjfQECasd9pv KOpiI8Tab1bCRl52gP1e4l8YcMd+92vkzaigOwwNm89KD5xXALMWlbbrmv8WKOeU rK9f+uBPFAQvGVmNTu7N =JLbq -----END PGP SIGNATURE----- --Apple-Mail=_E2EA1010-5E12-47A3-91E3-8B172A58E76A-- From nobody Sun Mar 13 15:33:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1DF12D875 for ; Sun, 13 Mar 2016 15:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1t4SSiawRdz for ; Sun, 13 Mar 2016 15:33:00 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2FF12D87B for ; Sun, 13 Mar 2016 15:33:00 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id e6so189161090vkh.2 for ; Sun, 13 Mar 2016 15:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5bRXtmCeLh/abNkZlT4mNZ1TEt1fUfrULlOvU02KWd8=; b=SfDx2Ls8EP7KsbX8bruobJcLqXbaS+NxossXFYwGhy7Haz+9zypJtjv3G+wDG9UJf2 t+PWl56l9l4pFa2hK68EQAH7w6+SJ05z/lFZeHaE8nebvh8sbuLbEohW6/Nl4VNux0A/ /Zw4sMJPkIs0PBFPH9H2C6ZhJGGCJBhj136iQPwDzjg/nPv49eCPhaBL2tLtEZxQbgpX cl/A7mXc+AuXYCF1Ve2RjUkMT44wi9fpiRhpVGaL4n/B7z+TRw4HJQUrTYl7da6Ej7oU pA7qsAO/7CQhuNWcYGRRE3zDHk/RixVbGVkQWG/k6ge7ewYo8QNd/3V2rgoDMbYS2JZr Bnmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5bRXtmCeLh/abNkZlT4mNZ1TEt1fUfrULlOvU02KWd8=; b=Q8/5Slb/AEh/YxMtDNwaMwXF+IBCosXl8jCfqHEvXbKCP5suvmPpl30PoL0gmgY+et b+LnSl+917746mOBzfMcLJc3TN4sehgzrvWH3G4Wgi1BDSnJyKFdEoRp5E/eftw7c15i 24dMt++crZOkqA4+3OtISURmD7heNhe9XH+EELn+C4SeY+HRJJ3bew+eWcADBYBi4Uk+ TFsym+uSlVQ3KSPmnTVDY8LW1LGxoSD40brsZs6BpGXKo9LE1Ypd0Df1T6TH1a4EDUIC fVXIShEYS+XWnbmKYAj8zX1KpPRpbanm944sEAsDSy5VfVinlI6vbrnusCftLi+QiHr0 MlQQ== X-Gm-Message-State: AD7BkJIqc1QKmez9VTq+QXGB/RhHdJ9FXijVf4YTqVeHLGufJLBr2bSXhDpNyKPy0CoprFb+G/sm2840jv6Kdw== X-Received: by 10.31.48.216 with SMTP id w207mr22285491vkw.36.1457908379709; Sun, 13 Mar 2016 15:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.5.68 with HTTP; Sun, 13 Mar 2016 15:32:30 -0700 (PDT) In-Reply-To: <6B813E27-F848-44DD-A504-C465AE196127@employees.org> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> <6B813E27-F848-44DD-A504-C465AE196127@employees.org> From: Mark Smith Date: Mon, 14 Mar 2016 09:32:30 +1100 Message-ID: To: Ole Troan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 22:33:02 -0000 Hi Ole, On 14 Mar 2016 07:34, wrote: > > Mark, > > > > > Have some questions from MLD Snooping switch point of view. > > > > > > > > If there are no Routers involved, it is Snooping switch responsibil= ity to send MLD Query to keep the groups alive on the switch. > > > > What is the correct correct Source IP to use for General Queries ? = Is it Src IP all 0 or some link-local Address ? Which host stack would like= /accept what Source IP ? Have observed different observations with differen= t host stacks. > > > > > > see rfc4541. > > > > > > > Also, per discussion below - what is the right behavior for snoopin= g switch when it comes to link-local multicast groups - flood or snoop ? It= would be good to have a standard practice for this. > > > > > > it depends on the platform and how big forwarding table your switch c= an handle. > > > as far as I many switches flood,( and if you want my personal opinion= , we should change hosts so that they no longer send MLD joins for link-loc= al groups.) > > > > > > > And I think the people complaining about MLD for LL groups may then com= plain when their hosts start receiving too many multicasts because they're = flooded. > > > > I'd like to know more about these sorts of issues. What specific resour= ce is being exhausted in the switch? TCAM? How many hosts are attached to t= he link - I'm wondering if, as a /64 effectively provides no limits at laye= r 3, people are now expecting to attach many more hosts to a link than they= would and have with IPv4. > > with IPv6 it isn't the number of hosts connected, it is the number of add= resses used. > (and it is sometimes quite hard in IPv6 to know which addresses are still= active). > I realise that. In IPv4, addresses to hosts on a link has been 1:1 in nearly all cases, and in my experience, most IPv4 subnets have been /24s (usually facilitated by the big address space of RFC1918, and most likely for the convenience of having an easy to work with subnet/host boundary). So the size of most IPv4 networks has been commonly limited to no more than ~250 hosts, which I think would have made it very unlikely that those networks would encounter any layer 2 constraints other than unicast bandwidth. As IPv6 /64s lifts that ~250 host self imposed limitation, I think we'll now experience a time and maybe are already experiencing a time where people who don't have any other experience than IPv4/RFC1918s/switched networks will now discover what the actual practical limits of the number of hosts they can attach to their links are when they deploy IPv6, and these practical limits won't always be unicast capacity. > it is all about carving of TCAM space. > see e.g. http://www.cisco.com/c/en/us/products/collateral/switches/cataly= st-3750-x-series-switches/data_sheet_c78-584733.html?cachemode=3Drefresh > look for "scalability numbers" > So I think the scalability section shows that these layer 3 inspection functions in a layer 2 device have been optimised for IPv4, as the number of IGMP groups and multicast routes doesn't change for any of the modes, despite the number of unicast related capacities changing across all the modes, and the Unicast MAC addresses capacity tripling between the Access and VLAN modes. IPv4 and IPv6 are obviously different enough that IPv4 focussed optimisations aren't necessarily going to work or work as well with IPv6. I think over time we'll see IPv6 focussed optimisations in switches as the protocol becomes more widely deployed (perhaps a software update to the above switch could make the IGMP groups and multicast routes capacity change too for the different modes?) Regards, Mark. > I would assume this is a quite typical switch. > > cheers, > Ole From nobody Sun Mar 13 16:05:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0DE12D84F for ; Sun, 13 Mar 2016 16:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VAZQw2E8Zhb for ; Sun, 13 Mar 2016 16:05:33 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F5412D803 for ; Sun, 13 Mar 2016 16:05:33 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id e185so189548972vkb.1 for ; Sun, 13 Mar 2016 16:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nIkoEmtNshzkdzyZhEQ3ws2jizlBs2bASEu69/4iNXs=; b=KYu/lKmCSWt8YWQmPcgcGl3X2N+Ge7XLpoW5TtSJdsxTl9gz3YaB/YLqqw2MgwBsVN 7mLvQ6Alz5TCjtuUNPIuoiR1qneRa7Pvz2++AI/qCVwlbLsJURvus6e9LFGdlWaFM5iW v/fSbQdi2BpJQeC3I9e8MTQ2Ys5ETrkJpu679fSaEjTqZwNqZk/MXOJRl4ZLRixGMzms jYcR+ecGkRvDtJWD4T0TC8S/8dApATXxRnr5iD3saYLC3K+Gjv1ioIsNRgLMmuhCb01a gTAk4SkjRUjkzL5+uIdMPuKoy3Y9Qhhw9/V/mdnLqJN0BqpufTz9hwcp4OczAxU9hBP8 zw4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nIkoEmtNshzkdzyZhEQ3ws2jizlBs2bASEu69/4iNXs=; b=F0TyfM7b5stY5T1JJ6U8KUDRU4ZGtg2bRNhzseH9pDyQOrPXiwMdexhIhaQjei3Dvy 3IPm/vTFKdWVsJylHPX64bqcBzD6I0oWXh4LNGRKzPRkDVuob+i8IsgVQbA/m5HAqatH Lc50RKy5aP7wFkDry1jScQJRKEdCrPTLiyMsTSLl79mMVUpPepyz//N172tag4KaUGuS Gk5TQ5p9XRZmcl+X+0HiI2bzKMuioMcAQ/MCt1sfv0HG2G98/bd6wyZTm3TEYdRJUkR4 +c7IDI6KqfRbCeK7aaP0h0Ejp86mNy3B3ZopyVIPxrgxChPZLLINwT8w2HdZg4VxgOVp eIEA== X-Gm-Message-State: AD7BkJK52F04RalJkzI41y47Gv63rKgn+L8g0edIIoDJ+bx8K2RQUG2Ir6+ALwW5zrdDeCPFK9HD9t4H7Q5SdQ== X-Received: by 10.31.128.82 with SMTP id b79mr22096081vkd.47.1457910332567; Sun, 13 Mar 2016 16:05:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.5.68 with HTTP; Sun, 13 Mar 2016 16:05:03 -0700 (PDT) In-Reply-To: <56E5D38F.7080507@foobar.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E5D38F.7080507@foobar.org> From: Mark Smith Date: Mon, 14 Mar 2016 10:05:03 +1100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 23:05:35 -0000 On 14 March 2016 at 07:54, Nick Hilliard wrote: > otroan@employees.org wrote: >> in every router / middlebox on the planet. (and somewhat tangential >> for any RFC describing shared IPv4 addresses) > > > The point of the draft is to note that excessive EHs will contribute to > a deterioration of entropy in flow hash inputs and that this has > operational consequences. > So in the medium term, the specific use of LAG and/or ECMP to bundle links, and their desire to look at transport layer headers, might disappear. I came across work on "Flex Ethernet" the other day, and one thing it seems to be looking to do is to solve the problem of link bundling without the dependencies on layer 2/3/4 field values. "What is FlexEthernet?" http://www.ethernetsummit.com/English/Collaterals/Proceedings/2015/20150415_1C_Gustlin.pdf "Flex Ethernet Implementation Agreement" http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-01.0.pdf Regards, Mark. From nobody Sun Mar 13 16:30:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC4412D775 for ; Sun, 13 Mar 2016 16:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTbcgPQI1QHT for ; Sun, 13 Mar 2016 16:30:26 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBA612D829 for ; Sun, 13 Mar 2016 16:30:24 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from [10.230.100.84] (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2DNUI2L039811 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Mar 2016 23:30:18 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be [10.230.100.84] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Nick Hilliard X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Sun, 13 Mar 2016 23:30:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8EE27F32-CE30-459B-ACED-4ACA8AA6E79B@foobar.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E5D38F.7080507@foobar.org> To: Mark Smith Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 23:30:28 -0000 On 13 Mar 2016, at 23:05, Mark Smith wrote: > So in the medium term, the specific use of LAG and/or ECMP to bundle > links, and their desire to look at transport layer headers, might > disappear. I came across work on "Flex Ethernet" the other day, and > one thing it seems to be looking to do is to solve the problem of link > bundling without the dependencies on layer 2/3/4 field values. flexethernet will solve a different set of problems to what we're talking ab= out here. I don't see any point in the foreseeable future where lags and ecm= p will stop being relevant.=20 Nick > "What is FlexEthernet?" > http://www.ethernetsummit.com/English/Collaterals/Proceedings/2015/2015041= 5_1C_Gustlin.pdf >=20 > "Flex Ethernet Implementation Agreement" > http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-01.0.pdf >=20 > Regards, > Mark. From nobody Sun Mar 13 16:45:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F41B12D838 for ; Sun, 13 Mar 2016 16:45:40 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl-V9-e2ZHBQ for ; Sun, 13 Mar 2016 16:45:37 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6885112D501 for ; Sun, 13 Mar 2016 16:45:37 -0700 (PDT) Received: from [172.20.15.144] (port-213-160-6-163.static.qsc.de [213.160.6.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C4AFC80800; Mon, 14 Mar 2016 00:45:32 +0100 (CET) To: otroan@employees.org, Tom Herbert References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <718B2297-9FE1-40F6-923F-1C7D9C43AC29@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56E5FB6D.60109@gont.com.ar> Date: Sun, 13 Mar 2016 20:44:45 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <718B2297-9FE1-40F6-923F-1C7D9C43AC29@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 23:45:40 -0000 On 03/13/2016 06:17 PM, otroan@employees.org wrote: > Tom, > >> This is not the way it works for *every* middlebox on the planet. For >> instance, in Linux we can deduce a flow hash from ports-- not just for >> TCP and UDP but for SCTP, DCCP, UDP-lite, etc.--, GRE key ID, MPLS >> entropy label, IPv6 flow label, SPI in AH and ESP, parse over >> extension headers, and also can parse into several encapsulation >> protocols to find L4 information (GRE, IPIP, IPv6/IP). See >> http://lxr.free-electrons.com/source/net/core/flow_dissector.c#L121. >> >> Even if I accepted that we are pragmatically limited with only ever >> using TCP and UDP without extensions headers on the Internet, I will >> never accept these as constraints in my private networks! We are and >> will using other IP protocols, encapsulation, EH, etc. IPv6 flow label >> is therefore a general solution; it works with any IP protocols we >> might use, extension headers, etc., it is straightforward to add into >> hash computation in devices. With the flow label, none my fabric >> switches need to parse beyond the 40 byte IPv6 header in order to >> provide ECMP. >> >> Most of the arguments against extension headers seem to be because >> they are difficult to parse, however the point of using flow label is >> that it eliminates the need to parse extension headers in the first >> place for the ECMP use case. It would be nice if this benefit was and >> the need for flow label support were better enunciated in the draft. >> IMO any opportunity we have to get intermediate devices to do less >> deep packet parsing without loss of functionality is a good thing! > > Fully agree. Wouldn't it be nice. > I don't see how this particular draft helps here though. The reasons being the same I mentioned in my other email: IN the same way as you did a while ago, there seems to be the assumption that the only reason for which packets with EHs are dropped is because middleboxes need the layer-4 information for ECMP, and that that would away with widespread support for the FL. Our I-D makes it clear that that is not the case. I will re-ask my question: where else are these operation considerations covered? (You argued that they are covered elsewhere, but you never said where). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Sun Mar 13 17:51:35 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825DF12D634 for ; Sun, 13 Mar 2016 17:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soVko43o6mxl for ; Sun, 13 Mar 2016 17:51:31 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634CA12D9C1 for ; Sun, 13 Mar 2016 17:51:31 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id td3so117154101pab.2 for ; Sun, 13 Mar 2016 17:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KZjbQHNuzBf/KPQai1tMu29RnLtlORV4SPV+LY0Rhs0=; b=X2VUbaqnN7p9Cizrra6qKpGLwFfKA1hseIZ/gvgQKiS8PoQayCYj6DA9tydCJrQLLH q4k+qxYkpXvmcDCEnsuCVLIT9rb1sQuLoHPSRcGHlXdvUDJvyi70TWa4O7jk93xZPOzf MVc5R1mjDwG7pDgVSO0SaE/bDZ5H/Iwn5VTRJf3UrMraCMahKT61cxnI+wRkT3y33ZJx m7y5zg7cpN3nfPugPM1cYBuSKtBekBlkKy8aJEw3QULTD+7vtKE9w5EbJopKt7KaOwEB q2gRUQzHYjfzxSEYOJrCBPCjZBhk2BvK9EUZGAzQEdZZ/6pr+MwlXJt6BYC0MhOsL6SC CFog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=KZjbQHNuzBf/KPQai1tMu29RnLtlORV4SPV+LY0Rhs0=; b=gThxtPfbLH6almh+0brRCDZb/wFaGoYIr+1ZWgKNKA2mTe2eJ0feIv/fWFU3u0HNHi qTvQevtEn1lO1EMJIWUpKvjdTkNprnfmC+Dkr8XAL2EfjA6qDtQLKtzthE3CEzhSVWxn f8hiRw2pd1ry9sgNbdUJRcXrqiacrP8AqB8qiJWi0I7Hul02yGyrxrQyfRGFSiZUhAcY 27OpJyNE312n0mEvjOMln+xUhEr7WNbeQqIWObsJWYJ9FcfXWpu4fyQms3o+M33Ejxtf qdZfOOn3vTb8xoX9apxlw6zW8hMlfGYS6Rf64NYujihgkohnGh4aHMtTsazhbDn2hb03 yISw== X-Gm-Message-State: AD7BkJLsv2/XUEKnOXxyw4g7CZ0xQ1OEk3JWmBIUOWfHSbNIA6mNq7vFuK+flokbx/IeMQ== X-Received: by 10.66.90.136 with SMTP id bw8mr33892440pab.52.1457916690987; Sun, 13 Mar 2016 17:51:30 -0700 (PDT) Received: from [192.168.88.117] ([103.29.31.50]) by smtp.gmail.com with ESMTPSA id yh5sm27526234pab.13.2016.03.13.17.51.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Mar 2016 17:51:29 -0700 (PDT) To: Tom Herbert , otroan@employees.org References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E60B0D.6070600@gmail.com> Date: Mon, 14 Mar 2016 13:51:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 00:51:33 -0000 On 14/03/2016 09:59, Tom Herbert wrote: ... > the point of using flow label is > that it eliminates the need to parse extension headers in the first > place for the ECMP use case. It would be nice if this benefit was and > the need for flow label support were better enunciated in the draft. I'll be the least likely person on the planet to disagree with that, but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3rd paragraphs of the Introduction) and has been in the IPv6 Node Requirements since 2011 (RFC434). Brian From nobody Sun Mar 13 18:21:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8C12D8F7 for ; Sun, 13 Mar 2016 18:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuPF_nkW-keV for ; Sun, 13 Mar 2016 18:21:13 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5913512D8D5 for ; Sun, 13 Mar 2016 18:21:13 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id e185so191620490vkb.1 for ; Sun, 13 Mar 2016 18:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NI6heZ8riARMzpDSEQCo+BvF1l/nzb86B8k0GB4oS90=; b=L6bvh/RBNClLywXSFynPp6QrDMqnIRBrQd1FKhJG4w/QQIFCcjo1RXs7+wdjwCotOI 3eZf9HaBN/rLOaip7HRqRRT715RkE9JuyQS3vZDyAjkBZdSnIfKH7SKQbhxwpF62deFW a7b8GmTB2XvhIYxlWy/U0iNtJBGiNjx8phS2MqYQ/AOdWCREg4kbfYNsH0PIG7+Q7sRT PewMROF3DY/iFRrRL2p/zxsyGGgQZwJ1gmdYjakrkR4wAugvCo1M/sJvnYPlI+N3xvEE UgMSZW6ch3i8kIEFkfOSpHx/TG0GXUrPzUDansIi6rGlYagRJR+JU0JW19f8EtFGBIVs qn7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NI6heZ8riARMzpDSEQCo+BvF1l/nzb86B8k0GB4oS90=; b=Jccwhkt65SGKsm2jzez4aHgvpm1ssTufSHbChFUEzlkLqlOU0ATf/Qy/y4Eh5z4M9S PvCdrXk1ztqT3Qg/rj6tlH7FP6EqwOTn1z2nsNWEB/+naqXx3bEBjXRnRdJMKvkeYMq+ pKEpaqfreP5QeUaCkKIwtsqKFGT6zS0ZvPs49kDR3piSKkDc7bYZv9LfxUdonI061/o5 MYR8l4d13eg0TKcTtaB9c3jtCQrKTJ9D4vYx/q1sUJ0X735PsQKkZgNn0W1nkhozYvcR 2M6SlWnh4DyAE+ZfEJ1YIwQykGl11BEIQ1y661PFgjGCLnjOSo9DrRr+e1VQdo8KiTKs Z/Ug== X-Gm-Message-State: AD7BkJIicTvPydq3Cr1Q9F2cqh+RWpsR2KBn9KE18W8ThETJB3sDWnl1iRwwrj7h1Fx0qkRuuZEt1f+Ft0lxEA== X-Received: by 10.31.128.82 with SMTP id b79mr22441958vkd.47.1457918472444; Sun, 13 Mar 2016 18:21:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.5.68 with HTTP; Sun, 13 Mar 2016 18:20:42 -0700 (PDT) In-Reply-To: <8EE27F32-CE30-459B-ACED-4ACA8AA6E79B@foobar.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E5D38F.7080507@foobar.org> <8EE27F32-CE30-459B-ACED-4ACA8AA6E79B@foobar.org> From: Mark Smith Date: Mon, 14 Mar 2016 12:20:42 +1100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 01:21:15 -0000 On 14 March 2016 at 10:30, Nick Hilliard wrote: > On 13 Mar 2016, at 23:05, Mark Smith wrote: >> So in the medium term, the specific use of LAG and/or ECMP to bundle >> links, and their desire to look at transport layer headers, might >> disappear. I came across work on "Flex Ethernet" the other day, and >> one thing it seems to be looking to do is to solve the problem of link >> bundling without the dependencies on layer 2/3/4 field values. > > flexethernet will solve a different set of problems to what we're talking= about here. So it might be worth enumerating all of them, as bullet #2 sounds like the problem people are commonly solving with LAG and ECMP, and one that has been mentioned in this discussion. From the Flex Ethernet Implemention Agreement: "5.3 Sample Applications FlexE can support a variety of applications. A non-exhaustive list includes= : * Router to Transport Connection (more examples below). * Intra-Data Center =E2=80=9CFat Pipe=E2=80=9D application: bonded PHYs for= flows exceeding the PHY rate, or carrying traffic that doesn=E2=80=99t distribute efficiently w= ith LAG. * Generalized MLG applications, e.g., an n =C3=97 100G PHY as an umbilicus = to a satellite shelf of lower rate ports." > I don't see any point in the foreseeable future where lags and ecmp will = stop being relevant. > If there is a solution that costs the same or less than them, and doesn't depend on the presence and/or distribution of layer 2/3/4 field values, I think they will stop or become far less relevant. Those networks that rely on LAG or ECMP aren't general purpose any more, as they've been optimised for certain link and upper layer traffic profiles. If you're originating the traffic, you're in control of the traffic profile, so you can ensure the optimisation continues to work. If you're not originating the traffic, there is always a risk the optimisation will fail and there is nothing you can do to prevent it - your customer probably believes they're getting X M/Gbps of any type of traffic, rather than X M/Gbps of type Y traffic that you've optimised for, and they'll probably be angry if you try to raise their price to cover you increase bandwidth costs to deal with their non-optimal traffic. Getting the IETF to prohibit the non-optimal traffic avoids the possibility of dealing with angry customers or increased network costs. I don't think it is intentional, however I think that is what is in effect happening here. The optimisation is understandable, and is caused by the costs imposed by Ethernet's 10x increments. FlexE seems to be specifically addressing that problem, by supporting bundling and therefore smaller link increments, without making assumptions about upper layer header presence, location and field value distribution. Regards, Mark. > Nick > >> "What is FlexEthernet?" >> http://www.ethernetsummit.com/English/Collaterals/Proceedings/2015/20150= 415_1C_Gustlin.pdf >> >> "Flex Ethernet Implementation Agreement" >> http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-01.0.pdf >> >> Regards, >> Mark. From nobody Sun Mar 13 18:54:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BCA12D8F0 for ; Sun, 13 Mar 2016 18:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH1DruLg2csU for ; Sun, 13 Mar 2016 18:54:46 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE3112D8B2 for ; Sun, 13 Mar 2016 18:54:46 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id ig19so51169514igb.1 for ; Sun, 13 Mar 2016 18:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DaP1L7ke/NbIUddoxZ+uXAnTNehrSdzIrrPsN77x/Og=; b=bEPwZ+I1kBSGJYGBdCUcJ7MUf6h1kHLaN1c8UQCqk1xoEl+5bwcAbjAxXWspMQOihM uKMCi6WFmflYSRhuan0TQmrGqXZ8hKpuK09jCJ+W/QqBoMdrxwM/N8qHdU62u80iWdXW vyDSxlMMMoWc6m0Z4cEvzhgQt5ixfnEF9gWrMd6+NpLo3d5EZLNlLj2Hu+V6Viyps+1X M1E3E4LXQl5ykF/+LlgabusgJWAigYYrpoXEISe269K2o2I4RWTtCJ3EmflmQ6LjaPRj f/A57bM2Gsw51bys7ufJmyQCvhZRhHI2sHnTdFK/154EjkzBhh82oJYybVusPtDtm0Df 5uFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DaP1L7ke/NbIUddoxZ+uXAnTNehrSdzIrrPsN77x/Og=; b=FZVnfAtht4BK4f2GsJXJLojKGZ0joQ278B53/LJHp15vIg0IWlqUkjJziFc+yVib4y jDKw7AmVDopUSoX8jIFnKZgFS0ZcxzlXI+LZe0eH4fE2HXek1el4vyVXJgcDBGu1/EQI HjCkNdxoC+VCqwbLQIUrVluSv5fiZuPyScCCotAXavxRa2zOgXTtEdUKKzhQAlVakhWD S+OIUZ4LzYWnf3coycG0Hu92xkO+Esqg12LcGAfN9gqSIxbO+zPb/oBfjArPsAuOJCFx X1d+KiNrYW+9Y/CroM3L4lK9K9LVvb8aOgtzdqbBj8OVq6AFUEbjEMP5kFFfzCt04581 HoFQ== X-Gm-Message-State: AD7BkJLCEnDghLpxRj+0UubKgoE8TQdJud1Ezmr1Kp0HejihlZsqOw+Js9YVTE7phZUouEMmuzdITBrRkriddw== MIME-Version: 1.0 X-Received: by 10.50.23.43 with SMTP id j11mr1204937igf.94.1457920485460; Sun, 13 Mar 2016 18:54:45 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Sun, 13 Mar 2016 18:54:45 -0700 (PDT) In-Reply-To: <56E60B0D.6070600@gmail.com> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> Date: Sun, 13 Mar 2016 18:54:45 -0700 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 01:54:48 -0000 On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter wrote: > On 14/03/2016 09:59, Tom Herbert wrote: > ... >> the point of using flow label is >> that it eliminates the need to parse extension headers in the first >> place for the ECMP use case. It would be nice if this benefit was and >> the need for flow label support were better enunciated in the draft. > > I'll be the least likely person on the planet to disagree with that, > but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3rd > paragraphs of the Introduction) and has been in the IPv6 Node Requirements > since 2011 (RFC434). > Brian, These are good descriptions flow label usage, but I don't see that they set requirements as to 1) whether end host must/should/may send non-zero flow labels with flow entropy 2) whether ECMP devices must/should/may use non-zero flow labels as input to their hash, or 3) if hosts use the flow label for EMCP must/should/may they parse any deeper to extract additional L4 entropy. RFC6438 comes close and answering #1, but that RFC is only applicable to tunnels. Pertaining to this draft, there is an observation that flow labels would obviate the need for middle boxes to parse the header chain, however the draft also states historically neither end nodes nor routers support. It seem like there should at least be a recommendation in "Future work" section on how to attain widespread support flow label. Thanks, Tom > Brian From nobody Sun Mar 13 20:02:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A65B12D924 for ; Sun, 13 Mar 2016 20:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0RJoj06ewDd for ; Sun, 13 Mar 2016 20:02:06 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF3712D787 for ; Sun, 13 Mar 2016 20:02:06 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g127so152394453ywf.2 for ; Sun, 13 Mar 2016 20:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x+OkwmD+RSR2eSjjBXLGa07v1w8/00o4jYBd89Bcf/s=; b=vp4ZrY2FVvmwZpjlyYcIGR9/YAZVJd7Qy8QHa5Ohm66We3QD5+/OmL43Q+7f+VetLg rqRUQhBgGys05PZO7BQkYWggBXaMNc/DdkRC7RzhaaggO8DkMCJdVfMnryfOUS7P9ckt 91dJKPfmYvPxVa7BGCqUCZcBZHzN3afxcp+mEZPTPkVIv7Tg0EBvtaaBtS+FhH9P8Pdh j+kf8h1YcL8//qw1H53YLnmwB3O3ZBSsx/e4thHsIDXyFoghuYSlIIXaCyLusLxuim+L Tu0rVMUndtJf3JBg8+4V/gbIh6QfGbP54cnJH0cD7D4LWVURf44qu9emifbPAipFVw/Q OafQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x+OkwmD+RSR2eSjjBXLGa07v1w8/00o4jYBd89Bcf/s=; b=lqKLUFcuJA7mjfj8wkp6MPd1/GO2UV/O5T+TA4Y9zZDTEbqvq2IJaq6/3qzAqOJhVL RJ8xVUb1Zo7s/lQl7afApIN2rq7GaemSUsIFzt/n4UiBwtnsEm6UM55upVe2zuhqVaCi Sg2OGuLoi8Ssm1NK6mUOhbyUjSfG5UtMqGO5s/xCfUGToeN76QqLvooudOLAmJOP+KH7 rskt2zTtrJXlJFVHdAM0hU25ka1Z8Qi4RXYuMmGsJH16czPERV4AtMI6JaRe03cVdsB7 BTOL8Jy5xXh4lzRGxK64ntFQTZeJF3cbtYiqsmMVqPO+THfSL1djYe6mkMywF0grF6tt VRWA== X-Gm-Message-State: AD7BkJIPVK5WbhSeAADJBPQPjSgrqgNqUaP65Q/aQY1IqexkSEOhjGRFco2vXodbsw6EN+h0ou1HHjvyJkvbVPVJ X-Received: by 10.13.210.67 with SMTP id u64mr10722790ywd.42.1457924525363; Sun, 13 Mar 2016 20:02:05 -0700 (PDT) MIME-Version: 1.0 References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> In-Reply-To: From: Warren Kumari Date: Mon, 14 Mar 2016 03:01:55 +0000 Message-ID: To: Tom Herbert , Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114e7e3071b7b2052df9810b Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 03:02:08 -0000 --001a114e7e3071b7b2052df9810b Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 9:54 AM Tom Herbert wrote: > On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter > wrote: > > On 14/03/2016 09:59, Tom Herbert wrote: > > ... > >> the point of using flow label is > >> that it eliminates the need to parse extension headers in the first > >> place for the ECMP use case. It would be nice if this benefit was and > >> the need for flow label support were better enunciated in the draft. > > > > I'll be the least likely person on the planet to disagree with that, > > but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3rd > > paragraphs of the Introduction) and has been in the IPv6 Node > Requirements > > since 2011 (RFC434). > > > Brian, > > These are good descriptions flow label usage, but I don't see that > they set requirements as to 1) whether end host must/should/may send > non-zero flow labels with flow entropy 2) whether ECMP devices > must/should/may use non-zero flow labels as input to their hash, or 3) > if hosts use the flow label for EMCP must/should/may they parse any > deeper to extract additional L4 entropy. RFC6438 comes close and > answering #1, but that RFC is only applicable to tunnels. > > Pertaining to this draft, there is an observation that flow labels > would obviate the need for middle boxes to parse the header chain, > I think I must have missed something somewhere / lost the plot -- which draft is "this" draft? draft-gont-v6ops-ipv6-ehs-packet-drops? I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says that at all -- if the *only* thing that the middlebox is doing is load-balancing / ECMP, then this may be true, but in many cases "middleboxes" (a term which seems about as vague as "thingies") are doing many other things, including filtering, encapsulation, translation, monitoring / measurement, "optimization", prioritization, etc. But, as I said, I suspect I've lost the plot somewhere along the line... W > however the draft also states historically neither end nodes nor > routers support. It seem like there should at least be a > recommendation in "Future work" section on how to attain widespread > support flow label. > > Thanks, > Tom > > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114e7e3071b7b2052df9810b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon= , Mar 14, 2016 at 9:54 AM Tom Herbert <tom@herbertland.com> wrote:
On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter
<brian.= e.carpenter@gmail.com> wrote:
> On 14/03/2016 09:59, Tom Herbert wrote:
> ...
>> the point of using flow label is
>> that it eliminates the need to parse extension headers in the firs= t
>> place for the ECMP use case. It would be nice if this benefit was = and
>> the need for flow label support were better enunciated in the draf= t.
>
> I'll be the least likely person on the planet to disagree with tha= t,
> but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3r= d
> paragraphs of the Introduction) and has been in the IPv6 Node Requirem= ents
> since 2011 (RFC434).
>
Brian,

These are good descriptions flow label usage, but I don't see that
they set requirements as to 1) whether end host must/should/may send
non-zero flow labels with flow entropy 2) whether ECMP devices
must/should/may use non-zero flow labels as input to their hash, or 3)
if hosts use the flow label for EMCP must/should/may they parse any
deeper to extract additional L4 entropy. RFC6438 comes close and
answering #1, but that RFC is only applicable to tunnels.

Pertaining to this draft, there is an observation that flow labels
would obviate the need for middle boxes to parse the header chain,

I think I must have missed something somewhere = / lost the plot -- which draft is "this" draft?=C2=A0draft-gont-v= 6ops-ipv6-ehs-packet-drops?=C2=A0
I don't think that=C2=A0dra= ft-gont-v6ops-ipv6-ehs-packet-drops says that at all -- if the *only* thing= that the middlebox is doing is load-balancing / ECMP, then this may be tru= e, but in many cases "middleboxes" (a term which seems about as v= ague as "thingies") are doing many other things, including filter= ing, encapsulation, translation, monitoring / measurement, "optimizati= on", prioritization, etc.=C2=A0

But, as I sai= d, I suspect I've lost the plot somewhere along the line...
W=
=C2=A0
however the draft also states historically neither end nodes nor
routers support. It seem like there should at least be a
recommendation in "Future work"=C2=A0 section on how to attain wi= despread
support flow label.

Thanks,
Tom

>=C2=A0 =C2=A0 =C2=A0Brian

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114e7e3071b7b2052df9810b-- From nobody Sun Mar 13 20:11:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8312D813 for ; Sun, 13 Mar 2016 20:10:59 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDULrKA_nD1J for ; Sun, 13 Mar 2016 20:10:58 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC6212D820 for ; Sun, 13 Mar 2016 20:10:57 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id nk17so29538738igb.1 for ; Sun, 13 Mar 2016 20:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RhrR9GXt2aJqDIQ+POQfI116d+MvI4zJNed0ln/Z2N0=; b=fO7aNUyIyHXSzXi+GTMxMyPg1LhxoRjRjTTuWt2SHOIA0iFqfEAnOEg1agcuxZjC3D AF5+/ynmJ+k/qlA90DS7XYFGZeVUW/CiuJk0FH7TamsX5CTANf+Cm1Sfh0Uxw4nVGGlT IeSS3sSrUr/Ae3jbl/PrnfQ7SKJpzvGFKWmaEKZxnJWKO1t/kuewct5rOgSmglBDm9ph 5JziPREb+Visk41U6VKU195/a7sk8bF8M47vGkdZRLgAWWrWHZ0IzL0obgbDtJ1gClNn ESPhGQc/fXSWWVy9fkWCpMMLgYVNBbjt3VPnM47o0FREhnfJ86E0kyaVqKKEJY4sz0pv gI/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RhrR9GXt2aJqDIQ+POQfI116d+MvI4zJNed0ln/Z2N0=; b=PXXlvHlAOV9x0mFDWKqntH6d2GYwo+/MikulRP4clRVDnIKBiSlBGnR6v/X54AymHt luLsrJ7LHZD/5Sii4aySsebKH6FxzvxADzeOTQe6iAMsj+ggCbVApocTT+vNZNsBn6oK 9IIA4WnpeO4lWbB3x4OWYs+NCQE3yQi4d5e8TydmOZs5RGurrsuXXDLaS9aOWNwVly/x csUAV3F9/f+XPSKdYniEFFIKHkLkS0SIsZ9mCdUc+Gl+swkHGwIcFOaDxQWxXY/OYhJV f29W49Ww5tBzoySNk/pDpQZlfK8rTiBt0TgapjnJozVb2SSXc7pJ31zIjx5v2EUcvCsB Y15g== X-Gm-Message-State: AD7BkJLP2nhBkZ0w2HpT7h2CFzBxGIzSmWhDOrac1Lx8vmxg/hRsNMXxJ9IWyZI05SaiuCZv55kitgL2Pnb4Cg== MIME-Version: 1.0 X-Received: by 10.50.23.43 with SMTP id j11mr1420450igf.94.1457925057032; Sun, 13 Mar 2016 20:10:57 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Sun, 13 Mar 2016 20:10:56 -0700 (PDT) In-Reply-To: References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> Date: Sun, 13 Mar 2016 20:10:56 -0700 Message-ID: From: Tom Herbert To: Warren Kumari Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 03:11:00 -0000 On Sun, Mar 13, 2016 at 8:01 PM, Warren Kumari wrote: > > > On Mon, Mar 14, 2016 at 9:54 AM Tom Herbert wrote: >> >> On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter >> wrote: >> > On 14/03/2016 09:59, Tom Herbert wrote: >> > ... >> >> the point of using flow label is >> >> that it eliminates the need to parse extension headers in the first >> >> place for the ECMP use case. It would be nice if this benefit was and >> >> the need for flow label support were better enunciated in the draft. >> > >> > I'll be the least likely person on the planet to disagree with that, >> > but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3rd >> > paragraphs of the Introduction) and has been in the IPv6 Node >> > Requirements >> > since 2011 (RFC434). >> > >> Brian, >> >> These are good descriptions flow label usage, but I don't see that >> they set requirements as to 1) whether end host must/should/may send >> non-zero flow labels with flow entropy 2) whether ECMP devices >> must/should/may use non-zero flow labels as input to their hash, or 3) >> if hosts use the flow label for EMCP must/should/may they parse any >> deeper to extract additional L4 entropy. RFC6438 comes close and >> answering #1, but that RFC is only applicable to tunnels. >> >> Pertaining to this draft, there is an observation that flow labels >> would obviate the need for middle boxes to parse the header chain, > > > I think I must have missed something somewhere / lost the plot -- which > draft is "this" draft? draft-gont-v6ops-ipv6-ehs-packet-drops? > I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says that at all > -- if the *only* thing that the middlebox is doing is load-balancing / ECMP, > then this may be true, but in many cases "middleboxes" (a term which seems > about as vague as "thingies") are doing many other things, including > filtering, encapsulation, translation, monitoring / measurement, > "optimization", prioritization, etc. > Section 4.1.2 of draft-gont-v6ops-ipv6-ehs-packet-drops-03 discusses ECMP. ECMP is a fundamental feature in switches, we currently rely it on to get good load balancing across network fabrics. > But, as I said, I suspect I've lost the plot somewhere along the line... > W > >> >> however the draft also states historically neither end nodes nor >> routers support. It seem like there should at least be a >> recommendation in "Future work" section on how to attain widespread >> support flow label. >> >> Thanks, >> Tom >> >> > Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Mar 13 20:35:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F5C12D93E for ; Sun, 13 Mar 2016 20:35:13 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik8A6lM_mdqo for ; Sun, 13 Mar 2016 20:35:11 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A66A12D937 for ; Sun, 13 Mar 2016 20:35:11 -0700 (PDT) Received: from [172.20.15.144] (port-213-160-6-163.static.qsc.de [213.160.6.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 64FA28088E; Mon, 14 Mar 2016 04:35:09 +0100 (CET) To: Warren Kumari , Tom Herbert , Brian E Carpenter References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56E63167.5020305@si6networks.com> Date: Mon, 14 Mar 2016 00:35:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 03:35:14 -0000 On 03/14/2016 12:01 AM, Warren Kumari wrote: > > I think I must have missed something somewhere / lost the plot -- which > draft is "this" draft? draft-gont-v6ops-ipv6-ehs-packet-drops? > I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says that at > all -- if the *only* thing that the middlebox is doing is load-balancing > / ECMP, then this may be true, but in many cases "middleboxes" (a term > which seems about as vague as "thingies") are doing many other things, > including filtering, encapsulation, translation, monitoring / > measurement, "optimization", prioritization, etc. > > But, as I said, I suspect I've lost the plot somewhere along the line... This is exactly why this document is needed. Every time this discussion comes up, people seem to argue that if/when support for the Flow Label is widespread, packets with EHs will be passed -- as if ECMP was the sole reason for processing the EH chain. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Mar 13 20:39:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198C612D949 for ; Sun, 13 Mar 2016 20:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu0UVgsQ98sz for ; Sun, 13 Mar 2016 20:39:29 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0866612D7C0 for ; Sun, 13 Mar 2016 20:39:29 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id u190so97123385pfb.3 for ; Sun, 13 Mar 2016 20:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KlnkVCxCC4SHxs26n+hla0H3bprj6pxQcp1d3qbEwyM=; b=FaCqQ1q2KjAy8qVygYFeazHFWbQphTyYRKwUKKbw1mKqEfhkgpNSMQre7lTCzJ9oNc mUlRvPXSnmXdJO+H8+mfkPvTXxrdo900uSU2ec1Uxvt9S4ooaFeA7cz9hd0hqlRNhFB0 ttg4k5uJ0osqS134uH2DHcDQaOqtuG/nrRq4cG6C0LyaUzOEdovAa2ktofR3gU+Rm5Eh gcTr+2hFVlBKT/UmxUvgzLEnp5LJK4ZJ3zqV2NK0T8VepH2SoTBYBqHNygUVZ5wTgKTP B0Ijvb6j+6ciqCj21CRozUDRA0lq1aH6SL7NFix3nnFZ3lakfDKMOynJcJalzIX+kNlF 6NIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=KlnkVCxCC4SHxs26n+hla0H3bprj6pxQcp1d3qbEwyM=; b=ERp0vMJjQcN2YsdtBOVPVvnqKmdPWxABx39VtJOyfKdiWmctsTqBSa8XLYqhlJeIrt jJXOQVfx0lfTeSf5gXxZ0ndZ6gYu5yWvR7abXnydpn55XHXYwuDZzem0ChIS7vc42UuH mEqSyP8z4vNWz1+X3WoTVA3r35KemcDJB3ru630YgEJYE3znhjCPflHWp9jheC0nG4Yy nk+8XB5n0CR+LJ7p2VMB1liKQTFkS00EpXphHS4RJqpuNJe33X/dzcrU9Q+psNNCqp0Z 6azVxVoRUNJz/b/GiMH64xl+JNIWrqhi6371nlcmbvXiqHVxrkqVQwFJ2dNH2yGl6fY1 M/cg== X-Gm-Message-State: AD7BkJIzqK98AwRxkTjpJeU5mkoFaJRdzDThpPEZLgwFvs2wD1N4v4sZlLwLSGjvFXaLEw== X-Received: by 10.98.9.219 with SMTP id 88mr27226192pfj.0.1457926768536; Sun, 13 Mar 2016 20:39:28 -0700 (PDT) Received: from [192.168.88.117] ([103.29.31.50]) by smtp.gmail.com with ESMTPSA id dg1sm28004840pad.18.2016.03.13.20.39.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Mar 2016 20:39:26 -0700 (PDT) To: Tom Herbert References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E6326B.2090303@gmail.com> Date: Mon, 14 Mar 2016 16:39:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 03:39:31 -0000 On 14/03/2016 14:54, Tom Herbert wrote: > On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter > wrote: >> On 14/03/2016 09:59, Tom Herbert wrote: >> ... >>> the point of using flow label is >>> that it eliminates the need to parse extension headers in the first >>> place for the ECMP use case. It would be nice if this benefit was and >>> the need for flow label support were better enunciated in the draft. >> >> I'll be the least likely person on the planet to disagree with that, >> but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3rd >> paragraphs of the Introduction) and has been in the IPv6 Node Requirements >> since 2011 (RFC434). >> > Brian, > > These are good descriptions flow label usage, but I don't see that > they set requirements as to 1) whether end host must/should/may send > non-zero flow labels with flow entropy RFC6437 seems clear enough to me: "It is therefore RECOMMENDED that source hosts support the flow label by setting the flow label field for all packets of a given flow to the same value chosen from an approximation to a discrete uniform distribution. Both stateful and stateless methods of assigning a value could be used, but it is outside the scope of this specification to mandate an algorithm. The algorithm SHOULD ensure that the resulting flow label values are unique with high probability." > 2) whether ECMP devices > must/should/may use non-zero flow labels as input to their hash, or 3) > if hosts use the flow label for EMCP must/should/may they parse any > deeper to extract additional L4 entropy. Is that a matter for standardisation? Surely designers of ECMP or other load balancing devices will use whatever they find works best? > RFC6438 comes close and > answering #1, but that RFC is only applicable to tunnels. > > Pertaining to this draft, there is an observation that flow labels > would obviate the need for middle boxes to parse the header chain, > however the draft also states historically neither end nodes nor > routers support. It seem like there should at least be a > recommendation in "Future work" section on how to attain widespread > support flow label. Beyond what "node requirements" says? Such as what? Brian From nobody Sun Mar 13 20:42:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF7612D93A for ; Sun, 13 Mar 2016 20:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnV9cRmclQDC for ; Sun, 13 Mar 2016 20:42:32 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E8A12D7D7 for ; Sun, 13 Mar 2016 20:42:32 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id d65so153153710ywb.0 for ; Sun, 13 Mar 2016 20:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WRaFBjbKgB/TS3V2riqhdx+Rh2RbzdVZtl1bep/hjAM=; b=DjJkCCy+5odQUl/otlSGmt2Gm3mStemVRZeDFDC5oj5LyW3B3UpAkMPyHevlW4CkAo hm5bJCOrJMArt6UEKsQKbkzaOZ1Iwd4KPvlCMeo+wVbNzELypL9Upmx4pIm143KNYIrr X1YncwHASayCee/g8p2gQz9r8RP7GINTH0Xcp9//x4pG91/wZlcrxbCRo1rn+tgjBTEi paZw6swaItc747JY8wPDjsXLWgxqoMRyDgF5WabLk33Di+Ap8PHcQieD3XgFV8+l/36v gj16+j5Ybelly0zq63bkwdv03UW8dlF4KuTt8lvlcQwwa1KjWZWGPZ6oH0MCJBwFWTpM TQ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WRaFBjbKgB/TS3V2riqhdx+Rh2RbzdVZtl1bep/hjAM=; b=VJU38YWWWpa/Ksql1fY9Z8VDaqRxJPnS2T3l65xwN02CKSuDAkPlUPatXFD/bNZrDf iMFxrVoJclVloZv40kRjmdwtI2H5nTKBgQf4jBnc1JlZbBMX2Uf2E9j2Ow6CVfLVKP6X OYMy3N8IaCdxxOVOvUPSWZ0rR696TlxSP4pHaNb5nuPVRlC26ULzTRxtrUc3Wgph5k9q keDb+CTBDYSyLIw/pS4HlYvA6C46TuQdXidd+Xx4YEt1vPxdcTCgnsKKb+kdnNCAwFTl N/xdETp/CnQtf+g4yIYHT4lOo/F7F4LusdReLnidGxIgzKdhlbYUm4jqi95jE0nEX6NH J/ig== X-Gm-Message-State: AD7BkJLsXPLorTNVjPbqShXPVEXbbKB/CcVlyOFPOx1B63lnu9w/mszPxSW1CdkQsk8mYV6KgH3aCdgvA6a1HKUe X-Received: by 10.129.103.66 with SMTP id b63mr12383117ywc.127.1457926951285; Sun, 13 Mar 2016 20:42:31 -0700 (PDT) MIME-Version: 1.0 References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> In-Reply-To: From: Warren Kumari Date: Mon, 14 Mar 2016 03:42:21 +0000 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a1145d1080a65a8052dfa1262 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 03:42:35 -0000 --001a1145d1080a65a8052dfa1262 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 11:10 AM Tom Herbert wrote: > On Sun, Mar 13, 2016 at 8:01 PM, Warren Kumari wrote: > > > > > > On Mon, Mar 14, 2016 at 9:54 AM Tom Herbert wrote: > >> > >> On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter > >> wrote: > >> > On 14/03/2016 09:59, Tom Herbert wrote: > >> > ... > >> >> the point of using flow label is > >> >> that it eliminates the need to parse extension headers in the first > >> >> place for the ECMP use case. It would be nice if this benefit was and > >> >> the need for flow label support were better enunciated in the draft. > >> > > >> > I'll be the least likely person on the planet to disagree with that, > >> > but it is already part of the IPv6 standards (RFC6437 - see 2nd and > 3rd > >> > paragraphs of the Introduction) and has been in the IPv6 Node > >> > Requirements > >> > since 2011 (RFC434). > >> > > >> Brian, > >> > >> These are good descriptions flow label usage, but I don't see that > >> they set requirements as to 1) whether end host must/should/may send > >> non-zero flow labels with flow entropy 2) whether ECMP devices > >> must/should/may use non-zero flow labels as input to their hash, or 3) > >> if hosts use the flow label for EMCP must/should/may they parse any > >> deeper to extract additional L4 entropy. RFC6438 comes close and > >> answering #1, but that RFC is only applicable to tunnels. > >> > >> Pertaining to this draft, there is an observation that flow labels > >> would obviate the need for middle boxes to parse the header chain, > > > > > > I think I must have missed something somewhere / lost the plot -- which > > draft is "this" draft? draft-gont-v6ops-ipv6-ehs-packet-drops? > > I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says that at > all > > -- if the *only* thing that the middlebox is doing is load-balancing / > ECMP, > > then this may be true, but in many cases "middleboxes" (a term which > seems > > about as vague as "thingies") are doing many other things, including > > filtering, encapsulation, translation, monitoring / measurement, > > "optimization", prioritization, etc. > > > Section 4.1.2 of draft-gont-v6ops-ipv6-ehs-packet-drops-03 discusses > ECMP. Nod. > ECMP is a fundamental feature in switches, Nod. > we currently rely it > on to get good load balancing across network fabrics. > Yah, nod, nod, fully agree. I see where the disconnect is now -- to me, switches are not "middleboxes", they fall into their own bucket ("switches" :-P). I think we are in violent agreement, we are just using different terms. To me, middleboxes are IP devices which are not designed to more than just packet forwarding / filtering - but this is a vague description, and more of a "I know it when I see it" (kind of like the entertaining (?) discussions of the difference between a bridge and a switch, or a L3 switch and a router). RFC 3234 ("Middleboxes: Taxonomy and Issues") has a much better definition than mine :-P W > > But, as I said, I suspect I've lost the plot somewhere along the line... > > W > > > >> > >> however the draft also states historically neither end nodes nor > >> routers support. It seem like there should at least be a > >> recommendation in "Future work" section on how to attain widespread > >> support flow label. > >> > >> Thanks, > >> Tom > >> > >> > Brian > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > --001a1145d1080a65a8052dfa1262 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon= , Mar 14, 2016 at 11:10 AM Tom Herbert <tom@herbertland.com> wrote:
On Sun, Mar 13, 2016 at 8:01 PM, Warren Kumari <warren@kumari.net> wrote:
>
>
> On Mon, Mar 14, 2016 at 9:54 AM Tom Herbert <tom@herbertland.com> wrote:
>>
>> On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter
>> <brian.e.carpenter@gmail.com> wrote:
>> > On 14/03/2016 09:59, Tom Herbert wrote:
>> > ...
>> >> the point of using flow label is
>> >> that it eliminates the need to parse extension headers in= the first
>> >> place for the ECMP use case. It would be nice if this ben= efit was and
>> >> the need for flow label support were better enunciated in= the draft.
>> >
>> > I'll be the least likely person on the planet to disagree= with that,
>> > but it is already part of the IPv6 standards (RFC6437 - see 2= nd and 3rd
>> > paragraphs of the Introduction) and has been in the IPv6 Node=
>> > Requirements
>> > since 2011 (RFC434).
>> >
>> Brian,
>>
>> These are good descriptions flow label usage, but I don't see = that
>> they set requirements as to 1) whether end host must/should/may se= nd
>> non-zero flow labels with flow entropy 2) whether ECMP devices
>> must/should/may use non-zero flow labels as input to their hash, o= r 3)
>> if hosts use the flow label for EMCP must/should/may they parse an= y
>> deeper to extract additional L4 entropy. RFC6438 comes close and >> answering #1, but that RFC is only applicable to tunnels.
>>
>> Pertaining to this draft, there is an observation that flow labels=
>> would obviate the need for middle boxes to parse the header chain,=
>
>
> I think I must have missed something somewhere / lost the plot -- whic= h
> draft is "this" draft? draft-gont-v6ops-ipv6-ehs-packet-drop= s?
> I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says tha= t at all
> -- if the *only* thing that the middlebox is doing is load-balancing /= ECMP,
> then this may be true, but in many cases "middleboxes" (a te= rm which seems
> about as vague as "thingies") are doing many other things, i= ncluding
> filtering, encapsulation, translation, monitoring / measurement,
> "optimization", prioritization, etc.
>
Section 4.1.2 of draft-gont-v6ops-ipv6-ehs-packet-drops-03 discusses
ECMP.

Nod.
=C2=A0
ECMP is a fundamental feature in switches,

Nod. =C2=A0
we c= urrently rely it
on to get good load balancing across network fabrics.
=
Yah, nod, nod, fully agree.

I see w= here the disconnect is now -- to me, switches are not "middleboxes&quo= t;, they fall into their own bucket ("switches" :-P).=C2=A0
=
I think we are in violent agreement, we are just using different terms= .=C2=A0

To me, middleboxes are IP devices which ar= e not designed to more than just packet forwarding / filtering - but this i= s a vague description, and more of a "I know it when I see it" (k= ind of like the entertaining (?) discussions of the difference between a br= idge and a switch, or a L3 switch and a router).

R= FC 3234 ("Middleboxes: Taxonomy and Issues") has a much better de= finition than mine :-P
W

=C2=A0
> But, as I said, I suspect I've lost the plot somewhere along the l= ine...
> W
>
>>
>> however the draft also states historically neither end nodes nor >> routers support. It seem like there should at least be a
>> recommendation in "Future work"=C2=A0 section on how to = attain widespread
>> support flow label.
>>
>> Thanks,
>> Tom
>>
>> >=C2=A0 =C2=A0 =C2=A0Brian
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops<= br>
--001a1145d1080a65a8052dfa1262-- From nobody Sun Mar 13 22:43:02 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BF312DDF0; Fri, 11 Mar 2016 15:05:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230532.15028.54628.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:32 -0800 Archived-At: X-Mailman-Approved-At: Sun, 13 Mar 2016 22:43:01 -0700 Cc: v6ops@ietf.org Subject: [v6ops] v6ops - Requested sessions have been scheduled for IETF 95 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:34 -0000 Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00:00) Monday, Afternoon Session I 1400-1530 Room Name: Buen Ayre C size: 250 --------------------------------------------- v6ops Session 2 (2:00:00) Tuesday, Morning Session I 1000-1230 Room Name: Buen Ayre C size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: opsec softwire homenet pcp sunset4 6man aqm dnsop isis opsawg ospf tsvwg Second Priority: tsvarea intarea mif lmap Third Priority: rtgwg Special Requests: --------------------------------------------------------- From nobody Mon Mar 14 06:11:37 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C5B12D5B8; Mon, 14 Mar 2016 06:11:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160314131134.5668.6923.idtracker@ietfa.amsl.com> Date: Mon, 14 Mar 2016 06:11:34 -0700 Archived-At: Cc: v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Subject: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 13:11:34 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-v6ops-ipv6-ehs-in-real-world-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The tables in section 2 would be more useful if they said how many addresses correspond to each row after filtering the 1M. - Appendix A: The URL [1] results in a 404 for me after a re-direct to port 443. I like the 301, but not the 404:-) [1] http://www.si6networks.com/datasets/wipv6day-domains.txt From nobody Mon Mar 14 09:31:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFE712DBD0 for ; Mon, 14 Mar 2016 09:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo1HaQveVEbI for ; Mon, 14 Mar 2016 09:31:02 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A981D12DBB1 for ; Mon, 14 Mar 2016 09:30:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2EGUm37016702 for ; Mon, 14 Mar 2016 17:30:48 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 88B73209707 for ; Mon, 14 Mar 2016 17:31:24 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7F1C120966F for ; Mon, 14 Mar 2016 17:31:24 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2EGUmjW011664 for ; Mon, 14 Mar 2016 17:30:48 +0100 From: Alexandre Petrescu To: v6ops@ietf.org References: Message-ID: <56E6E738.5090203@gmail.com> Date: Mon, 14 Mar 2016 17:30:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 16:31:05 -0000 Hi, Let me take advantage of this discussion to discuss the necessity of this join. Le 03/03/2016 03:29, Hermin Anggawijaya a écrit : > > On Linux, the IPv6 stack will generate MLD report (both unsolicited > report and as reply to queries) if a socket is set with > IPV6_ADD_MEMBERSHIP or IPV6_JOIN_GROUP for the given IPv6 multicast > address. I think linux does REPORT even though the user does not specifically open a socket with these parameters. Wireshark on a vanilla linux will expose those MLD messages on LL scope. A question that could be raised is on the necessity of this message. On one hand, it is good for a desktop PC to inform the office switch that it needs to be part of that group. It helps channelling messages. But when there are only Hosts on that link, the message is still issued even though all Hosts must be subscribed to the LL group anyways, by definition of the LL scope. This may have some significance in particular mobility settings where the medium must be free as much as possible of what could be considered noise. In vehicular networks the 802.11-OCB (aka 802.11p) is stripped off of all link-layer messages like 802.11 beacons/assn/auth in order to keep the medium as silent as possible, yet the IP MLD LL messages are there. These could be considered to be superfluous. But of course the MLD REPORTS for wider than LL scope are still needed in vehicular networks. Alex > And looks like the Python script should do the job. > > Having seen an MLD report from a host running the Python script, I > would have thought that the LAN switch would make the host (or the > switch port the host is connected to) to become a member of the > multicast group, and the switch should forward all multicast packets > for ff02::114. > > *If the corresponding multicast packets (ff02::114) are indeed > filtered by MLD snooping switch* - despite seeing the membership > report sent by the host running the script, then on some switches > you could try either (depends on availability of features): > > 1. disable snooping - but this could make the LAN 'chatty' 2. set > the default behaviour for unknown multicast address to flood, then > apply a filter on the MLDSnooping module so that it never 'learns' > ff02::114, thus keeping ff02::114 as unknown multicast 3. add static > MLD snooping entry for ff02::114 and make all the ports in the vlan > as a member. 4. add ff02::114 as a 'protocol' address to MLD > Snooping so that it is flooded properly to 'router ports' like > ff02::6, ff02:6, ff02::9 etc. > > > Kind regards > > Angga > > > > On Thu, Mar 3, 2016 at 10:13 AM, Mark Smith > wrote: > > > On 3 Mar 2016 07:00, "Brian E Carpenter" > > > wrote: >> >> I'm sorry to distract the group with a practical question, but I'm >> a bit stumped. My question is below. >> >> In the thread "Further Mitigating Router ND Cache Exhaustion DoS >> Attacks Using Solicited-Node Group Membership (-01)", on >> 24/02/2016 08:07, Brian E Carpenter wrote: >>> On 24/02/2016 07:53,otroan@employees.org >>> wrote: >>>>>> MLD joins for the solicited node multicast address has >>>>>> turned out to have little practical purpose. I am thinking >>>>>> of going the other way and stop sending joins for >>>>>> link-local multicast groups. >>>>> >>>>> Yes. What is the possible use of a link-local "join"? The >>>>> packets are just there on the link anyway, so "joining" is >>>>> entirely an internal matter for each node. >>>>> >>>>> However, it is the case that some switches are not >>>>> transparent to LL multicasts to arbitrary addresses. For >>>>> example in some tests I did recently, the lab switch was >>>>> transparent to ff02::1 but opaque to ff02::114. >>>> >>>> it was presumably snooping on MLD and did forward when it had >>>> received a join for ff02::114? >>> >>> Possibly. I fixed the problem by inserting a dumb bridge that >>> does what bridges are supposed to do. >>> >>>> the switch designers I've spoken to state that they cannot >>>> scale for the number of multicast groups, in particular >>>> solicited node multicast. I think they often do an exception >>>> for ff02::1 and treat that as broadcast. >>> >>> But why not pass all LL multicasts? >>> >>> Anyway, if this is common behaviour by switches it has to be >>> allowed for. >> >> Now my practical question. When a host starts listening to a LL >> multicast address, who or what sends the MLD Listener Report? Is >> the stack supposed to do so automatically, or does the socket >> programmer have to do something? RFC 3810 really doesn't answer >> this question, and Google has been unable to help me. >> > > My expectation is the stack, and when I wrote the following a number > of years a go, I'm pretty sure I saw the (Linux) stack doing it for > LL multicasts. > > https://github.com/markzzzsmith/replicast > > I think the stack would have to do it unless the application had a > MLD client implementation in it to send periodic reports and to > respond to MLD router queries. > >> A Python fragment is below to show what I am actually doing. This >> works perfectly, but not when the LAN switch is filtering >> multicasts. >> > > Is any sort of active multicast filtering enabled e.g., MLD > snooping? > > If not, it reminds me of some ADSL DSLAMs that will pass IPv4 > multicasts but not IPv6 ones thorough "transparent LAN service" > configurations. > > Regards, Mark. > >> Thanks Brian >> >> GRASP_LISTEN_PORT = 1021 ALL_GRASP_NEIGHBOR_6 = >> ipaddress.IPv6Address('ff02::114') >> >> mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) >> mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) >> mcrsock.bind(('',GRASP_LISTEN_PORT)) mreq = >> ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_zone_id) >> mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, >> mreq) mcrsock.settimeout(300) rawmsg, send_addr = >> mcrsock.recvfrom(2048) > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Mar 14 09:41:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8612D644 for ; Mon, 14 Mar 2016 09:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZksDkunnGCP for ; Mon, 14 Mar 2016 09:41:14 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B09412DA7B for ; Mon, 14 Mar 2016 09:41:11 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id m184so229588698iof.1 for ; Mon, 14 Mar 2016 09:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KjxD7XuVBfP/7G6LOUXI/sQvqpCDVu/xCxE6efgi5kE=; b=flpr2lA7VKGLoMES+be3QW4haoiNgHPGVP6qKIearExWsK3I2Hog56PC7/baNZUb7l Ybfne/zANLjlN8N0UpBqU8Eaet0TenuriwV5/wJYTw75jsbcft5OYDlnS60OCigv2skG APndGSs9CTrEUUuEMoopOW+trIk7b7iJEImijlRxwPtLwgcPI/dE6r/OXAxmzAJh+HY/ wY5P7aWbKZLvehRw7l4JXNdG6H6q35hO1JRfiYPzMc/b3EwQIZFlJuvU6FzlnZlGOTOw gBnpf+IWpaDxxrkUadoZqbMGEDiZr0ckNz48ksUZ0GWIkvi++3mjg0X28ZMW+/NGZKRB HYKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KjxD7XuVBfP/7G6LOUXI/sQvqpCDVu/xCxE6efgi5kE=; b=jBUNiF6p8CSvcZlP+X9SnsuZn4xUSKv2paTSXP++Xt2HHyLkvEkQ4T0yTK4a9uMxrP o1NMklDURbiJJ1YHhCbyfpaiY9I8LCgr3emZiYTT1HA6C4VKRVZ7oJTZZxHDcDWqTTaj GhbjhnyxfE4+yosvAZTDuDkcrOnqcQq/d0fPFYMcaju04BQI1/yuEio6tQFA0ox2y60g aJPotMX7JQ2rTJcaHhs9RKaQe9Qr51r8Y3Qy1Z8LYqS3O4jVTm7rqZjzFNAAoqbstH7+ 9uOANtKshtzrrAYMW0CSNISppe8BQyaDFXgzgOe3L16h37dQUSSUgZSlwpuj64IIVlQ2 cFTQ== X-Gm-Message-State: AD7BkJJZiXQvYmbWaFZ94C7pjYOq1ovBQrmHEAwghzJ44roDq7pQ8L6HXZjQ9CXqm2q/87DhNxSyikmwCokDxg== MIME-Version: 1.0 X-Received: by 10.107.10.103 with SMTP id u100mr25635866ioi.50.1457973670766; Mon, 14 Mar 2016 09:41:10 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Mon, 14 Mar 2016 09:41:10 -0700 (PDT) In-Reply-To: <20160314162201.8685.89310.idtracker@ietfa.amsl.com> References: <20160314162201.8685.89310.idtracker@ietfa.amsl.com> Date: Mon, 14 Mar 2016 09:41:10 -0700 Message-ID: From: Tom Herbert To: IPv6 Operations , "nvo3@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Blake Matheny , petr@fb.com Subject: [v6ops] Fwd: New Version Notification for draft-herbert-nvo3-ila-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 16:41:16 -0000 Hi, In this version we added a section (2.3) discussing some of the proposed alternatives suggested in IPv6 to accomplish network virtualization without encapsulation (namely use of flow label or extension header). Also, a method is defined to do checksum-neutral ILA translation modeled after that in RFC6296 (section 4.4). Thanks, Tom ---------- Forwarded message ---------- From: Date: Mon, Mar 14, 2016 at 9:22 AM Subject: New Version Notification for draft-herbert-nvo3-ila-02.txt To: Tom Herbert A new version of I-D, draft-herbert-nvo3-ila-02.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-nvo3-ila Revision: 02 Title: Identifier-locator addressing for network virtualization Document date: 2016-03-14 Group: Individual Submission Pages: 34 URL: https://www.ietf.org/internet-drafts/draft-herbert-nvo3-ila-02.txt Status: https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila/ Htmlized: https://tools.ietf.org/html/draft-herbert-nvo3-ila-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-herbert-nvo3-ila-02 Abstract: This specification describes identifier-locator addressing (ILA) in IPv6 for network virtualization. Identifier-locator addressing differentiates between location and identity of a network node. Part of an address expresses the immutable identity of the node, and another part indicates the location of the node which can be dynamic. Identifier-locator addressing can be used to efficiently implement overlay networks for network virtualization Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 14 10:29:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CFD12D683 for ; Mon, 14 Mar 2016 10:29:57 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcWS52LxfTJm for ; Mon, 14 Mar 2016 10:29:54 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF01612D675 for ; Mon, 14 Mar 2016 10:29:54 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id vf5so66993511igb.0 for ; Mon, 14 Mar 2016 10:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AAchAOCLNNxV+CBofF7sO682N+mhxz9OjWqE7WGg1YM=; b=vDCJnLy10nKk8dsEfa6RenDzGdYX1tb3sbLC18v4koFSBXxHYKCyL8x5PYYjtnH+ut duChIIjQT0wzhHZCNOqKA00LkNOgQTkg8u4AUtPyvEBCXZr1nynjkkZwKWp4jJSH8QDu /ELPF5mj7uMpCbO5zozljPSn1m3MUXp7ntn3KJJdfpiablNjnSmWwQCqaV2kyolkE/iF EwIt9RMnEnVWnbNZxWOAa5RMjYeCuA+cqsYzX4ledTRSUTff1654/GB5w7sYHdRuo65s +jMPVkqbsRMEA8oUlFDIIRGA3kx7s1gEjMioX5jIgiv+IUYXpvYQH8QFoFx+9UbUb0dB XV0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AAchAOCLNNxV+CBofF7sO682N+mhxz9OjWqE7WGg1YM=; b=AmcPHJxwkcoH5d/YQ2jGtcqjSdaIm279JiOqC8PxCIXQiGHlNxAj6yIOMqZP3LNRJt 5Yh8Q6BenrHnaleOvc38p68plVV67z25YhTeNEgVOCAAF6U01uy+812V/VMGeeqxCNzt fWYiQRwjp8LNmhKLIk5cmPsNF4Sjkq4EdYP1b5Pk0j6JSlvslOpHY5ivOptATXw914r0 6MFTADSIST5SOz6wQ15aLZW3woykZGkYXZZXAMz+WGWYR51xxJyccHi8B/Sr5JWUSjLI BqmqBQmgLJy68o8YgpAvcLWUKcNKbEh3PJZ40hSPpS1xIdLLC1yD4zTg3cmReX2C5mTP 7ZRQ== X-Gm-Message-State: AD7BkJKg1vadpSJ6TFyaFGtBAhxDaKIfSVgMWSV8+PI2luY7Lf9Js3ipWxLRTaYuyNWE/4AxsTse+B6Yh9koqQ== MIME-Version: 1.0 X-Received: by 10.50.87.7 with SMTP id t7mr19453253igz.65.1457976594135; Mon, 14 Mar 2016 10:29:54 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Mon, 14 Mar 2016 10:29:53 -0700 (PDT) In-Reply-To: <56E6326B.2090303@gmail.com> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> Date: Mon, 14 Mar 2016 10:29:53 -0700 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 17:29:57 -0000 On Sun, Mar 13, 2016 at 8:39 PM, Brian E Carpenter wrote: > On 14/03/2016 14:54, Tom Herbert wrote: >> On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter >> wrote: >>> On 14/03/2016 09:59, Tom Herbert wrote: >>> ... >>>> the point of using flow label is >>>> that it eliminates the need to parse extension headers in the first >>>> place for the ECMP use case. It would be nice if this benefit was and >>>> the need for flow label support were better enunciated in the draft. >>> >>> I'll be the least likely person on the planet to disagree with that, >>> but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3rd >>> paragraphs of the Introduction) and has been in the IPv6 Node Requirements >>> since 2011 (RFC434). >>> >> Brian, >> >> These are good descriptions flow label usage, but I don't see that >> they set requirements as to 1) whether end host must/should/may send >> non-zero flow labels with flow entropy > > RFC6437 seems clear enough to me: > > "It is therefore RECOMMENDED > that source hosts support the flow label by setting the flow label > field for all packets of a given flow to the same value chosen from > an approximation to a discrete uniform distribution. Both stateful > and stateless methods of assigning a value could be used, but it is > outside the scope of this specification to mandate an algorithm. The > algorithm SHOULD ensure that the resulting flow label values are > unique with high probability." > >> 2) whether ECMP devices >> must/should/may use non-zero flow labels as input to their hash, or 3) >> if hosts use the flow label for EMCP must/should/may they parse any >> deeper to extract additional L4 entropy. > > Is that a matter for standardisation? Surely designers of ECMP or > other load balancing devices will use whatever they find works best? > I think it may be a matter for standardization in the sense that most current ECMP implementations tend to only work with TCP and UDP without options (i.e. this leads to the notion that IP has evolved to have 24/44 byte headers as a de facto standard). This creates interoperability with other standard protocols. Even if devices perform ECMP on these alternate protocols based on just addresses this is still not enough, without similar flow based load balancing we can't deploy alternate transport protocols/EH at scale. From that point of view, the IPv6 flow label "works best" for ECMP and so the three tuple hash (addresses and flow label) should be the recommended method for ECMP devices to implement. Also, point #3 is important. An end host sets the flow label with the expectation that packets with the same 3-tuple will follow the same path through the network. If routers do implement the flow label, but also try to extract more entropy by trying to parse into the transport layer, this breaks the host's expectation. This increases nondeterminism resulting in out-of-order packets, drops, high variance latency. IMO #3 should also be a recommendation for switches doing ECMP. Tom >> RFC6438 comes close and >> answering #1, but that RFC is only applicable to tunnels. >> >> Pertaining to this draft, there is an observation that flow labels >> would obviate the need for middle boxes to parse the header chain, >> however the draft also states historically neither end nodes nor >> routers support. It seem like there should at least be a >> recommendation in "Future work" section on how to attain widespread >> support flow label. > > Beyond what "node requirements" says? Such as what? > > Brian From nobody Mon Mar 14 11:00:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83C612DC47 for ; Mon, 14 Mar 2016 11:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5OyULxHykOx for ; Mon, 14 Mar 2016 10:59:59 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCABD12D6A0 for ; Mon, 14 Mar 2016 10:59:58 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2EHxr2t076980 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Mar 2016 17:59:55 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <56E6FC18.1060304@foobar.org> Date: Mon, 14 Mar 2016 17:59:52 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tom Herbert References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 18:00:02 -0000 Tom Herbert wrote: > From that point of view, the IPv6 flow label "works best" for ECMP > and so the three tuple hash (addresses and flow label) should be the > recommended method for ECMP devices to implement. Tom, Everyone agrees with this. The problem is that core and leaf operators are not in control of flow label generation at the edge, and many operating systems do not bother to set the flow label. In other words, flow labels do not currently provide enough entropy to be useful for flow hash generation in most instances. Everyone understands that flow labels would help this problem. This draft is about what happens when the flow label is zero, which is the case more often than not. Nick From nobody Mon Mar 14 11:12:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1BD12D671 for ; Mon, 14 Mar 2016 11:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tN7NwH1e-eR for ; Mon, 14 Mar 2016 11:12:17 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04AFA12D5DC for ; Mon, 14 Mar 2016 11:12:17 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m184so232861495iof.1 for ; Mon, 14 Mar 2016 11:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+Y8VYFPw0MRKIIIi/A/K1Q9a4a7PpzAnNMCY5ZFLcHs=; b=rLmkbC/NdtKtdHlfJTVAQfu4pqwLR3TiLXEpwE6l7A5bTTpJ+v2EOHerjf1leODyTr AdyYPJmDm6q+ztbD5cSsauh2FB3cqa2FnlzZUZSh2ttnZLejkle8dnh8Bti/U7dWmrFI tzK5wcpHtMr8ZfRyIYhhjsUUeLtKfmCD9R8SrbzTUUHMwHqk0u4GG5EDCw53XOrmuCP5 PwFa9rYvxxDzLCf3a0wgcALcG+tIpK0CvDVIPqb8zz6C7Ic2cQRsLUIH1QRb3RQzM54Y bSLysCAhs5zoneCWWY/VUmWS/gWXu8fQGPQDO43JY709YZl7sBASDxMlcac3ZxlgxJIr pVAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+Y8VYFPw0MRKIIIi/A/K1Q9a4a7PpzAnNMCY5ZFLcHs=; b=HkqCNuWK7veX2kEWn4U0kJjS9F2znI4Ti02ybzmiXIwHWElx8nqCQKW11KDqQUX6kC L5SI+VSxGV/IxTDMbnDDIWHcazPrXjqyb4kOqd9GeStUpXmsxokiz7oxIzWE5O3V6JnC HijNKHz0Lg/MCWBs3Je3mX2JerCm+rUOICQVDe+tnXjDcn11QbpW+lIYwCdA7jBRzpFM WyAqg92LK9G7T7pqO8a9uZ+89lS1BN8rdtrJbYfUAfuWiJoc7xfaAN6kH6prtaydaKqQ nLo91r9R3ALxXkZPbbjp0FMnAxQck1P3pVi09wiFSko6wfN9MaFQmsbiGXepewsACNua syBw== X-Gm-Message-State: AD7BkJKYRn4RkHFR2cXCFt2U8kdmOrEIjINTe4lHQbDLMztcGIEPWrCTGS8u116jlUK6pyQMOmVB/nRzhp4M+A== MIME-Version: 1.0 X-Received: by 10.107.10.103 with SMTP id u100mr26092652ioi.50.1457979136393; Mon, 14 Mar 2016 11:12:16 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Mon, 14 Mar 2016 11:12:16 -0700 (PDT) In-Reply-To: <56E6FC18.1060304@foobar.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> Date: Mon, 14 Mar 2016 11:12:16 -0700 Message-ID: From: Tom Herbert To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 18:12:18 -0000 On Mon, Mar 14, 2016 at 10:59 AM, Nick Hilliard wrote: > Tom Herbert wrote: >> From that point of view, the IPv6 flow label "works best" for ECMP >> and so the three tuple hash (addresses and flow label) should be the >> recommended method for ECMP devices to implement. > > Tom, > > Everyone agrees with this. The problem is that core and leaf operators > are not in control of flow label generation at the edge, and many > operating systems do not bother to set the flow label. In other words, > flow labels do not currently provide enough entropy to be useful for > flow hash generation in most instances. > > Everyone understands that flow labels would help this problem. This > draft is about what happens when the flow label is zero, which is the > case more often than not. > Nick, iOS already sends non-zero IPv6 flow labels, we have changed Linux default to use IPv6 flow label so once Android rebases the kernel the majority of IPv6 end hosts should be sending non-zero flow labels. It is far easier and shorter time to change the software stacks to send them than upgrading all the HW in the paths to use them productively. But compared the problem of HW being able to efficiently parse arbitrarily long header chains, I still think this is a very solvable problem. Tom > Nick From nobody Mon Mar 14 13:30:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030DE12D4FF for ; Mon, 14 Mar 2016 13:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuhZW148wDUh for ; Mon, 14 Mar 2016 13:29:59 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5D812D5C8 for ; Mon, 14 Mar 2016 13:29:59 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id x3so49742191pfb.1 for ; Mon, 14 Mar 2016 13:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xRCsc4xoHZsq0aFYRNqiFU69pWqD4YQGF+y3HpRinlw=; b=y4GE7PiiHlPYxS2gmCpgjHdRGuNLo+/A+q/QC/X2Cn3Nq8RV/0/xFbAqrPqdV7KGUh +fU+eJ+eejLSj/VaH09zH/zFxYZyVxCYjQTzEXvQ0UROph9p6gPBBSGhz//n0+QPXo6o eIIuzAtwcWFjJt3HH5xvHqOnnTEDgeUSgboXob4h1sVPWsItC7VjZ9o9IVnsgerLiup2 yodvmC48dnYOUqZAuayoRzt/teBpU07Ou2CyJsiB1beHPyXYPxJ1+pNeyaH2BL551orW MG9pmkfZI+NYoyXy/CrHDdCLHGqUixQSy05R8tJBpciDyJ1cPPEaXX6XrQh3Hdai8gI0 /ezQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xRCsc4xoHZsq0aFYRNqiFU69pWqD4YQGF+y3HpRinlw=; b=MNpb+8oWLfO8YaPzct42oE4YtG6OP3iM9u8MlSlbQcMarwViytUOGaBaauSIAncTxu 5xivyymjrg31yjkQhlcUE6XOfMDo4sHRubd1ibDTocKrVVzUONPbdQK4409osLOlTt44 axyr6woOgIAWpQrfgC5n1grQ5bbaT3leYxa7VNm4nUCeABmNdC5+oia48f6eTPnkumRI 74lNhWOWzv5dBIgT2njIUNuU49hEl+xAB0AI3zqdZRWGK+BDlCzT56RomxCYpjKmzMal NmUddQ1Lisx8QOguNqfV1C4XGgJYOtkPnWibuSOqwEILcF5EKT3HwqjA2a9ijP3Wzf3E XQaw== X-Gm-Message-State: AD7BkJL3dbfIYwoQKUzOcpBUTCeyeMqL1qaS8Q9coHj+zcwIR+FRxTlmGdpQLSGfr1t3Kg== X-Received: by 10.98.33.74 with SMTP id h71mr32443451pfh.157.1457987398560; Mon, 14 Mar 2016 13:29:58 -0700 (PDT) Received: from [172.19.58.91] ([175.45.102.173]) by smtp.gmail.com with ESMTPSA id 82sm34151543pfb.64.2016.03.14.13.29.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 13:29:56 -0700 (PDT) To: Tom Herbert , Nick Hilliard References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E71F40.9030102@gmail.com> Date: Tue, 15 Mar 2016 09:29:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: [v6ops] Flow label setting [WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 20:30:01 -0000 On 15/03/2016 07:12, Tom Herbert wrote: ... > iOS already sends non-zero IPv6 flow labels, we have changed Linux > default to use IPv6 flow label so once Android rebases the kernel the > majority of IPv6 end hosts should be sending non-zero flow labels. It > is far easier and shorter time to change the software stacks to send > them than upgrading all the HW in the paths to use them productively. True, and upgrading the client stacks will break the chicken/egg blockage in this case. You don't mention Windows, which is still quite present in the market, and for full impact servers need to be setting the flow label too. Also, what algorithms are the various stacks using? It isn't just a matter of setting any old non-zero value. Brian From nobody Mon Mar 14 13:55:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878CE12D69C for ; Mon, 14 Mar 2016 13:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlgLBhx88_BN for ; Mon, 14 Mar 2016 13:55:19 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829B512D697 for ; Mon, 14 Mar 2016 13:55:19 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2EKtE5V081891 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Mar 2016 20:55:14 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org Message-ID: <56E72531.8080109@foobar.org> Date: Mon, 14 Mar 2016 20:55:13 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tom Herbert References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 20:55:22 -0000 Tom Herbert wrote: > iOS already sends non-zero IPv6 flow labels, we have changed Linux > default to use IPv6 flow label so once Android rebases the kernel > the majority of IPv6 end hosts should be sending non-zero flow > labels. It is far easier and shorter time to change the software > stacks to send them than upgrading all the HW in the paths to use > them productively. I'm not disagreeing, but bear in mind that flow labels were defined over 20 years ago and they're still only used in a minority of cases. All this is slightly beside the point, though - this is an informational draft, simply noting reasons why packets with EHs are dropped. The reason we're writing the draft is that when you turn EHs on, you can expect large-scale packet loss. As far as the authors are concerned, this is a bad thing. Nick From nobody Mon Mar 14 15:32:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B6112D7CD for ; Mon, 14 Mar 2016 15:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTE9ruRVsEgu for ; Mon, 14 Mar 2016 15:32:22 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F72E12D7C9 for ; Mon, 14 Mar 2016 15:32:22 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id n190so2818362iof.0 for ; Mon, 14 Mar 2016 15:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=VsljBgPwhiwaLpLR9BA8tvrHmo1Gf2VMbY4rcOyRwOQ=; b=LK7mDHMpoRcYJO6SFTQIX3K6yEFKaB9ijNoT0kRuyUmN0KeLLGWCEzA7jxnfNng/ZH hL09avi1eUuB4GjIfXepnzcxlK2+CNjt6VJpJcWvx1GP+nTbBpexYiuRJ+5PUTjQFWME 7tPU1hZ/v7oSXHshZWcS7X/UcBCFwL8x30o92fnYrwT1PeRlxTXqyiGjhOp1M4SeAD9y nKzfwyul2AGliOFqqdQ8JX6vzeSmBw9y3dU3zrnYKj46LRoKZlQvipQGiIJ5/502NCLU 6eK7ZdBH2mqKb0CQRcTD5T+VKSi2iSvDRvWnHmxAl3vTXhoYB7BY62Iylu4eONAMEXBo w5Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=VsljBgPwhiwaLpLR9BA8tvrHmo1Gf2VMbY4rcOyRwOQ=; b=AdTXiJejs5ZoL7IWUsxZ+0Ly84xzUvy+dToNvFNtGZ/Xk7fiufKg0rx2RkhvOUjt2P Gc/4wLzn2sYlREWAdPz9OT7y2MIxYML3Aa5W2BCKhl41i1oWBBDG7ZDHL74rxU/p4Ntw /0jXmZK4sDn+KE4AIX4sJiroddfJMi2QrEIrLB09CXBCpc97h1JO4ggAOmY5Xrbo3bqd qbyKIoug/IAzFTucRTrohA9PjDlzZU0U4R1+PN4wWY/6E+b7k63JypOhIgHwP/j/lTLr VHqpWfHcOvDUnAVOkPg/Y5XZ0ty0RMgn5FqNFnwK1cLe5Z1H5zyqfiZ6fMHdY8Vouh4z apUg== X-Gm-Message-State: AD7BkJKiUdxJAJlvt2ag9JmKFu9Fs5Qz2qfWqd01cEHonbMsGgPxg9EP1JZOvl6uEuMkfzPMN3AsT+Ojogx05g== MIME-Version: 1.0 X-Received: by 10.107.152.142 with SMTP id a136mr26704482ioe.84.1457994741614; Mon, 14 Mar 2016 15:32:21 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Mon, 14 Mar 2016 15:32:21 -0700 (PDT) In-Reply-To: <56E71F40.9030102@gmail.com> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <56E71F40.9030102@gmail.com> Date: Mon, 14 Mar 2016 15:32:21 -0700 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Flow label setting [WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 22:32:24 -0000 On Mon, Mar 14, 2016 at 1:29 PM, Brian E Carpenter wrote: > On 15/03/2016 07:12, Tom Herbert wrote: > ... >> iOS already sends non-zero IPv6 flow labels, we have changed Linux >> default to use IPv6 flow label so once Android rebases the kernel the >> majority of IPv6 end hosts should be sending non-zero flow labels. It >> is far easier and shorter time to change the software stacks to send >> them than upgrading all the HW in the paths to use them productively. > > True, and upgrading the client stacks will break the chicken/egg > blockage in this case. > > You don't mention Windows, which is still quite present in the market, > and for full impact servers need to be setting the flow label too. > > Also, what algorithms are the various stacks using? It isn't just a matter > of setting any old non-zero value. > - FreeBSD (and presumably iOS): sets the flow label for a new connection using the ip6_randomflowlabel function. This calls randomid() which implements a pseudo random number generator. Flow label is saved in connection state for use in transmitted packets. This automatic flow label generation is controlled by a socket option and a sysctl. - Linux (e.g. Android will): sets the flow label for new connections (TCP or connected UDP socket) using prandom_u32 (pseudo random number). The flow label for a connection may change if the connection is failing in hopes of finding a better route-- either the networking stack detects a bad route (i.e. TCP is retransmitting) or userspace can request a route change if it has information about path quality. So flow labels are not necessarily persistent which probably makes flow label filtering a bad idea at least if persistence for the lifetime of a connection is required for that (see http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf). For cases with no connection state (unconnected UDP, forward and encapsulate), the flow label is generated by parsing the packet to determine a hash based on L3/L4 information. - Windows: I believe you mentioned that Windows 7 doesn't seem to have support for setting flow labels. Maybe someone from Microsoft can clarify this and let us know what the prospects are for getting flow label support. These describe use of stateless flow labels. There are also interfaces to set specific stateful flow labels, but since on the wire there is no distinction between stateful and stateless labels we need to assume that stateful labels retain reasonable properties for stateless uses like ECMP (as in sec. 3 of RFC6437), however there is no effort by the stack to enforce any properties of stateful labels. Tom > Brian From nobody Mon Mar 14 20:05:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E121C12D52A for ; Mon, 14 Mar 2016 20:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljrp6tgRTcIH for ; Mon, 14 Mar 2016 20:05:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A686E12D615 for ; Mon, 14 Mar 2016 20:05:08 -0700 (PDT) Received: from [107.18.198.226] ([107.18.198.226]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u2F34S7Z008905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2016 20:04:31 -0700 (PDT) To: Nick Hilliard , Tom Herbert References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <56E72531.8080109@foobar.org> From: Joe Touch Message-ID: <56E77BB9.5080903@isi.edu> Date: Mon, 14 Mar 2016 20:04:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E72531.8080109@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 03:05:11 -0000 On 3/14/2016 1:55 PM, Nick Hilliard wrote: > I'm not disagreeing, but bear in mind that flow labels were defined over > 20 years ago and they're still only used in a minority of cases. The same might be said for IPv6 itself: https://eggert.org/meter/ipv6 From nobody Mon Mar 14 20:09:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B63412D6A6 for ; Mon, 14 Mar 2016 20:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BUdL3lSUX0L for ; Mon, 14 Mar 2016 20:09:28 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B70212D840 for ; Mon, 14 Mar 2016 20:09:28 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id u190so8012624pfb.3 for ; Mon, 14 Mar 2016 20:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SF6g2l1RbszTVmchDhHE5/04Z/h9I3Hj/0qWvBwBYrU=; b=flal3L6v4XKCmUVNyWUR7A/DMygaLdw1rK1ZD1qh7tPViySX2Km+p397N0ApcPcgsA kIO5hgLYfC4wqOP6xCif4Cv9oNntF1+6RD2yabzAsWzRNSRWMw9rRn2nmZll36G2rc38 Z3b96NYVBoeu0Z7uVF7U+VwDJfh8KfOV1UTXgBC4xLpufexNV3w4Xmhtu4TFcHylK9v2 tov9hPv7J1qqDMvEslxB2og5Bl3b4y61RZ6QBuHfQITkamc69bZRZ2ZPwu4PADahhV5c TmD3p2jgNRgIi5Y3jaW4dINFFil/Fflo32xz80eE7gT0fbvZzSlYXl9S9xeiyxNdHp8+ K4Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SF6g2l1RbszTVmchDhHE5/04Z/h9I3Hj/0qWvBwBYrU=; b=DLpdIGGQCD4cq1G5nnQWXUqVVc868t0RNNjRtE5cX3PBGoJ09+Cu8bxbuOLjvAQAeE P3TKOTxSCwL2+XBeV/Ho8TDoWgdionbJXsX5EhIkznRKwxkXpO8Q90CuekRsjQXrKMJZ WGfhcqumofE+GcBliDN80ajFV7ZqqcmVtyVFWcmZlZYom29p3w6wcOIHrbv3d79vYAMt JWIRR0xQn7piDcW2QI/aKga5LYBwlnZsdr8Kb6EvzdrR4LF5oaB/Qyj6dzIh114HWoC9 n3iUvavRZxK/zpAqHvS/vf0Icyir6xWJf1r83XMltngwclNDRP9Juw8J4YsTK8izboj3 ZtoQ== X-Gm-Message-State: AD7BkJLnq2A7uCg9oUvzM/5IwsfPI+9lo/FvR3EYmr19zT66+gJJVGQQoNobk8VETo1Oug== X-Received: by 10.66.152.231 with SMTP id vb7mr43127744pab.132.1458011367627; Mon, 14 Mar 2016 20:09:27 -0700 (PDT) Received: from [10.1.9.199] ([103.23.18.15]) by smtp.gmail.com with ESMTPSA id p74sm35247015pfa.11.2016.03.14.20.09.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 20:09:26 -0700 (PDT) To: Tom Herbert References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <56E71F40.9030102@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E77CE4.2010303@gmail.com> Date: Tue, 15 Mar 2016 16:09:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Flow label setting [WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 03:09:30 -0000 On 15/03/2016 11:32, Tom Herbert wrote: ... > - Linux (e.g. Android will): sets the flow label for new connections > (TCP or connected UDP socket) using prandom_u32 (pseudo random > number). The flow label for a connection may change if the connection > is failing in hopes of finding a better route In that case, it really doesn't matter as far as ECMP or load balancing goes if the flow label changes, since the path will be changing anyway. (OK, it might matter for server load balancing at the destination, but that is a corner case that has to be dealt with regardless.) > -- either the networking > stack detects a bad route (i.e. TCP is retransmitting) or userspace > can request a route change if it has information about path quality. > So flow labels are not necessarily persistent which probably makes > flow label filtering a bad idea It's a bad idea, period. If you are trying to detect malicious traffic you will need DPI anyway. > at least if persistence for the > lifetime of a connection is required for that (see > http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf). For cases with no > connection state (unconnected UDP, forward and encapsulate), the flow > label is generated by parsing the packet to determine a hash based on > L3/L4 information. > > - Windows: I believe you mentioned that Windows 7 doesn't seem to have > support for setting flow labels. I couldn't find anything. Presumably it can be done by apps through the Winsock API, but that isn't very useful. > Maybe someone from Microsoft can > clarify this and let us know what the prospects are for getting flow > label support. Please. Brian From nobody Mon Mar 14 20:52:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69C312D8A4 for ; Mon, 14 Mar 2016 20:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI2QSNXrvwWc for ; Mon, 14 Mar 2016 20:52:09 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6B912D7CB for ; Mon, 14 Mar 2016 20:52:09 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id h129so6280279ywb.1 for ; Mon, 14 Mar 2016 20:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LtjQVSovTdeZBLdcilyMj0DCl4Q6gaoNd5NE05x2Sks=; b=MlOdcDj+8T38BXsvuzRXgk4fV0da6AtEgJnrK9gT6F8sov+4A884QaXwqiQTM2KL8e 3A2jxbOs7+0UR4aXS5+i6qvvsrNblYvT86vTzRyk2dSF+a+DwGlXp68oE66yLSJotxkI INsk9A5uKnnIRlXkWJvoKGDiK/qiTNAasN5Zf7q/1raU6Q8vqO9oIngq+bcD9/kunSm+ mzBsaAUXYsD+Zue1ZR0ahD8tA/5jZ4yFK8bjTXRkVseaxCBmQibHRcYuLyK9ySX+7GFI 84l9+gEQtGn2OfM74iHtal0T4qXFqG9aLKej6gy/6qQtEYYGNYa71pAjnyIfOK2vAIF7 e0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LtjQVSovTdeZBLdcilyMj0DCl4Q6gaoNd5NE05x2Sks=; b=C6Uq9KYCleOHkWJSny5rk2fbHAeD3bbZfmYmHkjJCc4TlHr6pmfR9GfPUnZ7FFHg+E PvBXLLItPrzjD+3jUHyQ6VKWl7qzCadAR9TjwN4HkWxGdvC6rvwDNlN8kz4+COe9NCvP MPLQj/QHRA1gZjBteK0o2R3I+p7yZqIa1lQbvR4L0Y0twsm3QFbuyQeTU8qy9UU0Zp38 b5ehftru4MNpC47K8xPPICykFDXUL+qBXmmwTrqtu8nWUX/JAGrlvVZM5O+gKn3m5uX5 DEtWX11wtxvyDsZjjQTFRJTV+ugDOVOm4KZTPCQreHvuHitDM5W5b0yQZ2B3UOTythE4 tYdg== X-Gm-Message-State: AD7BkJLgmDVoZTTEURblg5ZDj4uxrjeLsl7noeLGau2btjghTbp3ZyrY+xTrIateT/bw/HdOoiPoOYR/m3w4/rya X-Received: by 10.13.210.67 with SMTP id u64mr13603864ywd.42.1458013928895; Mon, 14 Mar 2016 20:52:08 -0700 (PDT) MIME-Version: 1.0 References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> In-Reply-To: From: Warren Kumari Date: Tue, 15 Mar 2016 03:51:59 +0000 Message-ID: To: Tom Herbert , Nick Hilliard Content-Type: multipart/alternative; boundary=001a114e7e304f701c052e0e529c Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 03:52:12 -0000 --001a114e7e304f701c052e0e529c Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 2:12 AM Tom Herbert wrote: > On Mon, Mar 14, 2016 at 10:59 AM, Nick Hilliard wrote: > > Tom Herbert wrote: > >> From that point of view, the IPv6 flow label "works best" for ECMP > >> and so the three tuple hash (addresses and flow label) should be the > >> recommended method for ECMP devices to implement. > > > > Tom, > > > > Everyone agrees with this. The problem is that core and leaf operators > > are not in control of flow label generation at the edge, and many > > operating systems do not bother to set the flow label. In other words, > > flow labels do not currently provide enough entropy to be useful for > > flow hash generation in most instances. > > > > Everyone understands that flow labels would help this problem. This > > draft is about what happens when the flow label is zero, which is the > > case more often than not. > > > > Nick, > > iOS already sends non-zero IPv6 flow labels, we have changed Linux > default to use IPv6 flow label so once Android rebases the kernel the > majority of IPv6 end hosts should be sending non-zero flow labels. Yah, bring on the non-zero labels. It is far easier and shorter time to change the software stacks to send > them than upgrading all the HW in the paths to use them productively. > Goodness, yes. > But compared the problem of HW being able to efficiently parse > arbitrarily long header chains, I still think this is a very solvable > problem. > Yup. Ubiquitous flow labels will solve *one* of the issues with long header chains, but in the remaining cases (my personal bugbear is filtering (for dos and ingress / edge filters)) the hardware still need to be capable of doing it (at line-rate). W > > Tom > > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114e7e304f701c052e0e529c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 15= , 2016 at 2:12 AM Tom Herbert <to= m@herbertland.com> wrote:
On= Mon, Mar 14, 2016 at 10:59 AM, Nick Hilliard <nick@foobar.org> wrote:
> Tom Herbert wrote:
>> From that point of view, the IPv6 flow label "works best"= ; for ECMP
>> and so the three tuple hash (addresses and flow label) should be t= he
>> recommended method for ECMP devices to implement.
>
> Tom,
>
> Everyone agrees with this.=C2=A0 The problem is that core and leaf ope= rators
> are not in control of flow label generation at the edge, and many
> operating systems do not bother to set the flow label.=C2=A0 In other = words,
> flow labels do not currently provide enough entropy to be useful for > flow hash generation in most instances.
>
> Everyone understands that flow labels would help this problem.=C2=A0 T= his
> draft is about what happens when the flow label is zero, which is the<= br> > case more often than not.
>

Nick,

iOS already sends non-zero IPv6 flow labels, we have changed Linux
default to use IPv6 flow label so once Android rebases the kernel the
majority of IPv6 end hosts should be sending non-zero flow labels.

Yah, bring on the non-zero labels.=C2=A0
=
It=C2=A0is far easier and shorter= time to change the software stacks to send
them than upgrading all the HW in the paths to use them productively.

Goodness, yes.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> But compared the problem of HW being able to efficiently parse
arbitrarily long header chains, I still think this is a very solvable
problem.

Yup. Ubiquitous flow labels wi= ll solve *one* of the issues with long header chains, but in the remaining = cases (my personal bugbear is filtering (for dos and ingress / edge filters= )) the hardware still need to be capable of doing it (at line-rate).=C2=A0<= /div>

=C2=A0W

Tom

> Nick

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114e7e304f701c052e0e529c-- From nobody Mon Mar 14 23:36:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E8D12D7F1 for ; Mon, 14 Mar 2016 23:36:32 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 544_i_HrDP6G for ; Mon, 14 Mar 2016 23:36:30 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064B112D596 for ; Mon, 14 Mar 2016 23:36:29 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id d65so9402402ywb.0 for ; Mon, 14 Mar 2016 23:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ieg7EO1VL4/80Vd/ogSDFYRLUZBwh4tgM3VHXefUYmg=; b=B5cbTG0/7/HheLCN0XGICgPo7lRZDL+ATLfHhNIHud8czNtuLK1wnI4bQE3aCSy0xc K8fu/A6t1kN43H7C2TFFwXm6EGAiH2V2O0COvQIL7x+XbTlCp+6guoCxJpfUnMumtn/f vkQ81ONBz1CJ4X0sZuzW1jodm7UsOMqM9sFvfI5bCxdjRZhkcMPJ4fFw49owz2LNIKQ6 9KNJNzvngn/4MY6IAagW3n7yX+WqNK8XnBWDFfddZ0IDKKsTLvoiBmYwtf0Z8Svg+R/v 6YsJ/AU7huxQ3YCQd3O4hhYF7ZQehjPWrdsp5mg39uyWb/sEDbBFiUtwgwD7IQOagxzU xnuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ieg7EO1VL4/80Vd/ogSDFYRLUZBwh4tgM3VHXefUYmg=; b=QdUTef67fmh9sI227Ds8OO8t2xAtA93gZFSCqClrj+dWBL/a4za9aNWXLTv0dnr8O3 dq0QyVJQntxs8JW78N8rU5jgF/lu1usc+De76xrDK7OO4TaVFH5OZWMFAxTneWfvI6yL L3adQyzjNGqzIovEEgelO54QgW+M2NW3IP7cW8BLH84RnJ1kGaPrNKlHWjFgWoX6TlJO VBQuQ6ltLwMIv+eLJkUJDEaxsoKs/XFkDX6olXNre+kk7BrN9/jutPONubtlnlw+6wlu 68WOe2Wy2fPIurEkswk22LyVyzpy1zBBt1ocy2zo9Ttqgp5GB6gY/GpZl0tWaX7El2IM rAbQ== X-Gm-Message-State: AD7BkJIoMFMvTRGNcShvewGwmrMnIfwF2dorxM3UqK5GJPsvFZzi9/cMmqIrhWHHUzbKxpankjG9DAU0g70r4Q4d X-Received: by 10.13.214.142 with SMTP id y136mr13815061ywd.105.1458023789274; Mon, 14 Mar 2016 23:36:29 -0700 (PDT) MIME-Version: 1.0 References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <56E71F40.9030102@gmail.com> <56E77CE4.2010303@gmail.com> In-Reply-To: <56E77CE4.2010303@gmail.com> From: Warren Kumari Date: Tue, 15 Mar 2016 06:36:19 +0000 Message-ID: To: Brian E Carpenter , Tom Herbert Content-Type: multipart/alternative; boundary=94eb2c0762e608d847052e109ea9 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Flow label setting [WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 06:36:32 -0000 --94eb2c0762e608d847052e109ea9 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 11:09 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 15/03/2016 11:32, Tom Herbert wrote: > > ... > > - Linux (e.g. Android will): sets the flow label for new connections > > (TCP or connected UDP socket) using prandom_u32 (pseudo random > > number). The flow label for a connection may change if the connection > > is failing in hopes of finding a better route > > In that case, it really doesn't matter as far as ECMP or load balancing > goes > if the flow label changes, since the path will be changing anyway. > (OK, it might matter for server load balancing at the destination, > but that is a corner case that has to be dealt with regardless.) > > > -- either the networking > > stack detects a bad route (i.e. TCP is retransmitting) or userspace > > can request a route change if it has information about path quality. > > So flow labels are not necessarily persistent which probably makes > > flow label filtering a bad idea > > It's a bad idea, period. If you are trying to detect malicious traffic > you will need DPI anyway. > ... but, but, what if you are trying to use this to permit *good* traffic?! You just *know* that if you provide the ability to filter on flow labels that some silly monkey will invent some horrendous hack where you have to portknock on the SSH port with the flowlabel set to 0xBAA. Or "firewall" their corporate network to only allow flowlables of 0x123 (and provide a client that sets the flowlabel on all packets sent to that network to 0x123). Oh! Huh! Nftable provides the "ipv6 flowlabel" matching primitive. And I can just stuff (0xBAA & IPV6_FLOWINFO_FLOWLABEL) into flr_label... Oh no... I'm the stupid monkey here... :-P W > > > at least if persistence for the > > lifetime of a connection is required for that (see > > http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf). For cases with no > > connection state (unconnected UDP, forward and encapsulate), the flow > > label is generated by parsing the packet to determine a hash based on > > L3/L4 information. > > > > - Windows: I believe you mentioned that Windows 7 doesn't seem to have > > support for setting flow labels. > > I couldn't find anything. Presumably it can be done by apps through the > Winsock API, but that isn't very useful. > > > Maybe someone from Microsoft can > > clarify this and let us know what the prospects are for getting flow > > label support. > > Please. > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c0762e608d847052e109ea9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue= , Mar 15, 2016 at 11:09 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 15/03/2016 11:32, Tom Herbert wrote:

...
> - Linux (e.g. Android will): sets the flow label for new connections > (TCP or connected UDP socket) using prandom_u32 (pseudo random
> number). The flow label for a connection may change if the connection<= br> > is failing in hopes of finding a better route

In that case, it really doesn't matter as far as ECMP or load balancing= goes
if the flow label changes, since the path will be changing anyway.
(OK, it might matter for server load balancing at the destination,
but that is a corner case that has to be dealt with regardless.)

> -- either the networking
> stack detects a bad route (i.e. TCP is retransmitting) or userspace > can request a route change if it has information about path quality. > So flow labels are not necessarily persistent which probably makes
> flow label filtering a bad idea

It's a bad idea, period. If you are trying to detect malicious traffic<= br> you will need DPI anyway.

... but, but,= what if you are trying to use this to permit *good* traffic?!
You just *know* that if you provide the ability to filter on f= low labels that some silly monkey will invent some horrendous hack where yo= u have to portknock on the SSH port with the flowlabel set to 0xBAA. Or &qu= ot;firewall" their corporate network to only allow flowlables of 0x123= (and provide a client that sets the flowlabel on all packets sent to that = network to 0x123).
=C2=A0
Oh! Huh! Nftable provides the= "ipv6 flowlabel" matching primitive.=C2=A0
And I can j= ust stuff (0xBAA & IPV6_FLOWINFO_FLOWLABEL) into=C2=A0flr_label...
<= /div>

Oh no... I'm the stupid monkey here...=C2=A0

:-P
=C2=A0
W

> at least if persistence for the
> lifetime of a connection is required for that (see
> http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf<= /a>). For cases with no
> connection state (unconnected UDP, forward and encapsulate), the flow<= br> > label is generated by parsing the packet to determine a hash based on<= br> > L3/L4 information.
>
> - Windows: I believe you mentioned that Windows 7 doesn't seem to = have
> support for setting flow labels.

I couldn't find anything. Presumably it can be done by apps through the=
Winsock API, but that isn't very useful.

> Maybe someone from Microsoft can
> clarify this and let us know what the prospects are for getting flow > label support.

Please.
=C2=A0 =C2=A0Brian

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--94eb2c0762e608d847052e109ea9-- From nobody Mon Mar 14 23:58:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE8612D8E7 for ; Mon, 14 Mar 2016 23:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg0icrDB9PaF for ; Mon, 14 Mar 2016 23:57:56 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A45612D841 for ; Mon, 14 Mar 2016 23:57:56 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id u190so15959403pfb.3 for ; Mon, 14 Mar 2016 23:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=iApJx6W68nO0IqVBoY+8I1qPZ5ZU32up+BAzA5YnZnk=; b=XW8WAuVAXubBN7RdanuY/Td6f34P9/aAQi1S+/0mW+WtMBuitjbGRlsb+FBMhbN7oV 0rS6oUIxkW1IgLEPC66s5AtfcOXHJndlJYjM0UKCTX4cTCV97mOm0wNkpG9L4aU85aZv tqTbLYomRWBcKnj7gpCqGgCmO6BoCjhVBLvg5/XXLTtCwBNjlJzjMZJrEMOrPjr2m6Xh gZNFqjVxvFFSLk1ng/82bksoKYM0n+8W1/zhfVwAIIO66pzgoUWNTzI8SZJ5D6oAIJ6A r6kTsOJrM149KPsQsShvJdsDclX71Ae05fCjFS5BBcHVEixHVwLe5KeI2rWChHtGgIkP 83zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=iApJx6W68nO0IqVBoY+8I1qPZ5ZU32up+BAzA5YnZnk=; b=eGW2hCUuNJCe2Oy9Jg3JT7yDofv+U6E+3n2n1nKumCLDGQt3Age9vcjmm9AdvMJ1+i Yhss+1/WqE2B5vyyBRHzrBPoZjm9H4oZqlKJ8PLleRB7FtQlnA8ZjwIwyjoR81DVuDiQ iSJ25qDtijJ1vwU3viOMZl80Q78Zo+jUX+4s0PD/aPJRAphn0mA5gUJY4e0E4f/rtl6g YX4/41zCN7gUJUGZEt1KlV4oSja1y2Y0iRihXBzBq7m5s6BnjHGf2dubfx9OpsBI7T37 GkCvejXygoFWuqX6GR8sIe8qIM7Uwt3YBGIs9k8TONeD5q9lThl9VJtZdhgnz5x4XGJ3 l1wA== X-Gm-Message-State: AD7BkJLdiQGByytpe03Jdn0pBv3rbgweXgwrWO5lF6RNcU3HRXMJsqBzU84Pb532wjXkaQ== X-Received: by 10.67.5.133 with SMTP id cm5mr43938017pad.133.1458025076075; Mon, 14 Mar 2016 23:57:56 -0700 (PDT) Received: from [10.1.9.199] ([103.23.18.15]) by smtp.gmail.com with ESMTPSA id fw9sm22183772pac.21.2016.03.14.23.57.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 23:57:54 -0700 (PDT) To: Warren Kumari , Tom Herbert References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <56E71F40.9030102@gmail.com> <56E77CE4.2010303@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E7B271.2020909@gmail.com> Date: Tue, 15 Mar 2016 19:57:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Flow label setting [WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 06:57:59 -0000 Warren, A 20-bit hash of the evil bit? Regards Brian On 15/03/2016 19:36, Warren Kumari wrote: > On Tue, Mar 15, 2016 at 11:09 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 15/03/2016 11:32, Tom Herbert wrote: >> >> ... >>> - Linux (e.g. Android will): sets the flow label for new connections >>> (TCP or connected UDP socket) using prandom_u32 (pseudo random >>> number). The flow label for a connection may change if the connection >>> is failing in hopes of finding a better route >> >> In that case, it really doesn't matter as far as ECMP or load balancing >> goes >> if the flow label changes, since the path will be changing anyway. >> (OK, it might matter for server load balancing at the destination, >> but that is a corner case that has to be dealt with regardless.) >> >>> -- either the networking >>> stack detects a bad route (i.e. TCP is retransmitting) or userspace >>> can request a route change if it has information about path quality. >>> So flow labels are not necessarily persistent which probably makes >>> flow label filtering a bad idea >> >> It's a bad idea, period. If you are trying to detect malicious traffic >> you will need DPI anyway. >> > > ... but, but, what if you are trying to use this to permit *good* traffic?! > > You just *know* that if you provide the ability to filter on flow labels > that some silly monkey will invent some horrendous hack where you have to > portknock on the SSH port with the flowlabel set to 0xBAA. Or "firewall" > their corporate network to only allow flowlables of 0x123 (and provide a > client that sets the flowlabel on all packets sent to that network to > 0x123). > > Oh! Huh! Nftable provides the "ipv6 flowlabel" matching primitive. > And I can just stuff (0xBAA & IPV6_FLOWINFO_FLOWLABEL) into flr_label... > > Oh no... I'm the stupid monkey here... > > :-P > > W > >> >>> at least if persistence for the >>> lifetime of a connection is required for that (see >>> http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf). For cases with no >>> connection state (unconnected UDP, forward and encapsulate), the flow >>> label is generated by parsing the packet to determine a hash based on >>> L3/L4 information. >>> >>> - Windows: I believe you mentioned that Windows 7 doesn't seem to have >>> support for setting flow labels. >> >> I couldn't find anything. Presumably it can be done by apps through the >> Winsock API, but that isn't very useful. >> >>> Maybe someone from Microsoft can >>> clarify this and let us know what the prospects are for getting flow >>> label support. >> >> Please. >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Tue Mar 15 00:03:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F9B12D51E for ; Tue, 15 Mar 2016 00:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pluribusnetworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3DAf9qoVFP4 for ; Tue, 15 Mar 2016 00:03:32 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5A612D8E1 for ; Tue, 15 Mar 2016 00:03:32 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id n5so16183798pfn.2 for ; Tue, 15 Mar 2016 00:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pluribusnetworks.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=kj77GXanwkkbuSWEZToIsTPlJl4xeAJUpeE7WjV7ei8=; b=E0o8wVPZN0n/1gEmBEr6gK/i/3fgMWUL/P/bhSEglwElgleaP2XPs94u3eBwAYCEl/ U+Eejp6BL4HQ+Kbl7dMTwOhxA6aCj6P6jPhdwxcfFyslGVRyoQkjMCHkVIyydGAcM579 NvEaI4jw+aawCK4ntoZOWaz6XcWcdv05N0SSI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kj77GXanwkkbuSWEZToIsTPlJl4xeAJUpeE7WjV7ei8=; b=M7IRcRndj7e9BIKSCBen6VREqZTS89dpvzj8XjFFG2Rcqf/6vaWsKV6vhPwnlRlefa VFHkyqZ7JvuLs+7yLDXOz6yJ5x1VlFW6AbBciKHxNHQDHDfRf+4w75ringU85DWViy9p GMSeMDSA+/x5yhSLnInS1cYXDB1d47sL239SSlGLCSfPDvzz3FK5MLqNIOWkE3tL3Lpb rxCtFIUbwDTTKswg2qYftaHkrCtNu1VIDWKCQPgJHoFEC7rlYzfw9lQogz9dY3Ek9MEQ aPnTa/FYwyW1Lf7jmHPE410N2u6/2fcC38OP4l0G8jWKeLfflXozGUW5940yqux8iusR 6SGQ== X-Gm-Message-State: AD7BkJLH3huWhwEWBtLMtOA7oesBP5c5e60+d27RIjG0lhDzRDUtQnzRP0gvIwnm/sO4WeJv X-Received: by 10.66.222.129 with SMTP id qm1mr43840454pac.22.1458025411814; Tue, 15 Mar 2016 00:03:31 -0700 (PDT) Received: from Sonums-MacBook-Pro.local ([98.234.171.61]) by smtp.gmail.com with ESMTPSA id l88sm15578164pfj.7.2016.03.15.00.03.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 00:03:31 -0700 (PDT) To: otroan@employees.org References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> From: Sonum Mathur Message-ID: <56E7B3C2.6070507@pluribusnetworks.com> Date: Tue, 15 Mar 2016 00:03:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 07:03:35 -0000 Ole, Thanks for the response. RFC 4541 says SrcIP should be 'all-zeros'. But it is observed that Linux just drops the Query if SrcIP is not a Link-local Address. Solaris seems to accept anything - not sure about Windows or other stacks. Not just for hosts, for snooping switches to inter operate, they need to identify each other. Otherwise we create a dis-connect between the snooping switches. This is when there is no Router on the subnet. If there is no standard IP Address, then this becomes a problem. Can't use 'all-zeros' for MLD as Linux accepts non-zero link-local address. Regards -- Sonum On 3/12/16 9:23 AM, otroan@employees.org wrote: >> If there are no Routers involved, it is Snooping switch responsibility to send MLD Query to keep the groups alive on the switch. >> >What is the correct correct Source IP to use for General Queries ? Is it Src IP all 0 or some link-local Address ? Which host stack would like/accept what Source IP ? Have observed different observations with different host stacks. > see rfc4541. > From nobody Tue Mar 15 00:28:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D947B12D905 for ; Tue, 15 Mar 2016 00:28: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTRyWDtXDhMN for ; Tue, 15 Mar 2016 00:28:52 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDFB12D80B for ; Tue, 15 Mar 2016 00:28:51 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id d65so10494836ywb.0 for ; Tue, 15 Mar 2016 00:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8AxbdZKnh98He/Z15/nD8hagvuXTgPLaBdVBGhDhQtE=; b=uPFVEt9/EvP3+CSDJKzkhBA9qEYIbONn7exC05uvUtcaPBjY5u50BBXX6x+1vQtb5O D8dJJuii4XP81hDXCQjfqhe1Q6Foks0ZKsK0aNuDcdwn63C9bO5k4P9mY+4cMdKMHEfQ Hw4SfPL8ji1FTaQ2H2DqF4Y4BKZ6TDE9AKtTxVPvJIdBQgJzTQpAzYMueHa0ytSrau5P /d08U4Ycnx1XmxgiU20L/JsixHKc3IpLneiZt4gkLO+IyKnOu5qWBaa1JkDaSpmAKEV0 ZG+8JUbjWSHM6judTaKxTC6KbdavBAcw0F5XHNOckZEiORFM0WWRlo+THqIEEMkgjuV8 iSUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8AxbdZKnh98He/Z15/nD8hagvuXTgPLaBdVBGhDhQtE=; b=QoQclQTC7MnkREE+7nRoczV0d5cir9gQ580KsMgCwMNoZQxdOxZZIP23due6xGIgtG ZcGYvKhOxqgH8wTJ7JvmbXvCtwzFY9ewlzK5MyZP3XEkvjLMtbzsxjRrJ1VqWq3WSAfW 7gms2so8pHsMl7JrYDVdo4V/CJ6DdxKAFkuoZn6UIgU+O+UxAijgK7XTNBzF8zEKY7Ok ao7SMw821lrJ1rU06DfiIoqQgZ9I/FW/qRIJeAxIcNGp5D+oYQ7Sri0FG1Q+yvAvSf+P ACw27IcJrPq0wSNlEUeMR1bSQjSosfqF4Jh27Q47nR1rrWfSmgm2AGslcbdfaGcm9a+9 APBQ== X-Gm-Message-State: AD7BkJJokVMA9BQnkyHiC8/DoHVxY6fDfxB2/A3G/JWgkO12HubmOBB28q9HDex69M/83OwSq1h7HtZ2qrCB4sAN X-Received: by 10.13.214.142 with SMTP id y136mr13890013ywd.105.1458026931100; Tue, 15 Mar 2016 00:28:51 -0700 (PDT) MIME-Version: 1.0 References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <56E71F40.9030102@gmail.com> <56E77CE4.2010303@gmail.com> <56E7B271.2020909@gmail.com> In-Reply-To: <56E7B271.2020909@gmail.com> From: Warren Kumari Date: Tue, 15 Mar 2016 07:28:41 +0000 Message-ID: To: Brian E Carpenter , Tom Herbert Content-Type: multipart/alternative; boundary=94eb2c0762e64d4a49052e115998 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Flow label setting [WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 07:28:55 -0000 --94eb2c0762e64d4a49052e115998 Content-Type: text/plain; charset=UTF-8 $ ipython In [1]: import md5 In [2]: for evil_bit in [0,1]: ...: print hex(int(md5.md5(chr(evil_bit)).hexdigest(), base=16) & 0x0fffff) ...: 0x59f71L 0x1df41L In [3]: Yup, that looks to be about how much entropy we currently see in flow-labels... actually, a bit more... W On Tue, Mar 15, 2016 at 2:57 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Warren, > > A 20-bit hash of the evil bit? > > Regards > Brian > > On 15/03/2016 19:36, Warren Kumari wrote: > > On Tue, Mar 15, 2016 at 11:09 AM Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 15/03/2016 11:32, Tom Herbert wrote: > >> > >> ... > >>> - Linux (e.g. Android will): sets the flow label for new connections > >>> (TCP or connected UDP socket) using prandom_u32 (pseudo random > >>> number). The flow label for a connection may change if the connection > >>> is failing in hopes of finding a better route > >> > >> In that case, it really doesn't matter as far as ECMP or load balancing > >> goes > >> if the flow label changes, since the path will be changing anyway. > >> (OK, it might matter for server load balancing at the destination, > >> but that is a corner case that has to be dealt with regardless.) > >> > >>> -- either the networking > >>> stack detects a bad route (i.e. TCP is retransmitting) or userspace > >>> can request a route change if it has information about path quality. > >>> So flow labels are not necessarily persistent which probably makes > >>> flow label filtering a bad idea > >> > >> It's a bad idea, period. If you are trying to detect malicious traffic > >> you will need DPI anyway. > >> > > > > ... but, but, what if you are trying to use this to permit *good* > traffic?! > > > > You just *know* that if you provide the ability to filter on flow labels > > that some silly monkey will invent some horrendous hack where you have to > > portknock on the SSH port with the flowlabel set to 0xBAA. Or "firewall" > > their corporate network to only allow flowlables of 0x123 (and provide a > > client that sets the flowlabel on all packets sent to that network to > > 0x123). > > > > Oh! Huh! Nftable provides the "ipv6 flowlabel" matching primitive. > > And I can just stuff (0xBAA & IPV6_FLOWINFO_FLOWLABEL) into flr_label... > > > > Oh no... I'm the stupid monkey here... > > > > :-P > > > > W > > > >> > >>> at least if persistence for the > >>> lifetime of a connection is required for that (see > >>> http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf). For cases with no > >>> connection state (unconnected UDP, forward and encapsulate), the flow > >>> label is generated by parsing the packet to determine a hash based on > >>> L3/L4 information. > >>> > >>> - Windows: I believe you mentioned that Windows 7 doesn't seem to have > >>> support for setting flow labels. > >> > >> I couldn't find anything. Presumably it can be done by apps through the > >> Winsock API, but that isn't very useful. > >> > >>> Maybe someone from Microsoft can > >>> clarify this and let us know what the prospects are for getting flow > >>> label support. > >> > >> Please. > >> Brian > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > --94eb2c0762e64d4a49052e115998 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
$ ipython
In [1]: import md5
In [2]: for evil_bit in [0,1]:
=C2=A0 =C2=A0...: =C2=A0 =C2=A0 p= rint hex(int(md5.md5(chr(evil_bit)).hexdigest(), base=3D16) & 0x0fffff)=
=C2=A0 =C2=A0...:
0x59f71L
0x1df41L
In [3]:

Yup, that looks to be about how mu= ch entropy we currently see in flow-labels... actually, a bit more...
=

<warren runs away, chortling manically>
W


On Tue, Mar 15, 2016 at 2:57 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
<= /div>
Warren,

A 20-bit hash of the evil bit?

Regards
=C2=A0 =C2=A0Brian

On 15/03/2016 19:36, Warren Kumari wrote:
> On Tue, Mar 15, 2016 at 11:09 AM Brian E Carpenter <
> brian= .e.carpenter@gmail.com> wrote:
>
>> On 15/03/2016 11:32, Tom Herbert wrote:
>>
>> ...
>>> - Linux (e.g. Android will): sets the flow label for new conne= ctions
>>> (TCP or connected UDP socket) using prandom_u32 (pseudo random=
>>> number). The flow label for a connection may change if the con= nection
>>> is failing in hopes of finding a better route
>>
>> In that case, it really doesn't matter as far as ECMP or load = balancing
>> goes
>> if the flow label changes, since the path will be changing anyway.=
>> (OK, it might matter for server load balancing at the destination,=
>> but that is a corner case that has to be dealt with regardless.) >>
>>> -- either the networking
>>> stack detects a bad route (i.e. TCP is retransmitting) or user= space
>>> can request a route change if it has information about path qu= ality.
>>> So flow labels are not necessarily persistent which probably m= akes
>>> flow label filtering a bad idea
>>
>> It's a bad idea, period. If you are trying to detect malicious= traffic
>> you will need DPI anyway.
>>
>
> ... but, but, what if you are trying to use this to permit *good* traf= fic?!
>
> You just *know* that if you provide the ability to filter on flow labe= ls
> that some silly monkey will invent some horrendous hack where you have= to
> portknock on the SSH port with the flowlabel set to 0xBAA. Or "fi= rewall"
> their corporate network to only allow flowlables of 0x123 (and provide= a
> client that sets the flowlabel on all packets sent to that network to<= br> > 0x123).
>
> Oh! Huh! Nftable provides the "ipv6 flowlabel" matching prim= itive.
> And I can just stuff (0xBAA & IPV6_FLOWINFO_FLOWLABEL) into flr_la= bel...
>
> Oh no... I'm the stupid monkey here...
>
> :-P
>
> W
>
>>
>>> at least if persistence for the
>>> lifetime of a connection is required for that (see
>>> http://www.maths.tcd.ie/~dwmalone/p/ec2n= d05.pdf). For cases with no
>>> connection state (unconnected UDP, forward and encapsulate), t= he flow
>>> label is generated by parsing the packet to determine a hash b= ased on
>>> L3/L4 information.
>>>
>>> - Windows: I believe you mentioned that Windows 7 doesn't = seem to have
>>> support for setting flow labels.
>>
>> I couldn't find anything. Presumably it can be done by apps th= rough the
>> Winsock API, but that isn't very useful.
>>
>>> Maybe someone from Microsoft can
>>> clarify this and let us know what the prospects are for gettin= g flow
>>> label support.
>>
>> Please.
>>=C2=A0 =C2=A0 Brian
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >>
>
--94eb2c0762e64d4a49052e115998-- From nobody Tue Mar 15 01:12:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DAD12D94F for ; Tue, 15 Mar 2016 01:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOH_X6LSSIfZ for ; Tue, 15 Mar 2016 01:12:55 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1D912D6A5 for ; Tue, 15 Mar 2016 01:12:55 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D6BF0D7884; Tue, 15 Mar 2016 01:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=B6XybI3f3qRon7Cu2rU2KafSAoU=; b= PWrH8SXcE91Iq4IljDbn3YyFB/VosFYMORXtb2nP2rFaNL4aAIUea5ZOaO1VuZMx JwO2o0QKCAZ/Muvr2ZnQPkejloyZMH00XAv+aLjswuhGqQP500XjuLoAbCyXKjBi 1ns26rN/3NIFphiXTShTqm4bt3boEG9mST3IxhkY/TU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=Z3CrcbW3KE36Fnm9oBW2ohEoc5 hC68SvUZiraqZbBx3GngSC+J69ssCDZtXSlC7ST/Z3SfrQCNWYZSw7TKKtfWf1UG flHIdTVvXxDNeAS671PG/8RvO/5MYp+e6LEZJ14KiwU1Fr339/T670+vVP9nG5Zl 0GsHPp5Spcoum3EXA= Received: from h.hanazo.no (unknown [173.38.220.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 9A024D7882; Tue, 15 Mar 2016 01:12:54 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 85BA81299DB3; Tue, 15 Mar 2016 09:12:58 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BFBC0ACA-D26A-4335-B911-19DC420EC705"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E7B3C2.6070507@pluribusnetworks.com> Date: Tue, 15 Mar 2016 09:12:57 +0100 Message-Id: <101419E1-B227-4D3E-BDBD-707E9C5B6CDA@employees.org> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> <56E7B3C2.6070507@pluribusnetworks.com> To: Sonum Mathur X-Mailer: Apple Mail (2.3112) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 08:12:57 -0000 --Apple-Mail=_BFBC0ACA-D26A-4335-B911-19DC420EC705 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sonum, if it is a bug in Linux, then get that fixed. Ole > On 15 Mar 2016, at 08:03, Sonum Mathur = wrote: >=20 > Ole, > Thanks for the response. > RFC 4541 says SrcIP should be 'all-zeros'. But it is observed that = Linux just drops the Query if SrcIP is not a Link-local Address. Solaris = seems to accept anything - not sure about Windows or other stacks. >=20 > Not just for hosts, for snooping switches to inter operate, they need = to identify each other. Otherwise we create a dis-connect between the = snooping switches. This is when there is no Router on the subnet. If = there is no standard IP Address, then this becomes a problem. Can't use = 'all-zeros' for MLD as Linux accepts non-zero link-local address. >=20 > Regards > -- > Sonum >=20 > On 3/12/16 9:23 AM, otroan@employees.org wrote: >>> If there are no Routers involved, it is Snooping switch = responsibility to send MLD Query to keep the groups alive on the switch. >>> >What is the correct correct Source IP to use for General Queries ? = Is it Src IP all 0 or some link-local Address ? Which host stack would = like/accept what Source IP ? Have observed different observations with = different host stacks. >> see rfc4541. >>=20 --Apple-Mail=_BFBC0ACA-D26A-4335-B911-19DC420EC705 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW58QKAAoJEL7aWKiYQt92resQAIVyn+rdrJwkYOom6cwpHQCZ gXv2y74rjQe+MEkXie6q0zk9RPks6MQNHAq8Vq8KKfdQtaqvoLQMUybUr+FluQal Hknv1b5SHlL8wqCojOY9xJFXHmCKOEswVCp0GPVQCvxDc2IGkqtDgkPNU9Yq1mWY q744iUR9mefyxGm6mQLXNEc+30vRvjMZkxKUD5UChx8z3IyL+daRvBgON3/ntUvS mVRb7Pakq60faeBB2F7N9b90bmm7Wi7Wu/U660SHDWr66nCzo2RfmFkQ87dzRwe9 HvMhs0urmeoFoda26aH83/Wa3MRBet8CvIRox3SJLxHkNBtbmApDv7VeJsJ9fLOK gxQIvJyBuTRY+QvyFC+ueTKN9Q98Q5nFX7p5HvUfIwVW498aS9juwnage3rn35xV wKihCcLVVAthGa6IoGfO8Jutjyt+sPCKfwBZ8utCyHtsOIrHQZKJ9TbX7a2Hdcw/ yzaJDVq31MRLQAyQ4KCnsU0svLRRelou353FJkJkwsJA+JOp+TUkVNaLBG0R67S3 DEdGIthVIK1RCoZDAEsySQGaBLsnJ1hfdr5k2x9Ep11CGTv751egWJIQgbw4lE92 CLyhyWa0jpdoY28diaGdlWSOTjkUwTXKKZHzfSE0Jk8sLyUYVRCcipN7vL+wBe64 MYEd6WjV454k99M0RP9O =KbCT -----END PGP SIGNATURE----- --Apple-Mail=_BFBC0ACA-D26A-4335-B911-19DC420EC705-- From nobody Tue Mar 15 03:12:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A2212D51A for ; Tue, 15 Mar 2016 03:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLU606ZQsCMT for ; Tue, 15 Mar 2016 03:12:15 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C3612D512 for ; Tue, 15 Mar 2016 03:12:15 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 96D17D7884; Tue, 15 Mar 2016 03:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=uWDmdRKxVGx0u0iPZ9sj0ee2vlY=; b= n+5OtIMwyBNTgbtWKEEht39iS/cvaZwfCJH/QVEiraYHfQ5c5JPa7CbCs1ZNbu/H SeM1okTfA+MagCyHlyNXeoeQ0eUZPgpXVnJ66n7TZoT/P51lE2GWkBsn3XTz1s1T 3jGqAcyu2+oJvsXqiXj2WhqjDSU/Ij1JCc8ECKYYHhI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=cMKmGyDmB1b7Yrig8zLTvVYEIB AW833RKh6rocaoAqg+9T5VaaH0MSEmV07qjEZmOmnjGPD1jUkw6xuhlzE/6g5aAT /lhp0az+tGTQTtHNTpf+HlmUHr1xzXFUx13AQOwPO+eSGMa0OWP6Ws0JHNZQb9eM tpTWhTY8H+KJZF2po= Received: from h.hanazo.no (unknown [173.38.220.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 28D2AD7881; Tue, 15 Mar 2016 03:12:14 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E2612129CB29; Tue, 15 Mar 2016 11:12:11 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C7BC44FC-BD99-468F-B511-C5C90FF3FAAA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Tue, 15 Mar 2016 11:12:10 +0100 Message-Id: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 10:12:17 -0000 --Apple-Mail=_C7BC44FC-BD99-468F-B511-C5C90FF3FAAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Warren, [...] > Yup. Ubiquitous flow labels will solve *one* of the issues with long = header chains, but in the remaining cases (my personal bugbear is = filtering (for dos and ingress / edge filters)) the hardware still need = to be capable of doing it (at line-rate). I never understood from the draft what the other use cases were, but = those are the ones? ingress/edge filters and DOS attacks? from the perspective of a software forwarding path. parsing the extension header chain is _always_ going to be slower than = not doing it. that in itself can be considered opening your = implementation up to DOS attacks, but oh well. can ingress / edge filters be done in two stages? core routers only = filter on SA/DA while whatever infrastructure function you need to reach = apply deeper filters? for DOS attacks, are those filters put in place dynamically? what does a = typical attack look like? can you identify it without having to parse = EHs? how often are you not able to identify it even when looking deep? = any papers/reports on this? Best regards, Ole PS: In BA we're trying to do a project on VPP for the IETF hackathon, if = anyone is interested in implementing EH filtering / parsing and measure = the performance impact on that, it would be very welcome. (VPP is a open = source high performance software data plane running on commodity = hardware.) --Apple-Mail=_C7BC44FC-BD99-468F-B511-C5C90FF3FAAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW59/7AAoJEL7aWKiYQt925KUP/3ZPNkZa2neoePWKHplMzeS/ 1TbWKLx3jVtn4w738AHFm5PsW6YchUmDiagtKkPluywfKzEwB7cY3maZDBBYAe3s ijVto2oM9iRCgLeZgyuZyFmMP3aJnmWIpFs4pBPsHlAk486x47PvQoluvTaDJGvr kdt5MDWIsTe3WFl7JfmrnxdK4aTLGmiFx8gMqAVuU2P+26FeOVgcSuXZ+QjuUyUJ WlR1YkOf//CPcNpf111r7vOmfvKY/waag5ICMdtw9Bd+k6q2bvc+4ybhqqNkuh0Y LQKp554iCwk11TN2lrTkNMd/f0aTjdp6EOV0LsOZEzRZzc0WqP1/2VTeHlkyFmva wQ9c7BxHieRhWSZTUq5RMctisrMgV/tTMBRUlc6xjpTDdLD55DLTiXb2t/Pd/MEa PTS8ql8nee5uoUxhcHGv/s891GhcHTcky+l41Nv7ChbLQZGG7MpiLI1lFZMQLVth SogRO7cjw6AgQ/iOCNYUESDvotiTmVmpjPuFrl2zcB6zGR1nawIjKT6Ek/OlKj+G kJ9PEwvAQ26a3V4iK2PcwJKUCKj9ASaQaVTqOjMdAZO53w0yiqL/6r5l8W90OLTM bM3CVvwOFpv6ldbIlCyY/fwt0K7zs8kvozdRp1OdSnQ5et0l9yHp1IjIsW+9or2N NU+KTp5jQ19Aquf3e+Zx =3TMT -----END PGP SIGNATURE----- --Apple-Mail=_C7BC44FC-BD99-468F-B511-C5C90FF3FAAA-- From nobody Tue Mar 15 11:12:30 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D1012DD0C; Tue, 15 Mar 2016 11:12:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315181226.10954.95724.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 11:12:26 -0700 Archived-At: Cc: v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Subject: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 18:12:27 -0000 Benoit Claise has entered the following ballot position for draft-ietf-v6ops-ipv6-ehs-in-real-world-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While reading the document, I was wondering under which circumstances dropping IPv6 Extension Headers is the right behavior? Or, if dropping IPv6 Extension Headers is always just wrong? The only related sentences I found are: The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 Extension Headers, so that the situation improves over time. ... In any case, we note that it is impossible to tell whether, in those cases where IPv6 packets with extension headers get dropped, the packet drops are the result of an explicit and intended policy, or the result of improper device configuration defaults, buggy devices, etc. What does it mean "so that the situation improves overtime"? A disclaimer that this study is formulated in a neutral way, as a precursor document for some further advice + a pointer to https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-00 would be a plus IMO. From nobody Tue Mar 15 15:55:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270812D69F for ; Tue, 15 Mar 2016 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHDKU3jDgFSP for ; Tue, 15 Mar 2016 15:55:00 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CACE012D7A3 for ; Tue, 15 Mar 2016 15:54:59 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2FMsnBL032392 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2016 22:54:51 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org Message-ID: <56E892B8.9030902@foobar.org> Date: Tue, 15 Mar 2016 22:54:48 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: otroan@employees.org References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> In-Reply-To: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 22:55:02 -0000 otroan@employees.org wrote: > from the perspective of a software forwarding path. parsing the > extension header chain is _always_ going to be slower than not doing > it. that in itself can be considered opening your implementation up > to DOS attacks, but oh well. assuming that you're talking about routers with separate management and forwarding planes, and that you're referring to packets being punted from the regular forwarding plane to the management plane when they are difficult to handle (e.g. large EH chains), you can assume that on current large routers, this is as good as dropping the packet because the disparity between the capacity of the forwarding plane and the management plane is too large to be useful. No-one in their right mind will let the management plane of a high end router chew up management CPU by forwarding punted packets. It's pointless. > can ingress / edge filters be done in two stages? core routers only > filter on SA/DA while whatever infrastructure function you need to > reach apply deeper filters? Basically, no. What might look to be legitimate traffic on core ingress might only become visible as a ddos attack on the egress to the edge. That's assuming that there is a clear-cut edge and core which there often isn't. > for DOS attacks, are those filters put in place dynamically? yes - e.g. via flowspec. > what does a typical attack look like? they vary extremely widely; the smarter attacks will measure the effect on the recipient site and vary the ddos traffic according to what appears to work the best. I.e. if one style of traffic appears not to be having an impact, the traffic profile might change to something else to see if that causes more trouble. > can you identify it without having to parse EHs? If someone attacks with ipv6 and there is a long enough EH chain to cause the normal forwarding plane of a router to be unable to look far enough into the packet to determine the L4 info, then the only real option is to drop or rate limit (which is nearly equivalent to dropping in the case of a ddos). There is insufficient parsing granularity on any current equipment to be able to do much else. > how often are you not able to identify it even when looking deep? > any papers/reports on this? No papers that I'm aware of. Nick From nobody Wed Mar 16 03:50:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319EC12D7B5 for ; Wed, 16 Mar 2016 03:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGlHlfHjINyu for ; Wed, 16 Mar 2016 03:50:20 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D2612D522 for ; Wed, 16 Mar 2016 03:50:20 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 954B8D788E; Wed, 16 Mar 2016 03:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=sC47Y5lnFuS/7QE8CAydANGzQNQ=; b= Hnrh0qYe1mWwyEp0H/DB4gbtCJ5bfkc+nz/f95WqcHW3c+LfFFL95jELz4E4L6/8 YbGa4NZsj4tLCfNdspLVgJuXrsrNCFQ0ajdsS1MGxOxFhGMfxA/lsHHYK/BX/vVB hUTkqLJqcaG6p9dF+h9glZj/0ais6LAsbdaLfwWBoIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=py1iKe7IaGx3YZQk+LUxHdI7aV 26g6w9gscftxPPgHR3AMcO5RLd5VuN0IJkJTzwdY2M9XEWUZtdIG2JsnZ5o3qQiG I6ZYiWvL6rC1rKYdD4C01+EsTHdz5tmraALsfWYiaNs3OqEcVCwnjrQvUPMDASjN lGJh+4KFIgF8gT9qM= Received: from h.hanazo.no (unknown [173.38.220.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 2BA38D7884; Wed, 16 Mar 2016 03:50:18 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CF9B512A8D68; Wed, 16 Mar 2016 11:50:15 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_ACDED3EB-950D-42FF-8BB8-F227F030FB01"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E892B8.9030902@foobar.org> Date: Wed, 16 Mar 2016 11:50:14 +0100 Message-Id: <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 10:50:22 -0000 --Apple-Mail=_ACDED3EB-950D-42FF-8BB8-F227F030FB01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Nick, > otroan@employees.org wrote: >> from the perspective of a software forwarding path. parsing the >> extension header chain is _always_ going to be slower than not doing >> it. that in itself can be considered opening your implementation up >> to DOS attacks, but oh well. >=20 > assuming that you're talking about routers with separate management = and > forwarding planes, and that you're referring to packets being punted > from the regular forwarding plane to the management plane when they = are > difficult to handle (e.g. large EH chains), you can assume that on > current large routers, this is as good as dropping the packet because > the disparity between the capacity of the forwarding plane and the > management plane is too large to be useful. No-one in their right mind > will let the management plane of a high end router chew up management > CPU by forwarding punted packets. It's pointless. no, I'm talking about behaviour just in the data plane (in my case one = that runs entirely in software). if the requirement is to look into the L4 header, then there will be a = performance penalty for processing packets with extension headers. = looking deeper into packets =3D=3D more memory accesses. long EHs could be used as a DOS attack against the router. simple solution is to not look into the L4 obviously. >> can ingress / edge filters be done in two stages? core routers only >> filter on SA/DA while whatever infrastructure function you need to >> reach apply deeper filters? >=20 > Basically, no. What might look to be legitimate traffic on core = ingress > might only become visible as a ddos attack on the egress to the edge. > That's assuming that there is a clear-cut edge and core which there > often isn't. >=20 >> for DOS attacks, are those filters put in place dynamically? >=20 > yes - e.g. via flowspec. >=20 >> what does a typical attack look like? >=20 > they vary extremely widely; the smarter attacks will measure the = effect > on the recipient site and vary the ddos traffic according to what > appears to work the best. I.e. if one style of traffic appears not to > be having an impact, the traffic profile might change to something = else > to see if that causes more trouble. >=20 >> can you identify it without having to parse EHs? >=20 > If someone attacks with ipv6 and there is a long enough EH chain to > cause the normal forwarding plane of a router to be unable to look far > enough into the packet to determine the L4 info, then the only real > option is to drop or rate limit (which is nearly equivalent to = dropping > in the case of a ddos). There is insufficient parsing granularity on = any > current equipment to be able to do much else. why wouldn't the ddos flowspec description include the EHs in that case = and not depend on only the L4 information. can we conclude that we don't know enough about ddos attacks to = determine how they can be filtered? cheers, Ole --Apple-Mail=_ACDED3EB-950D-42FF-8BB8-F227F030FB01 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW6TpnAAoJEL7aWKiYQt92uogP/02ICi9bLwHztDPgUeVRMj9L 0NjXhjy2Im/iW0joRdwt43MszWWCLGRxjyf6j0bymXWLvHAP6LfATvtE5BcU23Jx mVuypM9csfWiXyWiVEF7eHmDk9e+6LNAiizM1I4BTZQ0CgUe0sioQeSLbyYRbnTK FClwMDiZcxPdo5KGsEm2xwf3SmKah1DeNVqRWbs7Z6D+ggLAldZRZPhIClOa9HrL pPdYR/DlZyr5Zv5ggmhxviFaNhvhr4hebZhxicA3tpJQq9hGkp5OYpiyoV18kq0T jgj4swLynajXMELQ5EYXCESulXzL/u25Oa+jFiujYZbNdU23H9MC8YEae3E6HuMr /bz++i1RQ+MlLtj8kfyDtdYN7/Fyn4d0nLUUxczVj0p6ndvmJU8ioOwz2gct6i5a G+YP1EhzhVrMmqJQoK7Oivj0yZi5kcr905+476KwLY9OEsf9TGvVcG8cbE3MhJhz HJ04A8sqN2UM0oPCJsJbkdWANo4DO7Q/ZNX/xvO5Fb7DC889U9PTgU7RIdkTmLJS SUSNr+cipQfxfEDTa60Qev68u9hjQmMKzLuVXuEP1/TATh5C9rJRPywQYUp1rzrT nQRSJFxFWR1OKMP6c7BXDXMTsx1a0mfaxhaOt+C3UMYS6WnOlrjY1Hp9zWwGnEQF KwiOkQSJ1ICjBdCJv3XG =+cnG -----END PGP SIGNATURE----- --Apple-Mail=_ACDED3EB-950D-42FF-8BB8-F227F030FB01-- From nobody Wed Mar 16 04:25:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25F112D75A for ; Wed, 16 Mar 2016 04:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng7sh8wiKTkk for ; Wed, 16 Mar 2016 04:24:49 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF1612D540 for ; Wed, 16 Mar 2016 04:24:46 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2GBOcCH058433 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2016 11:24:39 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <56E94275.20700@foobar.org> Date: Wed, 16 Mar 2016 11:24:37 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: otroan@employees.org References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> In-Reply-To: <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 11:25:01 -0000 otroan@employees.org wrote: > no, I'm talking about behaviour just in the data plane (in my case > one that runs entirely in software). > if the requirement is to look into the L4 header, then there will be > a performance penalty for processing packets with extension headers. > looking deeper into packets == more memory accesses. > long EHs could be used as a DOS attack against the router. It's not viable to run high end networks on general purpose CPUs using software forwarding. At the very least, you need NPUs if not custom hardware (asics, "merchant silicon", etc). > simple solution is to not look into the L4 obviously. That isn't a viable workaround. Losing visibility of L4 information is catastrophic from the point of view of ddos management. > why wouldn't the ddos flowspec description include the EHs in that > case and not depend on only the L4 information. Because if you have full control of a compromised device, you can create random EH chains on an ipv6 packet? > can we conclude that we don't know enough about ddos attacks to > determine how they can be filtered? Not sure what you mean here. People initiating DDoS attacks will do anything if they think it will cause damage to the recipient host. Does that answer your question? Nick From nobody Wed Mar 16 04:45:51 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D22C12D541; Wed, 16 Mar 2016 04:45:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316114549.25578.30969.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 04:45:49 -0700 Archived-At: Cc: v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Subject: [v6ops] Brian Haberman's Abstain on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 11:45:49 -0000 Brian Haberman has entered the following ballot position for draft-ietf-v6ops-ipv6-ehs-in-real-world-02: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alvaro that this document is valuable as far as providing data that serves as input to other work, but does not by itself warrant publication as an RFC. From nobody Wed Mar 16 07:00:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E0B12D572 for ; Wed, 16 Mar 2016 07:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj0znKPEoJIz for ; Wed, 16 Mar 2016 07:00:38 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8D512D50A for ; Wed, 16 Mar 2016 07:00:38 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 34485D7881; Wed, 16 Mar 2016 07:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=hxf7Me0q2Wq/3DI60L5ks+qUQgs=; b= mpqnNuL2uv2NPkcFr2HX194Pxd3PzNhQ2M4/H3YgpRyZNiSr/mgOVWZOWNPYQG7C ixjFl5wu0BGkJgTCymOL4IGrbuIQjl73tcs/Qj5/7EVHsocORNdRrdmqobY9j/pR SnHmwT32OQKRgDmuMgO5aLpueSyR0AgPdY+q/V2Xq54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=nIPpe/7bus4ofHEr/a+uevHNwh nFpkO5pz0ePVetSR+Fm6fCG1wNi/gLA41vAYBTbeTmRRQQA69Spz8/OqSiLGRZB6 km0gM/gv4EMzmJvVWWDcW2+z0w1gHjEjjqgQLKIsvllmWZDqSbspBlx6TyNV2Pjz FM3CV4moDF/IBIjMM= Received: from h.hanazo.no (unknown [173.38.220.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id CA431D789F; Wed, 16 Mar 2016 07:00:35 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A510512AC811; Wed, 16 Mar 2016 15:00:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_240FE8F0-F6D9-439B-8E93-BAE8F877A40F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E94275.20700@foobar.org> Date: Wed, 16 Mar 2016 15:00:32 +0100 Message-Id: <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 14:00:40 -0000 --Apple-Mail=_240FE8F0-F6D9-439B-8E93-BAE8F877A40F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nick, >> no, I'm talking about behaviour just in the data plane (in my case >> one that runs entirely in software). >> if the requirement is to look into the L4 header, then there will be >> a performance penalty for processing packets with extension headers. >> looking deeper into packets =3D=3D more memory accesses. >> long EHs could be used as a DOS attack against the router. >=20 > It's not viable to run high end networks on general purpose CPUs using > software forwarding. At the very least, you need NPUs if not custom > hardware (asics, "merchant silicon", etc). that was pretty fundamentalistic. as always it depends. if you're happy with a few 100Gs then you can do = it on current commodity hardware. >> simple solution is to not look into the L4 obviously. >=20 > That isn't a viable workaround. Losing visibility of L4 information = is > catastrophic from the point of view of ddos management. I hear you are saying that, but it is difficult to know if that's = correct or not without having access to data. how did the ddos attack look like, then figure out what the possible = mitigations are. >> why wouldn't the ddos flowspec description include the EHs in that >> case and not depend on only the L4 information. >=20 > Because if you have full control of a compromised device, you can = create > random EH chains on an ipv6 packet? >=20 >> can we conclude that we don't know enough about ddos attacks to >> determine how they can be filtered? >=20 > Not sure what you mean here. People initiating DDoS attacks will do > anything if they think it will cause damage to the recipient host. = Does > that answer your question? sure, I'm just saying that if the ddos mitigation requires lots of = processing it will also cause damage to routers. cheers, Ole --Apple-Mail=_240FE8F0-F6D9-439B-8E93-BAE8F877A40F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW6WcBAAoJEL7aWKiYQt92s20P/jUEiOg7br0/qUl0F65KWzAE fqccQlZ+uTCh8cotGBabqj86UrK4A/pp4qz1FbF6OZf5Cm3jWh3eKRm+i1xjYKx8 gr6L57SaV5zTPSa8xZFxaIyvK8zeMGQfd3OEAu0Ot0jwPGCX+DYDU5ZVdcPuXC// ngcWWups5CGTBG8cmUg/6f0kvpA+aS2PvVSx1nKAiooTfc4O57bNx0DdpQMDec8I t5pzgJOM28KzVmQXJhwO0NydHVpTfoM1Xuc08cJQuETj4bo8SzJQ70A8HCsX0RIt 1J1BhKoFvNLsVvR6b3W1kZZD/QO3sx+hTuFqPSJZABe1B6FhwipNsRZotU1WZesW uuCA/5BWtrG6C3JlLXnS9M3iSn580ljtQdWZwt7GxOsq3T/nH0RGhEmb4tk5vY9A CaQ+RJcdceYZKcgwr293s8GpMUey0w46BQWgWtPAEApWejN+/BopSnPx+G0rp/de 6XgEJZvI/CyfP+POmE/LRQrsV8mMJrukN7KPUYwuf3UjRWAKI4FBmJPGHyff98ge pzPcLaUIWkvrnD4HIVXha9XloBIiuA0fOqCNpMj/OWfSZfAOpbwk9nsSkjKO06eI XOwzfby/KtuR1xGhFCxi1+KqtlicOzTYyXksFq3lPXEsWAcdXglO7PDn+s/gSw5j gBGD+FRo4jle4ko9+j8X =5BOE -----END PGP SIGNATURE----- --Apple-Mail=_240FE8F0-F6D9-439B-8E93-BAE8F877A40F-- From nobody Wed Mar 16 07:36:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3757912D6EB for ; Wed, 16 Mar 2016 07:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_JNS5gsn73L for ; Wed, 16 Mar 2016 07:36:45 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B49112D5CA for ; Wed, 16 Mar 2016 07:36:45 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2GEabRa063923 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2016 14:36:38 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <56E96F74.7000206@foobar.org> Date: Wed, 16 Mar 2016 14:36:36 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: otroan@employees.org References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> In-Reply-To: <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 14:36:48 -0000 otroan@employees.org wrote: > that was pretty fundamentalistic. as always it depends. if you're > happy with a few 100Gs then you can do it on current commodity > hardware. which in turn depends completely on what features are enabled. in/out packet forwarding is simple and can be done fast on commodity hardware with software forwarding. When you turn on the sort of features that you need on production networks (netflow, qos, filtering, etc) forwarding throughput drops dramatically. >> That isn't a viable workaround. Losing visibility of L4 information >> is catastrophic from the point of view of ddos management. > > I hear you are saying that, but it is difficult to know if that's > correct or not without having access to data. Is it not obvious that if you're trying to selectively filter traffic to a specific destination, that you need to be able to access L4 info? Maybe take a look at some of the ddos presos at netops meetings (nanog / ripe / apricot, etc)? Do you need something more formal? Nick From nobody Wed Mar 16 08:48:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305AE12D65D for ; Wed, 16 Mar 2016 08:48:42 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPKNa6jP4i6l for ; Wed, 16 Mar 2016 08:48:40 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A113B12D6F5 for ; Wed, 16 Mar 2016 08:48:40 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id vf5so120242683igb.0 for ; Wed, 16 Mar 2016 08:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KU34kNlPJWXQUC/jJxyVjmRL+P96evovFRr36Um88Cg=; b=pUZONeEoUkAjOdtTyWFiyQSWIO0tnN09mIBXeYG1qxoxuhRYomgDlbGArEVkrt8trn rqIMqPjiCa4tBTk1iRqggeJ4gJB5pnW4b8V1knaUvKfiC7OC9UTdX5UvfooBzp7JVwO/ HC9EoQ7jgmLYIF1wnJj8LfHsNMPF1FQZrBeILEzpwyd2CSolkFk74qbOvCJBuduOmu7T ZCK/3bu2CBq10xIeZolD+TgnDUCMM7yyLkUNq4VJ2ntY2oF78LlAecEILjdVaaMEX3HM 0viF5aM5r87KWFilrF86gK6KtLzSp5MdaT/c2ZyGhKyZbDz2u7S+nfwKn8kx0asTva55 pJrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KU34kNlPJWXQUC/jJxyVjmRL+P96evovFRr36Um88Cg=; b=INGjJ/lD/A0FgZ8e10rR9cGsjjr79nEapcV6rOWUJDZ5zRADGJyCjPgLIdMe00ijZj S9pSi1hxDwLZtPd/tMhPVnW3dOW7KypVeYnJi/Ojvku8F+PyvAyasbx30POMVHzZxMXS qbQBQH8m5Z4K1cw8Rl+gSuOktx381fbyBbzBDpdw8WzvPAAbgh82bcd1IKQ1IxucRxxt kghuXy9j6i8nneV2kBLXWM7j9Urxjmtmq+5DOOWR3sHceDTjkdVdHv3Bbfv9fwMCNDBo Js0YlVF8I6kv1bCBIg1sf/dCcGZTHCVnYoT2Th2WZR9yur9EBXe+KCUhzn7/u4i4lmYC qtug== X-Gm-Message-State: AD7BkJJctPqjDf6ZiVKJz8hgAbWFeQPU4gyV514y+hqDWSsk7UUMaPMFibDNORlh2Fh9RftfmYTjgAie913tUA== MIME-Version: 1.0 X-Received: by 10.50.141.164 with SMTP id rp4mr2090546igb.89.1458143319886; Wed, 16 Mar 2016 08:48:39 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Wed, 16 Mar 2016 08:48:39 -0700 (PDT) In-Reply-To: <56E96F74.7000206@foobar.org> References: <56E318C7.5020200@gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> Date: Wed, 16 Mar 2016 08:48:39 -0700 Message-ID: From: Tom Herbert To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:48:42 -0000 On Wed, Mar 16, 2016 at 7:36 AM, Nick Hilliard wrote: > otroan@employees.org wrote: >> that was pretty fundamentalistic. as always it depends. if you're >> happy with a few 100Gs then you can do it on current commodity >> hardware. > > which in turn depends completely on what features are enabled. in/out > packet forwarding is simple and can be done fast on commodity hardware > with software forwarding. When you turn on the sort of features that > you need on production networks (netflow, qos, filtering, etc) > forwarding throughput drops dramatically. > But if we turn on the "wrong" features like the aforementioned EH's, IP options, checksum in UDP encapsulation, or use some protocol that a hardware device isn't designed for-- we can just as easily cause packet forwarding throughout to drop in HW devices. For basic packet forwarding (e.g. fabric switches) we'll still happily use hardware, but flow based ECMP must be supported in these which is why the flow label support in HW is critical. For more advanced filtering, load balancing, ddos mitigation we (large data center operators at least) are trending toward software solutions on commodity HW. Even if there is some performance difference with an equivalent HW solution in terms of features, extensibility and lower cost are driving factors. In any case, on the Internet I don't think the differences between HW and SW solutions are germane. We are bound to the least common denominator which advances much more slowly than production networks. Processing an unbounded chain of EHs is probably a problem for anyone at this point. Tom From nobody Wed Mar 16 08:50:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2B12D86F for ; Wed, 16 Mar 2016 08:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qshYGTp8TH-a for ; Wed, 16 Mar 2016 08:50:00 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA46312D887 for ; Wed, 16 Mar 2016 08:49:34 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2GFnRnI066032 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2016 15:49:28 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <56E98086.5040209@foobar.org> Date: Wed, 16 Mar 2016 15:49:26 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tom Herbert References: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:50:02 -0000 Tom Herbert wrote: > Processing an unbounded chain of EHs is probably a problem for anyone > at this point. exactly, which is what this draft is attempting to document. Nick From nobody Wed Mar 16 09:25:40 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6092112D9C3 for ; Wed, 16 Mar 2016 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfehUQxM896R for ; Wed, 16 Mar 2016 09:25:37 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075DF12D9BE for ; Wed, 16 Mar 2016 09:25:36 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id ig19so48671502igb.1 for ; Wed, 16 Mar 2016 09:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cRxQnQ6YzQngP1l/cqK2p5kSw/v1pe5MNmx2JM99bPQ=; b=0No4vxpWED+nazqf2KXy2DFfVLJ2xuo2GK2m7sKFodacM4kDbM/hXbNrjeneI4ead7 ZoAvnlBkPyBHVXvjOrqgvyXDjdTBheuxnFSeQuqwj2Jz8+s1RtM2m8egJJ7mY7VNVSuW J6axlSmwcXZi+3LuNCAvdcJ2MFMV4J/cZnKil5oxGqgTcYPf83uB+fhFThmhDaRjKaQa A4Kd3WRksHrc5mVlWJ8hM+wX8EJanFOKxQypALckdKVqp1Ce6MwKUnVwtVH3Ei5hcdLn Mvqf4DiHw0wEgcgIXZs+GRSSKkNt1VcH/LnR+An4TCvtrjw7bauM0nAdc/knU8ZMViwl ahVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cRxQnQ6YzQngP1l/cqK2p5kSw/v1pe5MNmx2JM99bPQ=; b=km4WZBX44ekJoEIJSzKiY+gRaD52km38nTI0PHC5zm/2okUIcM2IoRK5BBi23YG1k+ 18pMjOFnvgE/CmySzVu/KATGez4/ZKQyBBz5tdXwhFD1GvaRLyIDvMmJ3hZoAnr2l6sd w/nd0NLL6by0+H3XPdGt8oNiHpPMw6TOINoj1HhMKCAj72gxssgLR7HRwsVZ/T0GpyKE 1O7MBnhOa7R4Z1wtKEyGhgT0POsHWAoKR2FxEOQXfDY5e61231Eam3ZmMuXHy/eFS663 MtE4vDyNlC3dIGkYBXVLUc646cKflbrCLHrTZJBbvy7YUJ1nAryvbU/kIO0DtkEOGigy 6AMw== X-Gm-Message-State: AD7BkJIZgheUU8+REsL0OBZCmACsalUTs1rkYOkH7KFW7jImBl4jIOtKXhgMQmk5dKD3st2yEv3Z/+TRcZ4l9A== MIME-Version: 1.0 X-Received: by 10.50.23.43 with SMTP id j11mr18820769igf.94.1458145536080; Wed, 16 Mar 2016 09:25:36 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Wed, 16 Mar 2016 09:25:35 -0700 (PDT) In-Reply-To: <56E98086.5040209@foobar.org> References: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> Date: Wed, 16 Mar 2016 09:25:35 -0700 Message-ID: From: Tom Herbert To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:25:38 -0000 On Wed, Mar 16, 2016 at 8:49 AM, Nick Hilliard wrote: > Tom Herbert wrote: >> Processing an unbounded chain of EHs is probably a problem for anyone >> at this point. > > exactly, which is what this draft is attempting to document. > Nick, what is not clear to me from the draft is what purpose that devices would have in parsing EH. Different purposes may imply different mitigations to the parsing problem. I see at least four possibilities: 1) To extract L4 entropy for ECMP. As discussed flow label eliminates the need to parse in this case. 2) To perform L4 inspection for DDOS, stateful firewalls. The EH that provides the header chain length seems potentially useful in this case. 3) Handle/not handle HBH 4) Inspect other EHs for filtering. Others? Do you have any sense as to which of these would applicable/required in the Internet? Thanks, Tom > Nick > From nobody Wed Mar 16 10:38:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5292412D652 for ; Wed, 16 Mar 2016 10:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGdY4LjazqDR for ; Wed, 16 Mar 2016 10:38:42 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF4412DA68 for ; Wed, 16 Mar 2016 10:38:15 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 7CD66D7881; Wed, 16 Mar 2016 10:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=58bLtVUt40cQX8wgm3f85XGCi2o=; b= ra4rYQ2Wr0w5A5YMvpb5lHIonySNiKo3e9VAy3k0P02Fr9vHapoYP8fHPX1zGz/o xxxMxVBswfL+QVHInYLzM/Bjn4iWgPwI0AvKjsHoT9f5pFKCZMdClxEPiynmmPFH /f+gN6e6qiDwMp2QEJBc3jRINYScp1A8O1gkOcoMDGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=TMBapPA6/HudlLBf3FKpEbAfg/ SdOw184/GvycNIOd7Ys3KytMgbb0Hqm4hy2HObkgM2ylLbMjhgVcaTRFWAzUacwS FPi+iky5O8Ky0hEz7DOLgDsv7mMIIvDTGxpd0HxosqFhSBJaZrGPt2ZZNqAT77T0 2/59MK8fxJzRNVVfo= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 41CDFD7884; Wed, 16 Mar 2016 10:38:14 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 49AE312AE2E5; Wed, 16 Mar 2016 18:38:13 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_797800AC-C1A3-4586-84FB-4E0DF9C63005"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E98086.5040209@foobar.org> Date: Wed, 16 Mar 2016 18:38:12 +0100 Message-Id: References: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:38:46 -0000 --Apple-Mail=_797800AC-C1A3-4586-84FB-4E0DF9C63005 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nick, >> Processing an unbounded chain of EHs is probably a problem for anyone >> at this point. >=20 > exactly, which is what this draft is attempting to document. making processing of extension headers hard was considered by Steve to = be a feature. that's well known. it just isn't clear to me what you are trying to = achieve with this draft? on one hand it alludes to why L4 information might be required in the = network, on the other it says why routers aren't able to process the EH = chain... Best regards, Ole --Apple-Mail=_797800AC-C1A3-4586-84FB-4E0DF9C63005 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW6ZoFAAoJEL7aWKiYQt92qiQP/0xOlbdGmyf3AKuz6qYsb9wI 9vErHIs8IG08rmX25vCiAIVzAMrwAUmm9PULbrHzR/uId9ryFJowexWrGHe9Qu23 p6XsCZLm9Mjr0U8kzans10vLDz/+4kA+ZBjxFKKNFaSJhJ6+osFvYuldbF4cErz0 ENRmmxCjQ572CkpIpG7FJsQD7PZzGOcBoKYRM2SeJSvyxOKOZWf9vlLGJlJm/l8m /O8eYJlRlWg7A7bxBYaUidhTvu42d4h+gbNVYSSHGXowou30Tg4jNSL691wf6zoM F4rJvBPYZFhJL0ZgEBF16aWRtHXD9ZhUdUFw8f7XI7qzVhw5QcRymknD6iljCOFn tzMlwbXx6G1mdbg0KRPM4n4bTZi9xz7k6jYSyRY8l7cDbN4yrpYdVHrQMFABrl1r IQiMKgtoBqyLU2UFk/zFFx8BgFW3vtpQlSd+b4yYIh55Xxs/Sh79nhQ5nLrBr/Ue IdSEAQunr0UCsB+wC+SbaFxuCow4vcLJ9SVWGjhaX5AgqQaZbmN71AuvmCLEUZk5 xN/XrcekzuQYPKVO/eP4Td/qgqBhoJGkG5qj2ka7bVmLJngoX15hO3cr12FBCdzW FF6y8qpc4nvihd9bkFztO73Q0JnUi1A1jm6WD8jIlLNGPtxBwkLldamk+zK1EONu BFkmeDPIXk+of8Tk7tq4 =4cSo -----END PGP SIGNATURE----- --Apple-Mail=_797800AC-C1A3-4586-84FB-4E0DF9C63005-- From nobody Wed Mar 16 11:10:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7612D616 for ; Wed, 16 Mar 2016 11:10:02 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjxiM1uXwXXb for ; Wed, 16 Mar 2016 11:10:00 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6E012D63E for ; Wed, 16 Mar 2016 11:10:00 -0700 (PDT) Received: from [10.20.12.111] (HSI-KBW-46-237-222-202.hsi.kabel-badenwuerttemberg.de [46.237.222.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7DA8780909; Wed, 16 Mar 2016 19:09:58 +0100 (CET) To: otroan@employees.org, Nick Hilliard References: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56E9A16B.4030605@si6networks.com> Date: Wed, 16 Mar 2016 15:09:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:10:02 -0000 Hi, Ole, On 03/16/2016 02:38 PM, otroan@employees.org wrote: > Nick, > >>> Processing an unbounded chain of EHs is probably a problem for anyone >>> at this point. >> >> exactly, which is what this draft is attempting to document. > > making processing of extension headers hard was considered by Steve to be a feature. So what? That "feature" makes them impossible to deploy. > that's well known. it just isn't clear to me what you are trying to achieve with this draft? > on one hand it alludes to why L4 information might be required in the network, on the other it says why routers aren't able to process the EH chain... We go back to square one all the time. Please let me summarize: 1) Packets with EHs are drpped because middleboxes and routers, in practice, need to obtain layer-4 information 2) Why do they need such layer-4 information? -- Because of the reasons stated in our I-D. Everytime this topic comes up, you argue that processing layer-4 information is not necessary, or ask why ops people do that. This document answers that question, so that this gets clarified, and we can move on to improve the current state of affairs. Otherwise, we live pretending that EHs are deployable, when they are not. Looking to the other side, or pretending that the problem doesn't exist doesn't help to solve problems. The goal of publishing this document is so that we don't have to rehash the same discussion every time the topic of EHs come up. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Mar 16 11:59:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4816212D59F for ; Wed, 16 Mar 2016 11:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzeAeSJJJbKk for ; Wed, 16 Mar 2016 11:59:35 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C89712D688 for ; Wed, 16 Mar 2016 11:59:34 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id x3so85578605pfb.1 for ; Wed, 16 Mar 2016 11:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OHH0yoKAu0rxuuuxGpvSOLDEHHwzlZ/GtG6w5MWX2Qw=; b=a8jekBtZBBPrXpkt0RN4SsFIMOJNOD1kINr13gtjPBjOD335T9ZTNP4isDMccerNR0 hPuAVkFJw5iBsxzoUkG3VYx5Zr+TMGl+4bgx6jUusJ/oumu3V/VOIsT0gyqoqDOsUXEV OOHW9f0UZMJWiOA07TRw/XvCCaMiu/Qe3tzXK9kEkxxChttmPnTobo2x0UL4QRl+uq+c GWZg/i1stCyrvVpP2m+Y88FFm9/+4vm4c4I+W2NGi+bInTyqA4fnLWMNmSKol4X/i6UD 4EHCM+CBi6lbtYyg2IhWI7sCc3ahesF9Rcqydoocs/7pyIJZBEKigxPKiwQsl8xk850Y SCEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OHH0yoKAu0rxuuuxGpvSOLDEHHwzlZ/GtG6w5MWX2Qw=; b=Taddac4Jl2+dWO7z2MK80VdUf1WYVZBYsacZOmTqCPPVuy39d6N/9nMz+p46qY0SSd WVq5pw4IKFDqjUpfDjMuLe2yTgZqOLVWljry8dJ4xak/ltwN4Tv3YZwN4PO4aCmsWS1T 1szG1xd3v1J4CkkWHaX5HRltT2MeJM/RzOW9cC2q8eszXpq4opAg/UNSN8gbArGfXbLZ oDJDxezc8OWqaro8pHBN3Hu6sprOwBYuPzNcWNkz+o8p4LzCwntsUfwddSaQ3p6nSsu0 7KTQKjD0Ihas5jHwBLCnnHZ00pMnbKEcPZCZ0XeCSTx5t0VfQKvEXQV7nWM/1lv+yoQf cqYA== X-Gm-Message-State: AD7BkJLt8QvPoD7kfxeDvG9dImBEymVZFXadC7Z1PV8O2UBIIL/6FbwywQXET0Cmco1fvg== X-Received: by 10.66.141.11 with SMTP id rk11mr8468009pab.75.1458154774028; Wed, 16 Mar 2016 11:59:34 -0700 (PDT) Received: from [10.1.9.199] ([103.23.18.15]) by smtp.gmail.com with ESMTPSA id i11sm7431671pfi.55.2016.03.16.11.59.31 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 11:59:32 -0700 (PDT) To: v6ops@ietf.org References: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56E9AD19.9060802@gmail.com> Date: Thu, 17 Mar 2016 07:59:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E9A16B.4030605@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:59:37 -0000 On 17/03/2016 07:09, Fernando Gont wrote: ... > The goal of publishing this document is so that we don't have to rehash > the same discussion every time the topic of EHs come up. Agreed. Brian From nobody Wed Mar 16 19:07:46 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2751812D815; Wed, 16 Mar 2016 19:07:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317020743.16747.83053.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 19:07:43 -0700 Archived-At: Cc: v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Subject: [v6ops] Barry Leiba's Abstain on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 02:07:43 -0000 Barry Leiba has entered the following ballot position for draft-ietf-v6ops-ipv6-ehs-in-real-world-02: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm going with Ãlvaro here: it would be better to merge this into whatever other document the working group is considering, and to have this as a draft or in the working group wiki in the meantime. From nobody Thu Mar 17 00:22:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BEF12D8B9 for ; Thu, 17 Mar 2016 00:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BBRkHPfikKP for ; Thu, 17 Mar 2016 00:22:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C73912D700 for ; Thu, 17 Mar 2016 00:22:42 -0700 (PDT) Received: from mb-2.local ([IPv6:2601:647:4204:51:b8be:6e31:fb1c:e230]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u2H7Me8P025202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Mar 2016 07:22:40 GMT (envelope-from joelja@bogus.com) To: Barry Leiba , The IESG References: <20160317020743.16747.83053.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: <4bae49ef-3e73-5119-7c06-4af481188c09@bogus.com> Date: Thu, 17 Mar 2016 00:22:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160317020743.16747.83053.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q9I50oKP0GUKS89uICNKji5guUERIDnSN" Archived-At: Cc: draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Subject: Re: [v6ops] Barry Leiba's Abstain on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 07:22:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q9I50oKP0GUKS89uICNKji5guUERIDnSN Content-Type: multipart/mixed; boundary="2bepxq0wFgV7KdAFtiPNj5xit7DVSDoQt" From: joel jaeggli To: Barry Leiba , The IESG Cc: v6ops-chairs@ietf.org, lee@asgard.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Message-ID: <4bae49ef-3e73-5119-7c06-4af481188c09@bogus.com> Subject: Re: Barry Leiba's Abstain on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) References: <20160317020743.16747.83053.idtracker@ietfa.amsl.com> In-Reply-To: <20160317020743.16747.83053.idtracker@ietfa.amsl.com> --2bepxq0wFgV7KdAFtiPNj5xit7DVSDoQt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/16/16 7:07 PM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-v6ops-ipv6-ehs-in-real-world-02: Abstain >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-worl= d/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'm going with =C3=81lvaro here: it would be better to merge this into > whatever other document the working group is considering, and to have > this as a draft or in the working group wiki in the meantime. the other draft is draft-gont-v6ops-ipv6-ehs-packet-drops-03 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ a think an actual consenus it likely to be hard won, but we're also no there yet frankly. wheras the observations are unambiguous even if the conclusions potentially are not. >=20 --2bepxq0wFgV7KdAFtiPNj5xit7DVSDoQt-- --Q9I50oKP0GUKS89uICNKji5guUERIDnSN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbqWzgACgkQ8AA1q7Z/VrLTNgCfXut8OjdWZl+V4yKASWuD0uSv ucEAn22zNeHU7xFMTBXA3XkYlMNtkRWf =8/cV -----END PGP SIGNATURE----- --Q9I50oKP0GUKS89uICNKji5guUERIDnSN-- From nobody Thu Mar 17 01:45:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F67B12D583 for ; Thu, 17 Mar 2016 01:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZK2WkXRrNJF for ; Thu, 17 Mar 2016 01:45:54 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5474D12D656 for ; Thu, 17 Mar 2016 01:45:53 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 52494D7888; Thu, 17 Mar 2016 01:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=0lHFIyB/Fe8UNeklo78BdPjsbZo=; b= pjPxDGPvuLryfcOwaS7v6vZ1HmbxhGDdzqCvjbwp0sYnYrWkcp7O4aclkaPKQS3m 1MHKPIsHeCtvAsAbb5oviBZLZirVPn+35iYodNYQkblYZAD7xQnOlhin6zn+Eg4s a4/j42F4A6RYKU75F3P9U/wWP5KfWZMZaGl6NRaH17M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=f1PJCckQkObpauYWqVCHRg6rms BcVP7btT+nXTlnfr6RM6ZXU1XGWKlojAorlYZK/yn39HeifIK8DPjG4vsz+EsH2v jW2YTuZTJ/cVcY2OmgqQKRYtHbUDtSZuEc/l3GhJqi2reOXkl/L70gTf7nx61Sq4 xkAnhGpI0FbUCl6aI= Received: from h.hanazo.no (unknown [173.38.220.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id DDBD4D7884; Thu, 17 Mar 2016 01:45:52 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CCFC712B8947; Thu, 17 Mar 2016 09:45:50 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8411BC2F-B583-4D41-9F4B-7474BA545C88"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56E9A16B.4030605@si6networks.com> Date: Thu, 17 Mar 2016 09:45:49 +0100 Message-Id: References: <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 08:45:56 -0000 --Apple-Mail=_8411BC2F-B583-4D41-9F4B-7474BA545C88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> that's well known. it just isn't clear to me what you are trying to = achieve with this draft? >> on one hand it alludes to why L4 information might be required in the = network, on the other it says why routers aren't able to process the EH = chain... >=20 > We go back to square one all the time. >=20 > Please let me summarize: >=20 > 1) Packets with EHs are drpped because middleboxes and routers, in > practice, need to obtain layer-4 information >=20 > 2) Why do they need such layer-4 information? -- Because of the = reasons > stated in our I-D. >=20 > Everytime this topic comes up, you argue that processing layer-4 > information is not necessary, or ask why ops people do that. >=20 > This document answers that question, so that this gets clarified, and = we > can move on to improve the current state of affairs. >=20 > Otherwise, we live pretending that EHs are deployable, when they are = not. >=20 > Looking to the other side, or pretending that the problem doesn't = exist > doesn't help to solve problems. >=20 > The goal of publishing this document is so that we don't have to = rehash > the same discussion every time the topic of EHs come up. If your goal was to avoid rehashing discussions about EHs then I think = you would have been a lot more successful by not publishing this = document. There is no single common view on EHs that apply to all circumstances. = Which is why I have strong doubts that whatever you write in this = document will make any difference (not that I understand from this = document what difference (as in recommendations) it is actually trying = to make). I think Alvaro's comment on draft-ietf-v6ops-ipv6-ehs-in-real-world also = could apply to this draft: = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/b= allot/ If the working group is set on its path on publishing EH related = documents, I'll shut up. Best regards, Ole --Apple-Mail=_8411BC2F-B583-4D41-9F4B-7474BA545C88 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW6m6+AAoJEL7aWKiYQt92QZEP/14cLOXCASFWVwPidAyevsLX f+hXmjV57+R+0BrGbvcZFKIwWbVAmvvjBLFoX4TAEKqNcm6KVErreddYfvuhAYpy NCeMhb/hqiqN4LePNtw5LqM4NTGIlNx3KrxP54358iGepBH0Ic7FTi7bhV0SGg8N v0NSH3EfByQ5Rg/Xg1LVbtohGionmA1BWYzCbZ5K/ZGPFYMhZl2olS2HPxVreDIT K7sicFQTo4aCnA6mPo4XqYb455jSlEc4veIRwDdRDvRVwtAhE3rHRYT/yecZWt3b AFsqK91Yh08V+fhGNuGUfkm/FBFplZ/hHmgUq2q5V2SrZhmNPiNf+UHYqnSMkxJ3 icNLb8BBn6Cz5xlv+UluAPrxKcgJ6m5VTZ1dppz+hPjfNc9k4xC90UyJQROPQMVp RYKXfGqR3rQFi4xSsSrFeRUh5tWYSP9LIy69sJ0P2GiPWvZDY3ac04ppJuH1X2s7 +fGDiDKhF/bL6ua4ZZbuyjRs3TABbH2cI1Ls0MriVeT6a9LDIUUvr+49sr9rDulY J86VOdiDa4wbpDys6noBAXhZ4LPmUb5MMCE+s+xgl4SP/sZKiXgm/1y2ROAEfrwL IA7amroR8E7dWCBIBu9F4Nfl7Rj30M/DizGWtTniBa1SJhuAp+36Ar8o5sUGpXy+ 0wGyLSujjokgmQOtCb1R =D1BD -----END PGP SIGNATURE----- --Apple-Mail=_8411BC2F-B583-4D41-9F4B-7474BA545C88-- From nobody Thu Mar 17 05:08:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0486B12D92A for ; Thu, 17 Mar 2016 05:08:06 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o08g-HQBByjC for ; Thu, 17 Mar 2016 05:07:59 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E537712D922 for ; Thu, 17 Mar 2016 05:07:58 -0700 (PDT) Received: from [172.20.15.144] (port-213-160-6-163.static.qsc.de [213.160.6.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4ED638024A; Thu, 17 Mar 2016 13:07:53 +0100 (CET) To: otroan@employees.org References: <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56EA93C0.1040904@si6networks.com> Date: Thu, 17 Mar 2016 08:23:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:08:06 -0000 On 03/17/2016 05:45 AM, otroan@employees.org wrote: >> >> The goal of publishing this document is so that we don't have to >> rehash the same discussion every time the topic of EHs come up. > > If your goal was to avoid rehashing discussions about EHs then I > think you would have been a lot more successful by not publishing > this document. "Avoid rehashing a discussion" != "not ever talking about something". Every time we talked about EHs, you asked the same question: "why do you need to obtain the layer-4 information, if you're supposed to just fwd packets?" This document answers that question, among other things. You also noted that "all this is well known" (which then I don't follow why you asked the question in the first place), and that this stuff is covered elsewhere -- but even when it was asked a couple of times, you never said *where* it is covered. > There is no single common view on EHs that apply to all > circumstances. I haven't seen any operator saying that what is said in our document is incorrect. What are the "other" views that supposedly do not agree with the one stated in our document? I get the impression that discussions on EHs are unpopular, because people don't like to admit when there's a problem. But being n engineering group, I think we better admit problems and do our best to come up with solutions, than pretend there's no problem at all. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 17 05:23:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F20312DA88 for ; Thu, 17 Mar 2016 05:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qJAdrBawe2L for ; Thu, 17 Mar 2016 05:23:06 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B94F12DA50 for ; Thu, 17 Mar 2016 05:23:06 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 02606D7888; Thu, 17 Mar 2016 05:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=0C9L5Sr4Z72oscgZvuCyvjTTp3k=; b= Ks6bZxhXA1qZEKSA7Hty5FB1vYRXFwjb7wIUnS0ZlvmKWXk2Q2jjTRlTqyKLOpyi szAsAPZm8Ws5v4hWXzS/5f0oOzPJlaMdWRKg+IRoWexVREyVbuuBCj85P7sVOL/e KcJcQFleJp9FN1rlLeAZ2k5bcYhxsy+drz/AwYvpun8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=CWXv7fd/08mIYpSy4q3XrrzltT 9Od0zwyDAQOFJdRD+c7j3soTmIAgRIsCT5z4aw6D+1KoEculdubkB0F61XzuhgZi WoXxOvSnFiqCLmr154BJvWOXhfoqGp511htOTd4JITds97c2MSni03ejnNCe7WF8 6P1MufUjR0eGVfR8A= Received: from h.hanazo.no (unknown [173.38.220.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id BAF3CD7884; Thu, 17 Mar 2016 05:23:05 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8AD2912BC80F; Thu, 17 Mar 2016 13:23:03 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_289CDF6D-DDA1-470F-A034-FEAE1821D271"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56EA93C0.1040904@si6networks.com> Date: Thu, 17 Mar 2016 13:23:02 +0100 Message-Id: <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> References: <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:23:08 -0000 --Apple-Mail=_289CDF6D-DDA1-470F-A034-FEAE1821D271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Fernando, > I get the impression that discussions on EHs are unpopular, because > people don't like to admit when there's a problem. But being n > engineering group, I think we better admit problems and do our best to > come up with solutions, than pretend there's no problem at all. the problems are well known, just that there aren't any solutions. so it = is pretty pointless to continue to talk about the perceived problem ad = infinitum. cheers, Ole --Apple-Mail=_289CDF6D-DDA1-470F-A034-FEAE1821D271 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW6qGnAAoJEL7aWKiYQt924UAP/0s8GYst4SRY5/pEFVDGlYss NKSZkyks5IETmFmsHeE8ZSw0OkEe/fkv0S9EOh30zeK7lgc+FRepgsShEw8gls/t T04eiknVEAao6EX0WDia/ypIYSNx46WtejlI3s7X+5iY0DzLQB480AI4c0j4KaOh FIv+Jt+hJTvRmQvB9LlSusKcIVuMGkojAABCIBYxI/pXnv59w9A3XhN3RoR/yGFU PamqYbvav9z0H89oM6kc8NqJ5tViTCHVIzFpLzdE0+M3PFXOnpbsTMpzZckEKzNH mQBNeaQ8/+y7a7TX32ZhOLCdE04fqSXuGVULUOhPBiUcZaUl273UeFzfiiAn4+iw Vt3w2TWnFbUxmkeFORO1Z1SZSVts5dI3ffu3F9F9j00OMjCgAJJdV3tc3aoOT72u o3+wsLigS9zTXeCxHwkLEEyBfAxMDpGnQIj9xpUMBGBgBzGTZr7oJPVJUwM3wkIU 3ZS9kZkJrwXx8XBhUQS/wedrHjW5TekQEDDYKGuaSReOA8uS8ygnD2Pf7Jcghypy +pV3/8Fv3X5n5OhG9Y9qb14y3h+2T1rY13AjxhrRB7g3HseO+LDmIgk9pICuMYbx aerrQPIKLbfbaEE2Vyeu0txOImu0oRhLfuJtXmMF20kKbFVJjHdSJzb4NuacVWza XuoYLJjbJdyNPS+ver3K =8ouM -----END PGP SIGNATURE----- --Apple-Mail=_289CDF6D-DDA1-470F-A034-FEAE1821D271-- From nobody Thu Mar 17 06:13:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4B12D89E for ; Thu, 17 Mar 2016 06:13:01 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaf_XPk_I1hb for ; Thu, 17 Mar 2016 06:12:58 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664FA12D57F for ; Thu, 17 Mar 2016 06:12:27 -0700 (PDT) Received: from [172.20.15.144] (port-213-160-6-163.static.qsc.de [213.160.6.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 85B998017E; Thu, 17 Mar 2016 14:12:25 +0100 (CET) To: otroan@employees.org References: <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56EAAACA.5060801@si6networks.com> Date: Thu, 17 Mar 2016 10:02:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:13:02 -0000 On 03/17/2016 09:23 AM, otroan@employees.org wrote: > Fernando, > >> I get the impression that discussions on EHs are unpopular, because >> people don't like to admit when there's a problem. But being n >> engineering group, I think we better admit problems and do our best to >> come up with solutions, than pretend there's no problem at all. > > the problems are well known, just that there aren't any solutions. If the probems are well-known, why does the discussion revolve around "why we need to find layer-4 information"? It has been asked at least three times where else this is covered, and still you haven't mentioned where. When it comes to solutions, our I-D points a way forward. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 17 06:42:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3322712DBE4 for ; Thu, 17 Mar 2016 06:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2q6YvajHpzx for ; Thu, 17 Mar 2016 06:42:39 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438B712DBF3 for ; Thu, 17 Mar 2016 06:42:29 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id m126so76153618ywd.0 for ; Thu, 17 Mar 2016 06:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ia9a/XfPow17YgdtjjL8/d+MhSs0YDWc72QP5vl+JRo=; b=WTaHi7UuaMpgHvYIGNIRgMueWO50noJbss2H4TpBWQoWOJ6Hev2Ci9ZQcRETELn0tC ccbLZ5noutLnwWW8UZwLwQWDQNabTMyVI1YOiZrxVEZNuvCKsmFN5zEr12L2VYB3Z4Bi bFEcPmLRNYnUAyUBR99Zr8+WVxtuHxhd6dHgkw/aQzBAHablwqjmiG0kAmkGUAlG+1G5 EjdWCsxIG4V07ifhTXw8IyAiQVTR0rQvIYujj0lMO4vUq35/nz/enyMkrbl23t5XYqMc ZDhxkit6mZktWKqHrE+7tDa+yswvQYOjH6VvtrsUGhf6n8Bi8sagcboE1F2D4rSBnVv3 fe8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ia9a/XfPow17YgdtjjL8/d+MhSs0YDWc72QP5vl+JRo=; b=IHGiCP0Z3pOI3d5bIXkAB9Kjb+GcVj2O55mFHKN1kQb0lgoDN7ygvh/qy1/84ZL4KM mjUCRCiWstpzXcwouTjfe/FS6sbedW5D6yrIKYeHvDskT56d8PTMBnddKdGQ3kuBbTxx zuxB+wTJQ+7ZHxaCM9wsTA/Wxrjf1LJ+QnGeMTjwlYB0pcYr4k6b+zwL8837tZzlZFPY LU/Q+41Ge2xdgQvLW1CstZ1Zcs/ksIk9TRV3ERfdScl1q9Yj1L4wrLoGXQPwGfss3ON0 7zQ8/RmXEnGTm+nEjSKRql7ym/ZZCtrD9dxpK0/d4mGOCoyf5nWG4cNj0zS1Lij6LKRL u1LQ== X-Gm-Message-State: AD7BkJJil03JOmM8ryvV1v4mhKlmMf/L2dTkDKsAwuy52Mv2F6vsGOJgbJrQ+sq4QcfOypBn7Yax9biEHKlo6g8e X-Received: by 10.37.230.83 with SMTP id d80mr4153692ybh.186.1458222148405; Thu, 17 Mar 2016 06:42:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.19.65 with HTTP; Thu, 17 Mar 2016 06:42:08 -0700 (PDT) In-Reply-To: <56EA93C0.1040904@si6networks.com> References: <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.1040904@si6networks.com> From: Lorenzo Colitti Date: Thu, 17 Mar 2016 22:42:08 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=94eb2c0af9a82960b5052e3ecd28 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:42:42 -0000 --94eb2c0af9a82960b5052e3ecd28 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 17, 2016 at 8:23 PM, Fernando Gont wrote: > Every time we talked about EHs, you asked the same question: "why do you > need to obtain the layer-4 information, if you're supposed to just fwd > packets?" > I disagree with the characterization of the problem. Intermediate routers don't typically need to find the layer-4 header. If operators configure them to do so, then such operators are also free to configure the boxes to drop the packets if they can't find the layer-4 header. As regards ACLs: the extension headers are a part of the packet just like any other, and security policies can do whatever they wish with them. You can certainly define a security policy that allows no extension headers at all if you wish. As regards hashing: traversing the whole length of the extension header chain only to provide flow-based hashing is a bad use of processing power. (If it's implemented in hardware, it's might also be a bad use of die space, enercy, customer money, etc.) Using the flow label is much better. So perhaps we should recommend that if hosts emit packets with extension headers, they should also randomize the flowlabel. --94eb2c0af9a82960b5052e3ecd28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 17, 2016 at 8:23 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
Every time we talked ab= out EHs, you asked the same question: "why do you
need to obtain the layer-4 information, if you're supposed to just fwd<= br> packets?"

I disagree with the char= acterization of the problem. Intermediate routers don't typically need = to find the layer-4 header. If operators configure them to do so, then such= operators are also free to configure the boxes to drop the packets if they= can't find the layer-4 header.

As regards ACL= s: the extension headers are a part of the packet just like any other, and = security policies can do whatever they wish with them. You can certainly de= fine a security policy that allows no extension headers at all if you wish.=

As regards hashing: traversing the whole length o= f the extension header chain only to provide flow-based hashing is a bad us= e of processing power. (If it's implemented in hardware, it's might= also be a bad use of die space, enercy, customer money, etc.) Using the fl= ow label is much better. So perhaps we should recommend that if hosts emit = packets with extension headers, they should also randomize the flowlabel.
--94eb2c0af9a82960b5052e3ecd28-- From nobody Thu Mar 17 08:46:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC91012D924 for ; Thu, 17 Mar 2016 08:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3Nyr82lPaTU for ; Thu, 17 Mar 2016 08:45:47 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA93112D1E5 for ; Thu, 17 Mar 2016 08:45:46 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2HFjbuj012122 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Mar 2016 15:45:39 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org Message-ID: <56EAD120.7020501@foobar.org> Date: Thu, 17 Mar 2016 15:45:36 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: otroan@employees.org References: <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:46:02 -0000 otroan@employees.org wrote: > If your goal was to avoid rehashing discussions about EHs then I > think you would have been a lot more successful by not publishing > this document. > > There is no single common view on EHs that apply to all > circumstances. Which is why I have strong doubts that whatever you > write in this document will make any difference (not that I > understand from this document what difference (as in recommendations) > it is actually trying to make). It has been pointed out numerous times - both to you and to others - that this document is explicitly not making recommendations. It's only making observations and attempting to provide explanations for those observations. Nick From nobody Thu Mar 17 08:53:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D76D12D92C for ; Thu, 17 Mar 2016 08:53:44 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64-AaGZN4zMk for ; Thu, 17 Mar 2016 08:53:43 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8959E12D1E5 for ; Thu, 17 Mar 2016 08:47:10 -0700 (PDT) Received: from [172.20.15.144] (port-213-160-6-163.static.qsc.de [213.160.6.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F29838009E; Thu, 17 Mar 2016 16:47:08 +0100 (CET) To: Lorenzo Colitti References: <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.1040904@si6networks.com> From: Fernando Gont Message-ID: <56EAD0E1.4090706@si6networks.com> Date: Thu, 17 Mar 2016 12:44:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:53:44 -0000 On 03/17/2016 10:42 AM, Lorenzo Colitti wrote: > On Thu, Mar 17, 2016 at 8:23 PM, Fernando Gont > wrote: > > Every time we talked about EHs, you asked the same question: "why do you > need to obtain the layer-4 information, if you're supposed to just fwd > packets?" > > > I disagree with the characterization of the problem. Intermediate > routers don't typically need to find the layer-4 header. If operators > configure them to do so, then such operators are also free to configure > the boxes to drop the packets if they can't find the layer-4 header. That's not the point this I-D is making. What it is saying is that even if you don't want to drop EHs, you may have to do so, for the reasons noted in the I-D. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 17 09:36:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ECA12D7CF for ; Thu, 17 Mar 2016 09:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hls8saB1qIz for ; Thu, 17 Mar 2016 09:36:02 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463D712D95F for ; Thu, 17 Mar 2016 09:35:57 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id vf5so899482igb.0 for ; Thu, 17 Mar 2016 09:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tjvwUb7JbOcQ80wRAmO5T0w0IUCErGKMUAc2hbI/Pi8=; b=r2QuyYGfT1DwVZWS8ISLTtPwqKRQ50CAGbgiv12o8I3pn94vh7znZCv5mNl9FRXzDT 0m6O3VjLQWPdOmFYgrAiWwiCEEPTG9AMW3LEOijDujfKk9SMcY1GA/2ehD3jSpysz3Y3 4ivHIwOTUDJA1ckk7/Bvkz2y1ThRhCGrHBLDa8ON3kXhHJH7BINUT1zia0hqa3l9OVu/ ksu+a3vEFGj1DTaa7v76lmewlBTVByhro9G/pCSjnjwiWHILHgCdPgdXzT7tEKTyYvnq rOobI7kcs5pCnpKjHNMaa6Td7gGHZMHZnG5IqW7Npme+EVqUOuWhyNVVe+RyfCkr0i7c no4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tjvwUb7JbOcQ80wRAmO5T0w0IUCErGKMUAc2hbI/Pi8=; b=RnpEXsxrs3vlmhefbowAsVneQyIHnit+4fl7HKOw/+sRg94yFqFPSbf1X0T52VodcH TdvjLtXMYss2Qhgf5NpHT/sow/r3Qfn50GSRq+EZlql/8CeVwM0yPOzF0PF2AnyHSWRr 4l+T9eAX9YyZFcUEOJgyI55gz/cHTj5u0KzHMe+K2c4A2fppl80so/K+VyMavSZYeEuL 81DwctVBqrguxWGUPA4rhZvAv3u9R+Na8Yx7J0v1JzDrRyu1Ed2Q51xLv9dav+oZxfz2 mh+Uma/KU2DERdh/OwnLMTMie1WCazSmyzs8fXTUi922Ht9YDVh0nAJ/rkzReUYoD6nw aAZA== X-Gm-Message-State: AD7BkJIOsf6+snTjQMeiRfQX8axitHUJl7kvmjucr5j8G5WzepW6ZHYHnDU11quX2R5dHKq2Q5SM955VigFTdw== MIME-Version: 1.0 X-Received: by 10.50.64.242 with SMTP id r18mr13161764igs.65.1458232556439; Thu, 17 Mar 2016 09:35:56 -0700 (PDT) Received: by 10.107.160.203 with HTTP; Thu, 17 Mar 2016 09:35:56 -0700 (PDT) In-Reply-To: <56EAD0E1.4090706@si6networks.com> References: <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.1040904@si6networks.com> <56EAD0E1.4090706@si6networks.com> Date: Thu, 17 Mar 2016 09:35:56 -0700 Message-ID: From: Tom Herbert To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:36:04 -0000 On Thu, Mar 17, 2016 at 8:44 AM, Fernando Gont wrote: > On 03/17/2016 10:42 AM, Lorenzo Colitti wrote: >> On Thu, Mar 17, 2016 at 8:23 PM, Fernando Gont > > wrote: >> >> Every time we talked about EHs, you asked the same question: "why do you >> need to obtain the layer-4 information, if you're supposed to just fwd >> packets?" >> >> >> I disagree with the characterization of the problem. Intermediate >> routers don't typically need to find the layer-4 header. If operators >> configure them to do so, then such operators are also free to configure >> the boxes to drop the packets if they can't find the layer-4 header. > > That's not the point this I-D is making. What it is saying is that even > if you don't want to drop EHs, you may have to do so, for the reasons > noted in the I-D. > I think the I-D presents a good arguments for why packets with EHs are dropped and establishes that will intermediate devices commonly need layer-4 "information". But this does not necessarily mean that intermediate devices need to access the layer-4 header to get required information (as the flow label demonstrates), nor has it been established that they have to always parse the full header chain to find the layer 4 header (the offset option https://tools.ietf.org/html/draft-zhang-6man-offset-option-01 could be used). Section 8 make recommendations on action to take. In particular there is a fair amount of detail on arbitrarily capping the length of extension headers chain- this seems to assume that devices must parse the full header chain to get layer-4 information they need. So I would view this as one possible technique to evaluate, but it seems like other alternatives (like the offset option) to explore should be mentioned here also, or maybe this recommendation should be taken out. Tom > > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Mar 17 13:45:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B92912D6CE for ; Thu, 17 Mar 2016 13:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbibA-aUvlUF for ; Thu, 17 Mar 2016 13:45:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FE312DB1D for ; Thu, 17 Mar 2016 13:45:14 -0700 (PDT) Received: from mb-2.local ([8.18.217.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u2HKj5op030368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Mar 2016 20:45:05 GMT (envelope-from joelja@bogus.com) To: otroan@employees.org, Fernando Gont References: <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> From: joel jaeggli Message-ID: Date: Thu, 17 Mar 2016 13:45:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j0DGgtDi5G8msN5xqwhdQNLtchlFEArkL" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 20:45:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j0DGgtDi5G8msN5xqwhdQNLtchlFEArkL Content-Type: multipart/mixed; boundary="UJDF3xnkfU0WnvNFwTxmOUqnMg2TPePI5" From: joel jaeggli To: otroan@employees.org, Fernando Gont Cc: "v6ops@ietf.org" Message-ID: Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops References: <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> In-Reply-To: <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> --UJDF3xnkfU0WnvNFwTxmOUqnMg2TPePI5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/17/16 5:23 AM, otroan@employees.org wrote: > Fernando, >=20 >> I get the impression that discussions on EHs are unpopular, because >> people don't like to admit when there's a problem. But being n >> engineering group, I think we better admit problems and do our best to= >> come up with solutions, than pretend there's no problem at all. >=20 > the problems are well known, just that there aren't any solutions.=20 I'm pretty sure that isn't an acceptable answer in the long run. If one belives that we should be offering guidance to implementors and operators such that filtering is either less a persistent violation of expections or ceases to be an issue in the long term. simply pretending that the issue doesn't exist is a pretty bad message to developers. > so it is pretty pointless to continue to talk about the perceived probl= em ad infinitum. >=20 > cheers, > Ole >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --UJDF3xnkfU0WnvNFwTxmOUqnMg2TPePI5-- --j0DGgtDi5G8msN5xqwhdQNLtchlFEArkL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbrF1AACgkQ8AA1q7Z/VrJO7QCeIXrf/0e3+T2zemjvV7hsByJF fawAoIQUxqNXabePX7BYLV1ufxC18cbw =xRYl -----END PGP SIGNATURE----- --j0DGgtDi5G8msN5xqwhdQNLtchlFEArkL-- From nobody Thu Mar 17 14:09:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C6E12DC0A for ; Thu, 17 Mar 2016 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5tOdQHcMQ2n for ; Thu, 17 Mar 2016 14:09:37 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD7C12DA90 for ; Thu, 17 Mar 2016 14:09:37 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1C89ED788D; Thu, 17 Mar 2016 14:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=8zDcgOD+wAeeXzbrCoXcAiMzh/k=; b= lRQwgd9vyt/+XHYR0AOcEJmxz3tUiK6OFlV2KjMuLxcPCguVbPT0Il69kgUj3oX+ Z0G15QWTQvBJ2+Q7yrhSVAOINbiZjab0gO1EN79W2/6NyPxn6ipg/qa0f3pLSZED 7ShrQ/xdLDiAIeOCcSnqs/5OPc0VQcPptUbnnOPMbkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=QVnJDrpxe+I3RxS21ur1KcUK1T IZQSXLJSTs0tMy/8hszwByY6xbGOhXNnDBCCfJdylgdlCx8tABTmV+D/Ma07+HpX DmAD0IqKxUPlQBqMVVDvDDTa0xK7midJVMwod99lLPw0PhjXrf7o1ERH+NTwmTKQ EC6CZ0PnamKeHJJDk= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id DFE7ED7884; Thu, 17 Mar 2016 14:09:35 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 092F712C68E8; Thu, 17 Mar 2016 22:09:32 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C864C177-CF7A-4D4D-AAF4-045DCCA6B3CF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Thu, 17 Mar 2016 22:09:30 +0100 Message-Id: <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> References: <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> To: joel jaeggli X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 21:09:42 -0000 --Apple-Mail=_C864C177-CF7A-4D4D-AAF4-045DCCA6B3CF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 Joel, >>> I get the impression that discussions on EHs are unpopular, because >>> people don't like to admit when there's a problem. But being n >>> engineering group, I think we better admit problems and do our best to >>> come up with solutions, than pretend there's no problem at all. >> >> the problems are well known, just that there aren't any solutions. > > I'm pretty sure that isn't an acceptable answer in the long run. If one > belives that we should be offering guidance to implementors and > operators such that filtering is either less a persistent violation of > expections or ceases to be an issue in the long term. simply pretending > that the issue doesn't exist is a pretty bad message to developers. let me ask differently. how is this "problem" any different from: - "unknown" L4 header - IPsec encryption - L4 encryption (it's all port 443) - tunnels Cheers, Ole --Apple-Mail=_C864C177-CF7A-4D4D-AAF4-045DCCA6B3CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW6x0LAAoJEL7aWKiYQt92qwwQALyxiLrVOt3StsmrhYZp39P1 dtvLXRdE29cp8cj7g7sK8e04H+4uxXrhEUDYKLgpbh+zAtBIA5pgv4rHWjuH3fkL IAit19ARmqmLSdsC46/XK9XaOSCWeysdgZ5A6UKzfuqBH+1bg5s+eLvq+gVQWAPA rWvgn1CtgWQrCTcLusS1Nd4YAOIDIAlHNdL85WVI+LOLbFtXP7ecEblFcquYQVsu BTCNZpe30nmStUgKcx8bM7jxe80aoyHitrN6EV2FHlGApT4/ZUmRpHbyLzNCJznO jfGsAGThSj67B/mlb6Fb6swoNihRIXCr94wlS9lwWD1Kf1ix48ZV9BT6fy/R92OK I28YwEcEtBxRq2I601x9i4B5wu2QJJDUOkZqTbT1KqUfznXDSQnAKIIofzIQu8QA KjPZ1jL8YW+vFhjFPUV6pV3ldJ9xef2kVpBtMGbEQxnQl+cHplLYUI60rfb85auy 0Bx+yf+EibJ5BnuLID7NdRnIlDlBufetWWDFfe7+ysTA/GZULc9Gyy2QeRMOFZXo eGb7ocPaG4lZJW1LKcaCaJN5ArqFV9w7xc75wf2COr+9OV8IWp80I02ldiVPyUFQ WgeUikC+7Yakj8o3LgRh03qIuWnsMrV61aToPl3ydfbQ5wQwMHhFOSdMdyXA2EnB eD2lHR64eUTKA+j6qvtS =XDJ3 -----END PGP SIGNATURE----- --Apple-Mail=_C864C177-CF7A-4D4D-AAF4-045DCCA6B3CF-- From nobody Thu Mar 17 14:36:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EFE12D7D0 for ; Thu, 17 Mar 2016 14:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d_RQpzpv0zY for ; Thu, 17 Mar 2016 14:36:07 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA7C12D705 for ; Thu, 17 Mar 2016 14:36:02 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id v130so24925704lfd.2 for ; Thu, 17 Mar 2016 14:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=TrOJrqYyZfNNziPhnMt85wXlnSVFcMfQDOVLtwUehP4=; b=uG27QxVqleQj8nCQgBu8ctlwiMgB5YHCsXDI7tgueghiYeKkjf6GnFxMiMJXS9DjdN 8MPz44XuS4PSsuyBKJAlWcu1fwng7555RCvVKxlud+kHlI4/KLpKl3aNwFvOuiyapGTS aYhN/nNw81PGrqUNzSXt5HoZ5odQ/83y/ZD6JuKq5nKDTm7BvR0lEFlWsvwmHmHJkx9E 6uoWosYi/3pVcV48XBKwthb2fnvBBMs4FDq32ySYJSdA3wQwD5nIRpoq+VmtlzMlFC1d 1QT7qftaSxsoWu26qBkHRSASj7IuGr9nPpfpzqME+qCto0/msIF8rXZHla9Ky83Jsjla SSFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=TrOJrqYyZfNNziPhnMt85wXlnSVFcMfQDOVLtwUehP4=; b=U2AYbyNl4JPZKjJrjdfE74EkH9NtfrEXjHTKXGPzJGKvGNwbzMruKySWTbVXz8OJ+u K+mNVRPSmt/aAk/WwxtNWIE8ZfZdtLVEk5hBTE5bvSsLndd/ql2ouFX8imXdWFqkweCc uvOsQDsnaLv4DNFEZ+gjVn+cRpwMnfcOosomBM2vS4bgd9OlSTrQYk/6Cb90LPxNteE8 9SCcGzhfYV9Kzz4TJg0WAequtlaoyJUasyeG5PlxSh03o53HWN77ZYivFEuDFxjRICGb LZTGFy5h720wEg3AfpudgCektefswl/tQMA5isDtYAAtsgMwd4UJTM95Sy1lnAoAgrBR ZW/g== X-Gm-Message-State: AD7BkJIyjmfzZYj4xPUTQKR8f76h2zgC9M7xd5FGKsV9K8uJYT8gWJXKhilJaDgM6N9+QxKgYR2KYBTxEqjMnw== MIME-Version: 1.0 X-Received: by 10.25.33.140 with SMTP id h134mr4752105lfh.159.1458250560509; Thu, 17 Mar 2016 14:36:00 -0700 (PDT) Received: by 10.25.19.152 with HTTP; Thu, 17 Mar 2016 14:36:00 -0700 (PDT) Date: Fri, 18 Mar 2016 10:36:00 +1300 Message-ID: From: Hermin Anggawijaya To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a114102c0a71ce0052e456aa8 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 21:36:09 -0000 --001a114102c0a71ce0052e456aa8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Tue, Mar 15, 2016 at 5:30 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hi, > > Let me take advantage of this discussion to discuss the necessity of this > join. > > Le 03/03/2016 03:29, Hermin Anggawijaya a =C3=A9crit : > >> >> On Linux, the IPv6 stack will generate MLD report (both unsolicited >> report and as reply to queries) if a socket is set with >> IPV6_ADD_MEMBERSHIP or IPV6_JOIN_GROUP for the given IPv6 multicast >> address. >> > > I think linux does REPORT even though the user does not specifically > open a socket with these parameters. Wireshark on a vanilla linux will > expose those MLD messages on LL scope. > Linux only automatically generates MLD reports on multicast capable interfaces for 'all-nodes' and 'all-routers' groups (if it's forwarding), with interface, link-local, site-local scopes. For other groups, ADD_MEMBERSHIP or JOIN_GROUP needs to be set on the socket before report is generated. Kind regards Angga > > A question that could be raised is on the necessity of this message. > > On one hand, it is good for a desktop PC to inform the office switch > that it needs to be part of that group. It helps channelling messages. > > But when there are only Hosts on that link, the message is still issued > even though all Hosts must be subscribed to the LL group anyways, by > definition of the LL scope. > > This may have some significance in particular mobility settings where > the medium must be free as much as possible of what could be considered > noise. In vehicular networks the 802.11-OCB (aka 802.11p) is stripped > off of all link-layer messages like 802.11 beacons/assn/auth in order to > keep the medium as silent as possible, yet the IP MLD LL messages are > there. These could be considered to be superfluous. But of course the > MLD REPORTS for wider than LL scope are still needed in vehicular network= s. > > Alex > > And looks like the Python script should do the job. >> >> Having seen an MLD report from a host running the Python script, I >> would have thought that the LAN switch would make the host (or the >> switch port the host is connected to) to become a member of the >> multicast group, and the switch should forward all multicast packets >> for ff02::114. >> >> *If the corresponding multicast packets (ff02::114) are indeed >> filtered by MLD snooping switch* - despite seeing the membership >> report sent by the host running the script, then on some switches >> you could try either (depends on availability of features): >> >> 1. disable snooping - but this could make the LAN 'chatty' 2. set >> the default behaviour for unknown multicast address to flood, then >> apply a filter on the MLDSnooping module so that it never 'learns' >> ff02::114, thus keeping ff02::114 as unknown multicast 3. add static >> MLD snooping entry for ff02::114 and make all the ports in the vlan >> as a member. 4. add ff02::114 as a 'protocol' address to MLD >> Snooping so that it is flooded properly to 'router ports' like >> ff02::6, ff02:6, ff02::9 etc. >> >> >> Kind regards >> >> Angga >> > --001a114102c0a71ce0052e456aa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Tue, Mar 15, 2016 at 5:30 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Hi,

Let me take advantage of this discussion to discuss the necessity of this j= oin.

Le 03/03/2016 03:29, Hermin Anggawijaya a =C3=A9crit :

On Linux, the IPv6 stack will generate MLD report (both unsolicited
report and as reply to queries) if a socket is set with
IPV6_ADD_MEMBERSHIP or IPV6_JOIN_GROUP for the given IPv6 multicast
address.

 I think linux does REPORT even though the user does not specifically
open a socket with these parameters.=C2=A0 Wireshark on a vanilla linux wil= l
expose those MLD messages on LL scope.


<= div>Linux only automatically generates MLD reports on multicast capable int= erfaces for 'all-nodes'
and 'all-routers' groups (if it&= #39;s forwarding), with interface, link-local, site-local scopes.

For other groups, ADD_MEMBERSHIP or JOIN_GROUP needs to be set on = the socket before report is generated.


Kind regards
Angga

=C2=A0

A question that could be raised is on the necessity of this message.

On one hand, it is good for a desktop PC to inform the office switch
that it needs to be part of that group.=C2=A0 It helps channelling messages= .

But when there are only Hosts on that link, the message is still issued
even though all Hosts must be subscribed to the LL group anyways, by
definition of the LL scope.

This may have some significance in particular mobility settings where
the medium must be free as much as possible of what could be considered
noise.=C2=A0 In vehicular networks the 802.11-OCB (aka 802.11p) is stripped=
off of all link-layer messages like 802.11 beacons/assn/auth in order to keep the medium as silent as possible, yet the IP MLD LL messages are
there.=C2=A0 These could be considered to be superfluous.=C2=A0 But of cour= se the
MLD REPORTS for wider than LL scope are still needed in vehicular networks.=

Alex

And looks like the Python script should do the job.

Having seen an MLD report from a host running the Python script, I
would have thought that the LAN switch would make the host (or the
switch port the host is connected to) to become a member of the
multicast group, and the switch should forward all multicast packets
for ff02::114.

*If the corresponding multicast packets (ff02::114) are indeed
filtered by MLD snooping switch* - despite seeing the membership
report sent by the host running the script, then on some switches
you could try either (depends on availability of features):

1. disable snooping - but this could make the LAN 'chatty' 2. set the default behaviour for unknown multicast address to flood, then
apply a filter on the MLDSnooping module so that it never 'learns'<= br> ff02::114, thus keeping ff02::114 as unknown multicast 3. add static
MLD snooping entry for ff02::114 and make all the ports in the vlan
as a member. 4. add ff02::114 as a 'protocol' address to MLD
Snooping so that it is flooded properly to 'router ports' like
ff02::6, ff02:6, ff02::9 etc.


Kind regards

Angga

--001a114102c0a71ce0052e456aa8-- From nobody Thu Mar 17 14:48:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30412D5B0 for ; Thu, 17 Mar 2016 14:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_kBRbZYSNeT for ; Thu, 17 Mar 2016 14:48:46 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5281B12D667 for ; Thu, 17 Mar 2016 14:48:45 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2HLmYlU022404 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Mar 2016 21:48:35 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org Message-ID: <56EB2630.2020208@foobar.org> Date: Thu, 17 Mar 2016 21:48:32 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: otroan@employees.org References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> In-Reply-To: <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 21:48:48 -0000 otroan@employees.org wrote: > how is this "problem" any different from: > - "unknown" L4 header > - IPsec encryption > - L4 encryption (it's all port 443) > - tunnels none of "unknown" L4 headers, L4 encryption or tunnels are subject to the catastrophic levels of packet loss as measured in draft-ietf-v6ops-ipv6-ehs-in-real-world. ipv6 ipsec wasn't measured in that draft - it would probably have been useful if there were some easy way to measure this. It's not ok for the IETF to sit on its hands and pretend that this isn't a protocol problem. The EH mechanism as it stands is unworkable which is causing breakage on production networks. This needs attention from the IETF because EHs provide core ipv6 functionality and without this functionality, IPv6 is crippled as a protocol. Nick From nobody Thu Mar 17 14:54:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B0112D8CA for ; Thu, 17 Mar 2016 14:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg0jRFdiIwEH for ; Thu, 17 Mar 2016 14:54:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EF112D57F for ; Thu, 17 Mar 2016 14:54:02 -0700 (PDT) Received: from mb-2.local ([8.18.217.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u2HLrxPd030751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Mar 2016 21:54:00 GMT (envelope-from joelja@bogus.com) To: otroan@employees.org References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> From: joel jaeggli Message-ID: <8e822f51-fc8c-8dc4-bb38-f089a6e7742a@bogus.com> Date: Thu, 17 Mar 2016 14:53:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fnUwKV8nnWuxrN8EgL3XdTSBWsgHadQ0U" Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 21:54:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fnUwKV8nnWuxrN8EgL3XdTSBWsgHadQ0U Content-Type: multipart/mixed; boundary="071oSuL9UeqBOwUsMuer0rHgeo0wuDLjx" From: joel jaeggli To: otroan@employees.org Cc: Fernando Gont , "v6ops@ietf.org" Message-ID: <8e822f51-fc8c-8dc4-bb38-f089a6e7742a@bogus.com> Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops References: <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> In-Reply-To: <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> --071oSuL9UeqBOwUsMuer0rHgeo0wuDLjx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/17/16 2:09 PM, otroan@employees.org wrote: > Joel, >=20 >>>> I get the impression that discussions on EHs are unpopular, because >>>> people don't like to admit when there's a problem. But being n >>>> engineering group, I think we better admit problems and do our best = to >>>> come up with solutions, than pretend there's no problem at all. >>> >>> the problems are well known, just that there aren't any solutions. >> >> I'm pretty sure that isn't an acceptable answer in the long run. If on= e >> belives that we should be offering guidance to implementors and >> operators such that filtering is either less a persistent violation of= >> expections or ceases to be an issue in the long term. simply pretendin= g >> that the issue doesn't exist is a pretty bad message to developers. >=20 > let me ask differently. >=20 > how is this "problem" any different from: > - "unknown" L4 header unknown is rather different than unfound if you're actually attempting to parse the header chain. you still have a binary decision to make with respect to forwarding or not. > - IPsec encryption > - L4 encryption (it's all port 443) > - tunnels Because if you filter any of these three that's generally the product of a deliberate policy enforcement action rather than due to a collateral damage from another decision. > Cheers, > Ole >=20 >=20 --071oSuL9UeqBOwUsMuer0rHgeo0wuDLjx-- --fnUwKV8nnWuxrN8EgL3XdTSBWsgHadQ0U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbrJ3cACgkQ8AA1q7Z/VrIWrQCeLmjg8ayPTzL4KSNHDW/Lw8E9 jKMAnjhKMufXr0CP7H4bmh1ixscuFulo =9FKp -----END PGP SIGNATURE----- --fnUwKV8nnWuxrN8EgL3XdTSBWsgHadQ0U-- From nobody Thu Mar 17 15:30:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C6A12DD5E for ; Thu, 17 Mar 2016 15:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.522 X-Spam-Level: X-Spam-Status: No, score=-114.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7fqKfIxP7YN for ; Thu, 17 Mar 2016 15:29:56 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D95312DD5B for ; Thu, 17 Mar 2016 15:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3994; q=dns/txt; s=iport; t=1458253796; x=1459463396; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=v+VGS/F+DtuDT+9PNXaZZuowB/GS8KFaw9y0V8fV56E=; b=ezNRtnOtcTz7kiaPavOUE2FHD+w6bASV6HthSomhX4LTLQNmBowmDm/i LguRxbRjLlJXcS4Zu+lrH8bYhdliAxx2Q3+lhIxXRwskqS1uCDXuUaAwi i4i/yOwR7AEclXjxlj22IFTxwgTJby+dFit5n1Mu+fBghSQ7IiO7wGboA M=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AgCqL+tW/40NJK1eg0WBQQa6AQ6Bb?= =?us-ascii?q?4YNAoE6OBQBAQEBAQEBZCeEQgEBBHkQAgEIGC4yJQIEDgUOiBnBWgEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBDgiIEYJRh2eBDwWFV5F9AYMbgWaGSII3jwaPAgEeAUOCC?= =?us-ascii?q?BSBSWqJZX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,351,1454976000"; d="asc'?scan'208";a="250625442" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Mar 2016 22:29:35 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u2HMTZKi032167 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Mar 2016 22:29:35 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Mar 2016 17:29:34 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Thu, 17 Mar 2016 17:29:34 -0500 From: "Fred Baker (fred)" To: Nick Hilliard Thread-Topic: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRe3z+jjdZn/af1k6rS4wakEAZsw== Date: Thu, 17 Mar 2016 22:29:34 +0000 Message-ID: <9B901C5C-6BD1-4EFE-B448-AFFE9E07F972@cisco.com> References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <56EB2630.2020208@foobar.org> In-Reply-To: <56EB2630.2020208@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_586CF4AD-B212-4101-802C-97FDFDD976F6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 22:29:58 -0000 --Apple-Mail=_586CF4AD-B212-4101-802C-97FDFDD976F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 17, 2016, at 2:48 PM, Nick Hilliard wrote: > It's not ok for the IETF to sit on its hands and pretend that this = isn't > a protocol problem. The EH mechanism as it stands is unworkable which > is causing breakage on production networks. This needs attention from > the IETF because EHs provide core ipv6 functionality and without this > functionality, IPv6 is crippled as a protocol. I'm scratching my head on both of those statements. Help me out, if you = would. In there first statement, you assert that we're looking at a protocol = problem. We may be, but that's not obvious to me. There is an issue with = HBH headers, or at least with their implementation, which we are looking = at in draft-ietf-6man-hbh-header-handling. Nalini Elkins has a problem = with the lack of a counterpart to the IPv4 ident field, which she wants = to address with a Destination Option in draft-ietf-ippm-6man-pdm-option. = Several folks have issues with fragmentation and reassembly = (draft-bonica-6man-frag-deprecate), but that is more about security = policy and perceived application designer laziness than about issues = with the header; it in fact fragments and reassembles if used for that = purpose, and AFAIK is widely implemented. You go on to say that IPv6 Extension Headers implement core = functionality. I'll agree that the Security Header is core; I go to work = using one of a couple of VPN technologies, and packet layer encryption = is central to both. I'm hard pressed to say that the other headers are = core; we don't use options in IPv4, and we don't seem to need these = headers to make it work. Speaking wearing my protocol-droid hat, if I = walk through a list of extension headers (HBH, Routing, Fragment, = Destination Options, Security) I haven't heard anyone say "the protocol = is incorrect; we need to move these bits over there and add these other = bits somewhere else, or define some different processing algorithm". The = only one we have deprecated is RH0, and even there, the issue isn't that = RH0 can't be used to implement what in IPv4 we would call a Loose Source = Route and Record; it's that even in IPv4 we decided that having that = option was a security nightmare. If we're looking at a protocol problem, we should be able to describe = proposed changes to the protocol to fix it. I'm not hearing such things = described, apart from draft-wkumari-long-headers. Is the issue addressed in draft-wkumari-long-headers what we're talking = about? If so, can we discard the bluster in tone and say that? Is there = another issue? Can we describe it? --Apple-Mail=_586CF4AD-B212-4101-802C-97FDFDD976F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVusvzUayAOS/EQ8MAQI0XRAAplDdYUnD8w5v70lNMhTR4y7/tGY7hHw+ AdvviWBCX6JwgS3Mxy3ZRKa9KSv2mkTatkZgH0t2t+yGW+k0E+wxhNtUpuV4ZrjO L+dlh0WMNdn1IJjHsFYIkYJQbnFvHWrNBWuUiisydImYbsQzFbdeRJru5VIi92Tc 7aKh24w4wbHOkzdFDnxZ1pWS1PU70m1PmFyB0YrurmyO0/auU3hRI98uQq9Ldyjw kss3TuPyei4WApJdH3WaDyS54gdW4bwKvtZ69g/7iE2vFqGiTPhTsJAu6NbnnOUt Ihz/x1QgeyO9v+yyP7QszdVmLJ9HWul7+6UmpxSgrAVbD+DztEUjQiBf2vd7gmDP YcaE7L0D8v5Rp/WV1IFxiuXVxDDI1hFtJI50Ij8bsNeFRUx3NMFCBZB5pW7z7/Mw r7yL0mTwb0vwrmEqErayDddJ/sDOFkO/KoZs++Ln0BJwi4mKSDZA9/H+UouTfniq b8EASLxhdwfxlM/w1Gyk2K39+ZUX31NFb8lJdEgjARUiLziKthWuaQ8I8ePUICJX HDzIEHn+Kh/piqSWm0s/78ZsvRfMT8BN02KDfY4BxMfaVSPkHUHwjPLTHtzYwpa9 wBsVlwyPNjHrCgI9/mP585wG68qA2/bgqrA3wTh1Z5wgn5pLM45i4BWfrkgfDse3 Oi+ce8wgO84= =5wYO -----END PGP SIGNATURE----- --Apple-Mail=_586CF4AD-B212-4101-802C-97FDFDD976F6-- From nobody Thu Mar 17 17:10:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE72512DDED for ; Thu, 17 Mar 2016 17:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLcW4uP6OBPJ for ; Thu, 17 Mar 2016 17:10:54 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF3F12DBD7 for ; Thu, 17 Mar 2016 17:10:54 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h129so120669606ywb.1 for ; Thu, 17 Mar 2016 17:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgOwtbK0uz8Kd7Ap9Si9bRtlPlMzu295NEGEYyYRNDc=; b=NuIoRgsB7kTWa/mgg5LJ+rmO70JWPgsXq8zjRb4dALjp0ZHzAlXTBlcakEfb1h21oP 1AZA20vq7vg7jx2MLZoHkbudGldAepkzCInKRyzclDdJgomaHFXMa0JonPa68lsn5fXi CwDUdfzSkvCcJNggRoMkDDKbc97VYiVYMsaVIiqgTzd/J+yWwKfF/39WMSpyJdNnjBcC 5mt/suSNTG+YSnUjr5JCzkyjxrefdwJ+G3qBX0/xGqV1qahBCL5NXh0xzV0qzsbQX6vC uK4a2xSynhJGJK0RuKamUguhmY2O6mUjZtrT09mr9zwbzjuJ+Tj8cma2zHvdhDtyk13g mFJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zgOwtbK0uz8Kd7Ap9Si9bRtlPlMzu295NEGEYyYRNDc=; b=T0tThIIOYNK2nBWIn0s4u/2G2gBDmk3NnCMg32Z+1Pm1twJdn9fBRDcfOOX9knd4UY 8yKJdee41v3jjzyHu01KLKglaW+IxT26x/A5TdMjcnFdYud7En0bFBufuHRdyY7i9Gxx WNL0eWntLaqjQf8iko9W9vSPQPXhA7UbwbLIIp/4Lyk8GIBRBmXeF/IWNpDh9g2VEyrw LWdBuzsPCbXbDAKX4pxMlEiRo7f8JyDag0mdJDGnD3qIjM3RqGi7HmuckPznaBHY1eQS bklQM2yyva6FDwyRDSHlCPo+te0ejCzdL0YQ/mwkodK/PT0MGy88tEay7NUDSHLxXnEg iA3Q== X-Gm-Message-State: AD7BkJKNmPiU+HrDV4IcLAxo5Ezx0cztNHr516xMWEyB33pwPOEhuhqONyB2JmuVKMYxAKw+fmV891/n41z3nfYh X-Received: by 10.13.238.194 with SMTP id x185mr6079109ywe.35.1458259853418; Thu, 17 Mar 2016 17:10:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.19.65 with HTTP; Thu, 17 Mar 2016 17:10:33 -0700 (PDT) In-Reply-To: <8e822f51-fc8c-8dc4-bb38-f089a6e7742a@bogus.com> References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <8e822f51-fc8c-8dc4-bb38-f089a6e7742a@bogus.com> From: Lorenzo Colitti Date: Fri, 18 Mar 2016 09:10:33 +0900 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=94eb2c0310948e479d052e479441 Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 00:10:56 -0000 --94eb2c0310948e479d052e479441 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 18, 2016 at 6:53 AM, joel jaeggli wrote: > > how is this "problem" any different from: > > - "unknown" L4 header > > unknown is rather different than unfound if you're actually attempting > to parse the header chain. you still have a binary decision to make with > respect to forwarding or not. > >From the point of view of security, I don't see a difference. Not found should be treated as unknown anyway. --94eb2c0310948e479d052e479441 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 18, 2016 at 6:53 AM, joel jaeggli <joelja@bogus.com> = wrote:
> how is this = "problem" any different from:
>=C2=A0 - "unknown" L4 header

unknown is rather different than unfound if you're actually atte= mpting
to parse the header chain. you still have a binary decision to make with respect to forwarding or not.

From the = point of view of security, I don't see a difference. Not found should b= e treated as unknown anyway.
--94eb2c0310948e479d052e479441-- From nobody Thu Mar 17 17:13:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E019412DDF8 for ; Thu, 17 Mar 2016 17:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTXdNqKBijJP for ; Thu, 17 Mar 2016 17:12:57 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4310112DDF5 for ; Thu, 17 Mar 2016 17:12:57 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id m126so96668209ywd.0 for ; Thu, 17 Mar 2016 17:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xhqOxWJb5/mxeetHQtzYKatGL9rlVaORo65aGQDHdJs=; b=JwyOx1MYPSeLHQ4OK8PWRT0llNcpCH1gyTgOum1JT2fwd8HIn78CV5lqVkZo6cfpeT IVzCFMFJ2N1sWe1iAK5F5xR4+V+nIFz3dD/IJT7JBHJ+2eI7r6kEVgq8E18AB4MT1lNu OIzU9eZKB3x7Rc030XndMJMNq77fkV2S906tnHBAVfLsGcVbGSqo8QmfLkPCVSzddZBh Bcig+6i9RTvJLELTiPinFxLYpk6gu7+FIoaODtKHjnDwHUDmZkYMNHeFe9LAkOtF5BYv BbHz7q0wGhQE8JtQys2bvDXVBliidvwWvul4qKRSg0Rrz3LmetWLncHMgsggdc3Vt4HY Alkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xhqOxWJb5/mxeetHQtzYKatGL9rlVaORo65aGQDHdJs=; b=gZZsfpd3+epowwu363iboNc7Jv+v30GX6E+qPU7vuVwigSf+WprTrDGhf9zau+ELWo cZLKsfvOQDkq8X9ruwoiMq9haMkrtAFIDAbk+Yt30p8TQqxEHEVf3d8wP7J1nVchIjWM uzF/swhUMrbtYWoG7466woaa9xMgiRHpmDIFRGoVdBnqI2foxPnL2B639+XAdDotfsQB nYaNhPddbitVHmjkyQePlxxJVQ6PrtbiGXTUzaJ6gC8lQCu/lAB8MUqx96fn0pcDH38Q OxkqfcZ9UHRhYrThaldgFSIBC0HKyqXPAiq8KO97boP7Mj63bsHopPtB5KC0OQruKADo 6bCg== X-Gm-Message-State: AD7BkJLa8otTH1qG+paB1WtnqOCAEy5tMEhRVC3tWoyX1Vdwo7hDY0zbLEbEmyTZCYVP1C7nEa9zEqLWPHtA5nFW X-Received: by 10.13.205.199 with SMTP id p190mr6108619ywd.116.1458259976454; Thu, 17 Mar 2016 17:12:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.19.65 with HTTP; Thu, 17 Mar 2016 17:12:36 -0700 (PDT) In-Reply-To: <56EB2630.2020208@foobar.org> References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <56EB2630.2020208@foobar.org> From: Lorenzo Colitti Date: Fri, 18 Mar 2016 09:12:36 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a114e5eb6e378a7052e479bb2 Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 00:12:59 -0000 --001a114e5eb6e378a7052e479bb2 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 18, 2016 at 6:48 AM, Nick Hilliard wrote: > none of "unknown" L4 headers, L4 encryption or tunnels are subject to > the catastrophic levels of packet loss as measured in > draft-ietf-v6ops-ipv6-ehs-in-real-world. And this is a protocol problem because...? IPv4 protocols other than TCP, UDP and ICMP are probably subject to even more catastrophic loss than extension headers, but we're not talking about fixing them. --001a114e5eb6e378a7052e479bb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 18, 2016 at 6:48 AM, Nick Hilliard <nick@foobar.org> w= rote:
none of "unknown" L4 head= ers, L4 encryption or tunnels are subject to
the catastrophic levels of packet loss as measured in
draft-ietf-v6ops-ipv6-ehs-in-real-world.

An= d this is a protocol problem because...? IPv4 protocols other than TCP, UDP= and ICMP are probably subject to even more catastrophic loss than extensio= n headers, but we're not talking about fixing them.
--001a114e5eb6e378a7052e479bb2-- From nobody Thu Mar 17 20:33:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C381512D7B4 for ; Thu, 17 Mar 2016 20:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K7K4LyhyWJ9 for ; Thu, 17 Mar 2016 20:33:40 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2071A12DF20 for ; Thu, 17 Mar 2016 20:33:40 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 4so17369101pfd.0 for ; Thu, 17 Mar 2016 20:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=fnHVUv6RYPlCvYHvuxwbWvcCgURQ8nhykoEurwjhQZc=; b=bW3JMALdx/brriAbWNyrHrHL9YLUT3zYPr61vO14itW0Y1K4CN1ZlAR2Z0XqXA1lxF sjR4B1pT4iDH1sC8bWwaruA5RKdEEjldS0ZIaVusb2ga7CCB/u9bNj9pkSMIjhu8A/as U+2xIwiskSvCY6DvjCLeNq257MW7PSRXYi7h66XaXqPsdheMYJe3se2MG2gUwZrThB/5 2FZCvlPFB1CN4L6ggEwyWiGB2IRZQOqhbLcz/gPZdgfU2Ndm7dz+aGTSYj/oGseKqxW2 ubXBbugcx2CoX2nqGSNAroicJrjXsixdz1pji38E4OK7KcbOdeBs1wmaDB9BPlM4TkTV OV8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=fnHVUv6RYPlCvYHvuxwbWvcCgURQ8nhykoEurwjhQZc=; b=HiSLcBDyvDiF8saRicsuVAGhckorLKBtpt5JBqhkCBi697Lix+C/OX/PWIzXEpxpF2 IGXspKmdldfb2W91v4grxikCtKIJK3f2SYbRSjt0PzbS5n36ZXZplLOPFY8/zS/G8blf fPTeM/LHkBQ8LdraSEu74zvTlfxRfifxvw16uEsBmbt+UrMMGlS4dEqlmd3tb2d4b1oz TPBGwVJNh1VEbTQlvuNpJCucvsyCKnUY+kByLmHsUB8Nu+djoMwx2YUaWg3a3mZQZE+u t1ZIPWAF2O95BwR3Hgeu4d3S/4wkRcI8J1bvLiwd92Lb9H6ZPmoeggK4RPGsHIhlbCi/ ELTA== X-Gm-Message-State: AD7BkJLiCKsjv/swBOAdnXVO1PsidNetsi1O3mXs3x7fGhS2H3Rp5SLvjWO0rkC329/l/g== X-Received: by 10.66.167.237 with SMTP id zr13mr20420460pab.85.1458272019769; Thu, 17 Mar 2016 20:33:39 -0700 (PDT) Received: from [10.1.9.199] ([103.23.18.15]) by smtp.gmail.com with ESMTPSA id z68sm16649069pfi.19.2016.03.17.20.33.36 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 20:33:38 -0700 (PDT) To: v6ops@ietf.org References: <56E60B0D.6070600@gmail.com> <56E6326B.2090303@gmail.com> <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.1040904@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56EB7719.7050903@gmail.com> Date: Fri, 18 Mar 2016 16:33:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 03:33:42 -0000 On 18/03/2016 02:42, Lorenzo Colitti wrote: ... > As regards hashing: traversing the whole length of the extension header > chain only to provide flow-based hashing is a bad use of processing power. > (If it's implemented in hardware, it's might also be a bad use of die > space, enercy, customer money, etc.) Using the flow label is much better. > So perhaps we should recommend that if hosts emit packets with extension > headers, they should also randomize the flowlabel. We did: Proposed Standard RFC 6437 in 2011. We also recommended that middleboxes should correctly process extension headers: Proposed Standard RFC 7045 in 2013. We have forbidden too-long header chains: RFC 7112 in 2014. We're fixing the requirements for hop-by-hop options in 6man. I see this draft (and the one on the IESG ballot) as being operational commentaries on the consequences of those RFCs being ignored. Brian From nobody Fri Mar 18 05:00:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FCA12D641 for ; Fri, 18 Mar 2016 05:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh0Hy3lftlIC for ; Fri, 18 Mar 2016 05:00:34 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31CF12D514 for ; Fri, 18 Mar 2016 05:00:33 -0700 (PDT) Received: from [172.20.15.144] (port-213-160-6-163.static.qsc.de [213.160.6.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 692EB801C6; Fri, 18 Mar 2016 13:00:28 +0100 (CET) To: Lorenzo Colitti , joel jaeggli References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <8e822f51-fc8c-8dc4-bb38-f089a6e7742a@bogus.com> From: Fernando Gont Message-ID: <56EBBC7E.8060602@si6networks.com> Date: Fri, 18 Mar 2016 05:29:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 12:00:37 -0000 On 03/17/2016 09:10 PM, Lorenzo Colitti wrote: > On Fri, Mar 18, 2016 at 6:53 AM, joel jaeggli > wrote: > > > how is this "problem" any different from: > > - "unknown" L4 header > > unknown is rather different than unfound if you're actually attempting > to parse the header chain. you still have a binary decision to make with > respect to forwarding or not. > > From the point of view of security, I don't see a difference. Not found > should be treated as unknown anyway. Dropping as a result of unfound is unintended effect. That's the point. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Mar 18 05:20:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED99612D51B for ; Fri, 18 Mar 2016 05:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9oiBUxjXmKs for ; Fri, 18 Mar 2016 05:20:52 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A24312D681 for ; Fri, 18 Mar 2016 05:20:24 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id m126so112283813ywd.0 for ; Fri, 18 Mar 2016 05:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JPPTIsE1iVgTijwmX2CcLU4qBHAFpKybg3v6FxrpNn4=; b=XmW8bv2lrr2W7/kibdR643MAChlxllthqK07JbGetcDplYBrLOqJMc+eDlXGTUNPiG F0LDBfqzXCAphEMsyw/+kuMTbUcMKcli2vFJWlQuaBWQwXV1CapX3DYMk4Itxc3fez98 dtkB+tjD2FrtygW9iuffnBZsvolre4RPRYbmYgDB6NQXuldNPpQRMALCcu6mMjXlyPTP w5o5pHb0gJq9ieLR8Yken56YJDN8UwyEyqnXKggiza+iEq/B9Fr1N2nFCWl/eJOMBBEI 9Ex7FMQk3p6hR6QQ8bbAY2CVHt91KcFTo9uIUVl72nWwnkbpNoYln28wFHa1QUfvZZCc 533A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JPPTIsE1iVgTijwmX2CcLU4qBHAFpKybg3v6FxrpNn4=; b=YedTghiMvVMemfOyrxR9bOL9Sptmvmv+DEUo5OpUWJU9ti2IC929+AHNt3C7C5gaCH HEYrYoKrXD39YLSuJoK1hDz0DqyINuy/kADEQ0jOnZHgkBr/KRK/nlPZfyzGUQabgk1H U+ZROHur/7eqAgypBscQbzKn2Jnh+o5390sFQ6lRWpJuI4/jjJuKuiieVdy1XlcPi6Tq abIArw6on3HxYFjJdeKiGAoPhQa8iphS90cvokM2pNQIP30upF/MybiaRpX2qSrF76kF JBLE9qCLyjNOtebbUZsR7RGKk+5cErxXgx/b7YifqH4EUx8E9UkXjjQWc1jBCrDYFfxS 1gZw== X-Gm-Message-State: AD7BkJISSbNn+awJmRkyeMbB21o5rX7XlHANXRe0znzuFePCN6j6a+veBcdroA/j+Ahovj2sc14+XrxYXImvw7N6 X-Received: by 10.13.214.1 with SMTP id y1mr6486575ywd.307.1458303623486; Fri, 18 Mar 2016 05:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.19.65 with HTTP; Fri, 18 Mar 2016 05:20:03 -0700 (PDT) In-Reply-To: <56EBBC7E.8060602@si6networks.com> References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <8e822f51-fc8c-8dc4-bb38-f089a6e7742a@bogus.com> <56EBBC7E.8060602@si6networks.com> From: Lorenzo Colitti Date: Fri, 18 Mar 2016 21:20:03 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=94eb2c0770e4745984052e51c554 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 12:20:56 -0000 --94eb2c0770e4745984052e51c554 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 18, 2016 at 5:29 PM, Fernando Gont wrote: > > From the point of view of security, I don't see a difference. Not found > > should be treated as unknown anyway. > > Dropping as a result of unfound is unintended effect. That's the point. I don't think that's a useful argument. If you don't know what you're doing, everything is unintended. I think we should assume that network administrators know that EHs exist and that they are making explicit decisions on whether to filter them or not, based on the capabilities of their hardware. If an admin configures a policy that says "from next-header tcp" and doesn't care to check the documentation as to whether that means "the next header after the IPv6 header is TCP" or "the last header in the chain is TCP"... well, they get what they deserve No different from someone who writes a policy that says "allow port 80" to protect a webserver and is surprised when anyone can talk to any port on the webserver by sending packets with a source port of 80. --94eb2c0770e4745984052e51c554 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 18, 2016 at 5:29 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
> From the point of view of = security, I don't see a difference. Not found
> should be treated as unknown anyway.

Dropping as a result of unfound is unintended effect. That's the= point.

I don't think that's a usef= ul argument. If you don't know what you're doing, everything is uni= ntended.

I think we should assume that network= administrators know that EHs exist and that they are making explicit decis= ions on whether to filter them or not, based on the capabilities of their h= ardware.

If an admin configures a policy that = says "from next-header tcp" and doesn't care to check the doc= umentation as to whether that means "the next header after the IPv6 he= ader is TCP" or "the last header in the chain is TCP"... wel= l, they get what they deserve

No different from so= meone who writes a policy that says "allow port 80" to protect a = webserver and is surprised when anyone can talk to any port on the webserve= r by sending packets with a source port of 80.
--94eb2c0770e4745984052e51c554-- From nobody Fri Mar 18 06:36:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DDF12D8AE for ; Fri, 18 Mar 2016 06:36:32 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfgR3-Wrqb2w for ; Fri, 18 Mar 2016 06:36:30 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F50F12D81F for ; Fri, 18 Mar 2016 06:36:26 -0700 (PDT) Received: from [172.20.15.144] (port-213-160-6-163.static.qsc.de [213.160.6.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id DBDF38045E; Fri, 18 Mar 2016 14:36:23 +0100 (CET) To: Lorenzo Colitti References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E9A16B.4030605@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <8e822f51-fc8c-8dc4-bb38-f089a6e7742a@bogus.com> <56EBBC7E.8060602@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56EC0298.5010708@si6networks.com> Date: Fri, 18 Mar 2016 10:28:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 13:36:34 -0000 On 03/18/2016 09:20 AM, Lorenzo Colitti wrote: > On Fri, Mar 18, 2016 at 5:29 PM, Fernando Gont > wrote: > > > From the point of view of security, I don't see a difference. Not found > > should be treated as unknown anyway. > > Dropping as a result of unfound is unintended effect. That's the point. > > I don't think that's a useful argument. If you don't know what you're > doing, everything is unintended. > > I think we should assume that network administrators know that EHs exist > and that they are making explicit decisions on whether to filter them or > not, based on the capabilities of their hardware. Isn't that the point we're making in our document?? > If an admin configures a policy that says "from next-header tcp" and > doesn't care to check the documentation as to whether that means "the > next header after the IPv6 header is TCP" or "the last header in the > chain is TCP"... well, they get what they deserve This is not what we're saying in the I-D. What we are saying is that, based on the usual capabilities of routers, a guy does now what he is doing and that has read the documentation, cannot do what he's meaning to do. Hence he has to resort to dropping packets that he's not really meaning to drop. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Mar 18 08:59:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F8312D6B0 for ; Fri, 18 Mar 2016 08:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbHjrkbQ4f_z for ; Fri, 18 Mar 2016 08:59:29 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972B312D56F for ; Fri, 18 Mar 2016 08:59:29 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2IFxGLt059075 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2016 15:59:16 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org Message-ID: <56EC25D2.2090101@foobar.org> Date: Fri, 18 Mar 2016 15:59:14 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <56EB2630.2020208@foobar.org> <9B901C5C-6BD1-4EFE-B448-AFFE9E07F972@cisco.com> In-Reply-To: <9B901C5C-6BD1-4EFE-B448-AFFE9E07F972@cisco.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 15:59:32 -0000 Fred Baker (fred) wrote: > In there first statement, you assert that we're looking at a protocol > problem. We may be, but that's not obvious to me. for non-trivial EH chains, most people seem to be acknowledging that start-to-end EH chain walking is too difficult for vendors to implement in silicon and is too expensive to handle in software. Vendors could implement it, but the cost-to-return ratio doesn't work. If the ietf designs a protocol which is too difficult / expensive for vendors to implement or where the cost-to-return doesn't work, then the problem lies with the protocol definition, not with the vendors' lack of inclination to implement it. > There is an issue > with HBH headers, or at least with their implementation, which we are > looking at in draft-ietf-6man-hbh-header-handling. hbh is a separate issue and we should probably park that for this discussion. > Nalini Elkins has > a problem with the lack of a counterpart to the IPv4 ident field, > which she wants to address with a Destination Option in > draft-ietf-ippm-6man-pdm-option. Several folks have issues with > fragmentation and reassembly (draft-bonica-6man-frag-deprecate), but > that is more about security policy and perceived application designer > laziness than about issues with the header; it in fact fragments and > reassembles if used for that purpose, and AFAIK is widely > implemented. The ipv6-ehs-in-real-world draft notes that if you attach a fragmentation extension header to a packet, it stands a good chance of being dropped on the floor. Protocols don't work when they are dropped by the network. This matters for frags / ipsec. > You go on to say that IPv6 Extension Headers implement core > functionality. I'll agree that the Security Header is core; I go to > work using one of a couple of VPN technologies, and packet layer > encryption is central to both. I'm hard pressed to say that the other > headers are core; ipsec and fragmentation are the two EHs that concern me. Other people may have other opinions. Personally, I see no future for either RH or HBH headers, but that is a personal opinion. > some different processing algorithm". The only one we have deprecated > is RH0, and even there, the issue isn't that RH0 can't be used to > implement what in IPv4 we would call a Loose Source Route and Record; > it's that even in IPv4 we decided that having that option was a > security nightmare. agreed. IPv4 options stopped working in the mid 90s but no-one noticed because they didn't do anything very important. The result is that there is plenty of silicon being sold today which is unable to forward packets with ipv4 options, and no-one cares. > If we're looking at a protocol problem, we should be able to describe > proposed changes to the protocol to fix it. I'm not hearing such > things described, apart from draft-wkumari-long-headers. > > Is the issue addressed in draft-wkumari-long-headers what we're > talking about? If so, can we discard the bluster in tone and say > that? Is there another issue? Can we describe it? The draft deliberately avoids prescription of a fix. First, there are a lot of people in this WG claiming that there isn't a problem in the first place and second, the authors want to try to get consensus that there is a problem before prescribing a fix. The authors have discussed this offline and feel that if the WG came to a consensus that there is a problem, that it would be better to poll the WG about potential fixes or workarounds. Personally, I think there is a problem and that the problem could be helped in the long term by drastically reining in the EH chain limits prescribed in 7112 (namely, 1280 bytes). If there are minimum acceptable limits imposed, then the obvious choices would either to limit by the number of headers or the number of octets used for headers. The latter would be much simpler to implement. Gaining consensus on a reasonable value for either would be very difficult because the IETF has a long history of having difficulties settling on what are ultimately arbitrary numbers. From a practical point of view, vendor input might be advisable, but I fear this is bikeshed territory. draft-wkumari-long-headers discourages EHs completely. Personally, I don't think this is workable because of ipsec / fragmentation requirements. draft-zhang-6man-offset-option is also not ideal. From a technical point of view, it is difficult to implement due to packet lookahead limitations in silicon. Also the IPR statement allows retaliatory infringement action, which some people may have issues with. Nick From nobody Fri Mar 18 11:34:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1F712D76A for ; Fri, 18 Mar 2016 11:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqh5F19O2Jv2 for ; Fri, 18 Mar 2016 11:34:44 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C08212D73C for ; Fri, 18 Mar 2016 11:34:44 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 3C11FD7887; Fri, 18 Mar 2016 11:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=WX/QaQ2j/nSEfikjGEoReWv5sQI=; b= mqGNN5QoCw3wQfIETD4duJBI0wif4P8AKajarhRh4+pkcE8/ZWXIklnFKsrk3uRm IIQ64fpvCZzWnJlexfadOEQIuB7bEY1iFUhQeOU8Cklgr1TFw015t1OnOO3pyW6z 09pNxqnBudD4yqUhpKFcpp6WNz8opI8kkwhCzy/ti9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=P0eby732mbJaDFuXAbz3Rv+sOH BQzdU8K56XXurS7AZBy2Zbt5TFNzuKlEHagcVMjd5Oyc9D/Z0NIUv6Q/Xd5VDqn7 LdnsuqXeY7qdnwxtiZxQqWPUjfzn+T/SxRSCQJJEDwtnITJ9JZTOrcAhx2jhy4S/ hX5rumWU/YCmX8i/A= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id AF7AFD7884; Fri, 18 Mar 2016 11:34:41 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 87A3D12D24BD; Fri, 18 Mar 2016 19:34:39 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6AAFB065-2937-42F6-A5B6-947368874C65"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56EC25D2.2090101@foobar.org> Date: Fri, 18 Mar 2016 19:34:38 +0100 Message-Id: <7AD49A5B-B449-408B-A8E5-B2983E01E259@employees.org> References: <56E6FC18.1060304@foobar.org> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <56EB2630.2020208@foobar.org> <9B901C5C-6BD1-4EFE-B448-AFFE9E07F972@cisco.com> <56EC25D2. 2090101@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 18:34:46 -0000 --Apple-Mail=_6AAFB065-2937-42F6-A5B6-947368874C65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Nick, > The ipv6-ehs-in-real-world draft notes that if you attach a > fragmentation extension header to a packet, it stands a good chance of > being dropped on the floor. Protocols don't work when they are = dropped > by the network. This matters for frags / ipsec. Fragment drop probability is not significantly different between IPv6 = and IPv4. https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters "We measure that about 8.5% to 9% of RIPE Atlas probes have problems = with fragmentation in IPv4, and 10% of probes have fragmentation = problems in IPv6. The IPv6 number agrees with a study that was performed = by NLNetLabs in 2012, at which point the number of deployed RIPE Atlas = probes was considerably smaller then now. In the meantime NLNetLabs have = resumed their work on fragmentation, and the RIPE NCC is closely = cooperating with this effort to better inform the Internet operations = and research communities on this issue." Which might be more of an argument against fragmentation at the network = layer than EHs in particular. Best regards, Ole --Apple-Mail=_6AAFB065-2937-42F6-A5B6-947368874C65 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW7Eo/AAoJEL7aWKiYQt92bXoQAIo84yDMKxWCWD7R6zpV7Env qachLMOy5PfR5xrfbbZcPNM0o7pCDKVd+zziWbIzU4m53nz5b+DWrbaVfL0SAfR1 DL7jDRE+pxa0DeenMx/f7EkzJg5z/US0jy1Ui4i8ZTLhd+ymJuuSZMasXutR6b9+ c59rzW7p/yejQiUq7v/KsgzNXoA+gkR1Ab4/PIbdAG3Ki/ZVm0bqkW1w6za0mgUh 9iYWoxV5EX70bT1WmcDQ+dZA2YTZ1QZq0dHSX3WYYp5fDL2pk8tLcHqV5K4Dc075 QvXBl2Oq7liGBv5c5Y8EJavnt6/RYHu3s4AxwVMY/t6Wd66REhN7ipYrA09oL7/q LjG7DhrV5LtBj5LNJUnbwfuAp47NJfAKLBunaClo+ZjZOcK2jZftW2fHZKF0lZJo 2bEblsvrdX3KyHjx7/xQWW9e5JfgDxy09dpQ7eZBFS8f6lFdCCm5FIGhXOW2KtA1 kE8fYuJbCG6D8U1kLU8VEK4hEAC4Rq1pF/WZZMizNAESUXb62J1qmiP27mVUPhdP 6Z7G1Fg2J28KjuEpHFpEU5y3kuj87VnbSoxhB2V/cdKg7JkzTko5c4uQXd6SVjFs h27HyQXkQTN1DLLiCsl9IrzDyrwoJZKIBrmpLXc8YDWCHumxmzOf37f86QGZghFD uNFXr227rOFc7s7De4to =b82F -----END PGP SIGNATURE----- --Apple-Mail=_6AAFB065-2937-42F6-A5B6-947368874C65-- From nobody Sat Mar 19 05:46:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD7012D7BB for ; Sat, 19 Mar 2016 05:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z66PtZArUc3l for ; Sat, 19 Mar 2016 05:46:25 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9C12D7AD for ; Sat, 19 Mar 2016 05:46:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3B3AB402E8; Sat, 19 Mar 2016 13:46:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7cbjKJIuX9L; Sat, 19 Mar 2016 13:46:21 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 1210B40170; Sat, 19 Mar 2016 13:46:21 +0100 (CET) Message-ID: <56ED4A1B.50905@globis.net> Date: Sat, 19 Mar 2016 13:46:19 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mark Smith References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> <6B813E27-F848-44DD-A504-C465AE196127@employees.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090005000200030307090303" Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 12:46:28 -0000 This is a multi-part message in MIME format. --------------090005000200030307090303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mark Smith wrote: > Hi Ole, > > > On 14 Mar 2016 07:34, wrote: >> Mark, >> >>>>> Have some questions from MLD Snooping switch point of view. >>>>> >>>>> If there are no Routers involved, it is Snooping switch responsibility to send MLD Query to keep the groups alive on the switch. >>>>> What is the correct correct Source IP to use for General Queries ? Is it Src IP all 0 or some link-local Address ? Which host stack would like/accept what Source IP ? Have observed different observations with different host stacks. >>>> see rfc4541. >>>> >>>>> Also, per discussion below - what is the right behavior for snooping switch when it comes to link-local multicast groups - flood or snoop ? It would be good to have a standard practice for this. >>>> it depends on the platform and how big forwarding table your switch can handle. >>>> as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.) >>>> >>> And I think the people complaining about MLD for LL groups may then complain when their hosts start receiving too many multicasts because they're flooded. >>> >>> I'd like to know more about these sorts of issues. What specific resource is being exhausted in the switch? TCAM? How many hosts are attached to the link - I'm wondering if, as a /64 effectively provides no limits at layer 3, people are now expecting to attach many more hosts to a link than they would and have with IPv4. >> with IPv6 it isn't the number of hosts connected, it is the number of addresses used. >> (and it is sometimes quite hard in IPv6 to know which addresses are still active). >> > > I realise that. > > In IPv4, addresses to hosts on a link has been 1:1 in nearly all > cases, and in my experience, most IPv4 subnets have been /24s (usually > facilitated by the big address space of RFC1918, and most likely for > the convenience of having an easy to work with subnet/host boundary). > So the size of most IPv4 networks has been commonly limited to no more > than ~250 hosts, which I think would have made it very unlikely that > those networks would encounter any layer 2 constraints other than > unicast bandwidth. Actually some older readers will recognise another more onerous limit to (IPv4) subnet size from the time before switches were invented: the (in)ability of end nodes to cope with incessant broadcast traffic such as ARP interrupting the main processor, which is why we ended up with ND, LL multicast group membership, and MLD in the first place. > As IPv6 /64s lifts that ~250 host self imposed limitation, I think > we'll now experience a time and maybe are already experiencing a time > where people who don't have any other experience than > IPv4/RFC1918s/switched networks will now discover what the actual > practical limits of the number of hosts they can attach to their links > are when they deploy IPv6, and these practical limits won't always be > unicast capacity. > >> it is all about carving of TCAM space. > Indeed: We've just moved the limit on L3 addresses/link somewhere else. You still need to be able to map L3 address on this prefix -> port + MAC in hardware. So it's always going to be a balance. More TCAM and/or more multicast groups in the switch = more complexity and $$ in switching and simpler end nodes. Less TCAM and/or less multicast groups in the switch = less complexity and $$ in switching, but end nodes that have to deal with more multicast or broadcast traffic when the switch moves into "all-port flooding" mode. Note: The number of multicast filters supported in hardware on (end host) NIC cards is also strictly limited. Once this limit is exceeded the card would also typically go into promiscuous mode, and thus interrupt the main CPU for packet processing. See for example this (randomly chosen) NIC data sheet from an Internet search: http://www.intel.nl/content/dam/www/public/us/en/documents/datasheets/ethernet-x540-datasheet.pdf One example quoted there has as few as 16 filters for both unicast and multicast. Others 128. So if you're using excessive numbers of unicast privacy addresses concurrently (e.g. due to many long-lived sessions), the NIC on the end host may run out of hardware filters. However, many NICs (including above) use input hashes in front of the hardware filters to attempt to reduce the impact of too many (multicast) filters. http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf So it might be thought to be advantageous when implementing privacy addressing to minimise the number of multicast groups concurrently in use for each end node/NIC, to preserve switch TCAM or NIC multicast filters performance in hardware, whilst still maintaining a wide "enough spread" to confuse listeners. But then again, 3rd party / off-link listeners could also infer a relationship between 2 apparently unrelated privacy addresses, based on computing the relevant IPv6 multicast group or NIC filter hashes remotely if they can guess the hardware ...... It's a utopia to think that any currently affordable hardware can cope with a full 64 bits of address space when filtering/forwarding. >> see e.g. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-x-series-switches/data_sheet_c78-584733.html?cachemode=fresh >> look for "scalability numbers" >> > > So I think the scalability section shows that these layer 3 inspection > functions in a layer 2 device have been optimised for IPv4, as the > number of IGMP groups and multicast routes doesn't change for any of > the modes, despite the number of unicast related capacities changing > across all the modes, and the Unicast MAC addresses capacity tripling > between the Access and VLAN modes. > > IPv4 and IPv6 are obviously different enough that IPv4 focussed > optimisations aren't necessarily going to work or work as well with > IPv6. I think over time we'll see IPv6 focussed optimisations in > switches as the protocol becomes more widely deployed (perhaps a > software update to the above switch could make the IGMP groups and > multicast routes capacity change too for the different modes?) > > > Regards, > Mark. > > >> I would assume this is a quite typical switch. >> >> cheers, >> Ole > > -- regards, RayH --------------090005000200030307090303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Mark Smith wrote:
Hi Ole,


On 14 Mar 2016 07:34, <otroan@employees.org> wrote:

Mark,


Have some questions from MLD Snooping switch point of view.

If there are no Routers involved, it is Snooping switch responsibility to send MLD Query to keep the groups alive on the switch.
What is the correct correct Source IP to use for General Queries ? Is it Src IP all 0 or some link-local Address ? Which host stack would like/accept what Source IP ? Have observed different observations with different host stacks.

see rfc4541.


Also, per discussion below - what is the right behavior for snooping switch when it comes to link-local multicast groups - flood or snoop ? It would be good to have a standard practice for this.

it depends on the platform and how big forwarding table your switch can handle.
as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.)


And I think the people complaining about MLD for LL groups may then complain when their hosts start receiving too many multicasts because they're flooded.

I'd like to know more about these sorts of issues. What specific resource is being exhausted in the switch? TCAM? How many hosts are attached to the link - I'm wondering if, as a /64 effectively provides no limits at layer 3, people are now expecting to attach many more hosts to a link than they would and have with IPv4.

with IPv6 it isn't the number of hosts connected, it is the number of addresses used.
(and it is sometimes quite hard in IPv6 to know which addresses are still active).



I realise that.

In IPv4, addresses to hosts on a link has been 1:1 in nearly all
cases, and in my experience, most IPv4 subnets have been /24s (usually
facilitated by the big address space of RFC1918, and most likely for
the convenience of having an easy to work with subnet/host boundary).
So the size of most IPv4 networks has been commonly limited to no more
than ~250 hosts, which I think would have made it very unlikely that
those networks would encounter any layer 2 constraints other than
unicast bandwidth.
Actually some older readers will recognise another more onerous limit to (IPv4) subnet size from the time before switches were invented: the (in)ability of end nodes to cope with incessant broadcast traffic such as ARP interrupting the main processor, which is why we ended up with ND, LL multicast group membership, and MLD in the first place.
 
As IPv6 /64s lifts that ~250 host self imposed limitation, I think
we'll now experience a time and maybe are already experiencing a time
where people who don't have any other experience than
IPv4/RFC1918s/switched networks will now discover what the actual
practical limits of the number of hosts they can attach to their links
are when they deploy IPv6, and these practical limits won't always be
unicast capacity.


it is all about carving of TCAM space.
Indeed: We've just moved the limit on L3 addresses/link somewhere else.

You still need to be able to map L3 address on this prefix -> port + MAC in hardware.

So it's always going to be a balance.

More TCAM and/or more multicast groups in the switch = more complexity and $$ in switching and simpler end nodes.

Less TCAM and/or less multicast groups in the switch = less complexity and $$ in switching, but end nodes that have to deal with more multicast or broadcast traffic when the switch moves into "all-port flooding" mode.

Note: The number of multicast filters supported in hardware on (end host) NIC cards is also strictly limited.

Once this limit is exceeded the card would also typically go into promiscuous mode, and thus interrupt the main CPU for packet processing.

See for example this (randomly chosen) NIC data sheet from an Internet search:
http://www.intel.nl/content/dam/www/public/us/en/documents/datasheets/ethernet-x540-datasheet.pdf

One example quoted there has as few as 16 filters for both unicast and multicast. Others 128. So if you're using excessive numbers of unicast privacy addresses concurrently (e.g. due to many long-lived sessions), the NIC on the end host may run out of hardware filters.

However, many NICs (including above) use input hashes in front of the hardware filters to attempt to reduce the impact of too many (multicast) filters. http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf

So it might be thought to be advantageous when implementing privacy addressing to minimise the number of multicast groups concurrently in use for each end node/NIC, to preserve switch TCAM or NIC multicast filters performance in hardware, whilst still maintaining a wide "enough spread" to confuse listeners.

But then again, 3rd party / off-link listeners could also infer a relationship between 2 apparently unrelated privacy addresses, based on computing the relevant IPv6 multicast group or NIC filter hashes remotely if they can guess the hardware ......

It's a utopia to think that any currently affordable hardware can cope with a full 64 bits of address space when filtering/forwarding.
see e.g. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-x-series-switches/data_sheet_c78-584733.html?cachemode=fresh
look for "scalability numbers"



So I think the scalability section shows that these layer 3 inspection
functions in a layer 2 device have been optimised for IPv4, as the
number of IGMP groups and multicast routes doesn't change for any of
the modes, despite the number of unicast related capacities changing
across all the modes, and the Unicast MAC addresses capacity tripling
between the Access and VLAN modes.

IPv4 and IPv6 are obviously different enough that IPv4 focussed
optimisations aren't necessarily going to work or work as well with
IPv6. I think over time we'll see IPv6 focussed optimisations in
switches as the protocol becomes more widely deployed (perhaps a
software update to the above switch could make the IGMP groups and
multicast routes capacity change too for the different modes?)


Regards,
Mark.



I would assume this is a quite typical switch.

cheers,
Ole

--
regards,
RayH
--------------090005000200030307090303-- From nobody Sat Mar 19 11:24:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AD412D573 for ; Sat, 19 Mar 2016 11:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ISLqiOu0bqc for ; Sat, 19 Mar 2016 11:24:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EA112D1E5 for ; Sat, 19 Mar 2016 11:24:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2JINxYf003361; Sat, 19 Mar 2016 19:23:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5408E203AD3; Sat, 19 Mar 2016 19:24:42 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 48544200F83; Sat, 19 Mar 2016 19:24:42 +0100 (CET) Received: from [132.166.84.30] ([132.166.84.30]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2JINwE7014353; Sat, 19 Mar 2016 19:23:58 +0100 To: Hermin Anggawijaya References: From: Alexandre Petrescu Message-ID: <56ED993E.6000000@gmail.com> Date: Sat, 19 Mar 2016 19:23:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 18:24:04 -0000 Le 17/03/2016 22:36, Hermin Anggawijaya a écrit : > Hi, > > On Tue, Mar 15, 2016 at 5:30 AM, Alexandre Petrescu > > wrote: > > Hi, > > Let me take advantage of this discussion to discuss the necessity of > this join. > > Le 03/03/2016 03:29, Hermin Anggawijaya a écrit : > > > On Linux, the IPv6 stack will generate MLD report (both unsolicited > report and as reply to queries) if a socket is set with > IPV6_ADD_MEMBERSHIP or IPV6_JOIN_GROUP for the given IPv6 multicast > address. > > > I think linux does REPORT even though the user does not specifically > open a socket with these parameters. Wireshark on a vanilla linux will > expose those MLD messages on LL scope. > > > > Linux only automatically generates MLD reports on multicast capable > interfaces for 'all-nodes' > and 'all-routers' groups (if it's forwarding), with interface, > link-local, site-local scopes. I agree. But still, this constitutes "noise" in some environments. Consider a wireless setting where the link is ephemeral: exists for maybe 10 seconds average. During these 10 seconds only utmost important messages must be sent to avoid collisions, packet loss and retransmissions. Two routers present on an ephemeral link do not really need to join the link-scoped group. They already advertise their presence using Router Advertisements and that contains their respective link-local address. Alex > > For other groups, ADD_MEMBERSHIP or JOIN_GROUP needs to be set on the > socket before report is generated. > > > Kind regards > > Angga > > > A question that could be raised is on the necessity of this message. > > On one hand, it is good for a desktop PC to inform the office switch > that it needs to be part of that group. It helps channelling messages. > > But when there are only Hosts on that link, the message is still issued > even though all Hosts must be subscribed to the LL group anyways, by > definition of the LL scope. > > This may have some significance in particular mobility settings where > the medium must be free as much as possible of what could be considered > noise. In vehicular networks the 802.11-OCB (aka 802.11p) is stripped > off of all link-layer messages like 802.11 beacons/assn/auth in order to > keep the medium as silent as possible, yet the IP MLD LL messages are > there. These could be considered to be superfluous. But of course the > MLD REPORTS for wider than LL scope are still needed in vehicular > networks. > > Alex > > And looks like the Python script should do the job. > > Having seen an MLD report from a host running the Python script, I > would have thought that the LAN switch would make the host (or the > switch port the host is connected to) to become a member of the > multicast group, and the switch should forward all multicast packets > for ff02::114. > > *If the corresponding multicast packets (ff02::114) are indeed > filtered by MLD snooping switch* - despite seeing the membership > report sent by the host running the script, then on some switches > you could try either (depends on availability of features): > > 1. disable snooping - but this could make the LAN 'chatty' 2. set > the default behaviour for unknown multicast address to flood, then > apply a filter on the MLDSnooping module so that it never 'learns' > ff02::114, thus keeping ff02::114 as unknown multicast 3. add static > MLD snooping entry for ff02::114 and make all the ports in the vlan > as a member. 4. add ff02::114 as a 'protocol' address to MLD > Snooping so that it is flooded properly to 'router ports' like > ff02::6, ff02:6, ff02::9 etc. > > > Kind regards > > Angga > > From nobody Sat Mar 19 15:35:31 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6510E12D5EA; Thu, 17 Mar 2016 06:03:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317130356.3746.55282.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 06:03:56 -0700 Archived-At: X-Mailman-Approved-At: Sat, 19 Mar 2016 15:35:30 -0700 Cc: v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Subject: [v6ops] Alia Atlas' Abstain on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:03:56 -0000 Alia Atlas has entered the following ballot position for draft-ietf-v6ops-ipv6-ehs-in-real-world-02: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also agree with Alvaro. From nobody Sat Mar 19 17:53:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D916C12D583; Sat, 19 Mar 2016 17:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqYZKqb4aifx; Sat, 19 Mar 2016 17:53:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C1212D557; Sat, 19 Mar 2016 17:53:25 -0700 (PDT) Received: from mb-2.local (50-0-150-57.dsl.static.fusionbroadband.com [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u2K0rMju046913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 20 Mar 2016 00:53:23 GMT (envelope-from joelja@bogus.com) To: Alia Atlas , The IESG References: <20160317130356.3746.55282.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: Date: Sat, 19 Mar 2016 17:53:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160317130356.3746.55282.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OJWqDG6dPCu5Gaj3lgL55ONjnkedawQlH" Archived-At: Cc: draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Subject: Re: [v6ops] Alia Atlas' Abstain on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 00:53:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OJWqDG6dPCu5Gaj3lgL55ONjnkedawQlH Content-Type: multipart/mixed; boundary="U77tHwjQh5fTnmjRn44LwCOigEafIR7vM" From: joel jaeggli To: Alia Atlas , The IESG Cc: v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org Message-ID: Subject: Re: [v6ops] Alia Atlas' Abstain on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) References: <20160317130356.3746.55282.idtracker@ietfa.amsl.com> In-Reply-To: <20160317130356.3746.55282.idtracker@ietfa.amsl.com> --U77tHwjQh5fTnmjRn44LwCOigEafIR7vM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/17/16 6:03 AM, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-v6ops-ipv6-ehs-in-real-world-02: Abstain >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-worl= d/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I also agree with Alvaro. notwithstanding that the call has already occurred and I don't expect to change anyone's minds anyways I would direct attention to the current discussion of the follow-on draft in the v6ops working group . https://mailarchive.ietf.org/arch/search/?email_list=3Dv6ops&gbt=3D1&qdr=3D= w&q=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops the wide diversity of opinions there is very much why the measurement is purposefully neutral. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --U77tHwjQh5fTnmjRn44LwCOigEafIR7vM-- --OJWqDG6dPCu5Gaj3lgL55ONjnkedawQlH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbt9H0ACgkQ8AA1q7Z/VrKHWACfVR83X2kW6O69PXg5NSUNkHBd T/IAn2D3M2GJJHKX2GPAXWuDQYtKqpMp =RrDA -----END PGP SIGNATURE----- --OJWqDG6dPCu5Gaj3lgL55ONjnkedawQlH-- From nobody Sun Mar 20 23:09:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B81312D63B for ; Sun, 20 Mar 2016 23:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.522 X-Spam-Level: X-Spam-Status: No, score=-114.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5FYpQWg32kS for ; Sun, 20 Mar 2016 23:09:39 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAA712D55D for ; Sun, 20 Mar 2016 23:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2032; q=dns/txt; s=iport; t=1458540579; x=1459750179; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4NRiZSZAYYJ3cfuizMORCU2GbIhFGN0vzaMNVYCTzVQ=; b=Wcwineq0pjjHZqyR8rJn990nHPVtmwia4EP4ws5342RMGWU18ItHEx8M SK5yVH8cQmnSms00f4jhR9t8LVchgjpHKuDCU5YiKka6QzdTw8CKHezbV 2ga2usojdHlL4cahtb3BeE7ZrWAy8tR/wrDdc0NPhDK4u5Ps4zbpslA7v 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZAgCOj+9W/4MNJK1egzNTcga6Hg6Bb?= =?us-ascii?q?xcMhWoCgR44FAEBAQEBAQFkHAuEQQEBAQMBAQEBawsFCwIBCBguJwslAgQOBQ6?= =?us-ascii?q?IEQgOvhkBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASIEQiCSYdngisFl1cBgx2BZ?= =?us-ascii?q?m2IE48HjwUBHgFDg2VqAYkWfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,370,1454976000"; d="asc'?scan'208";a="250163647" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2016 06:09:38 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2L69cW2031905 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2016 06:09:38 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Mar 2016 01:09:37 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 21 Mar 2016 01:09:37 -0500 From: "Fred Baker (fred)" To: "draft-gont-v6ops-ipv6-ehs-packet-drops.all@tools.ietf.org" Thread-Topic: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRe3z+jjdZn/af1k6rS4wakEAZs59jzVQA Date: Mon, 21 Mar 2016 06:09:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_17B13578-1259-465A-B27A-B4D1D48F7B80"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 06:09:41 -0000 --Apple-Mail=_17B13578-1259-465A-B27A-B4D1D48F7B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii After a week's debate, with 13 people posting, I am hard pressed to say = that there is a consensus in support of the adoption of this draft. > On Mar 11, 2016, at 2:01 AM, Fred Baker (fred) wrote: >=20 > The authors of draft-gont-v6ops-ipv6-ehs-packet-drops would like v6ops = to adopt draft-gont-v6ops-ipv6-ehs-packet-drops as a working group = document. Yes or no? >=20 > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03 > = https://tools.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-dro= ps-03.txt > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_17B13578-1259-465A-B27A-B4D1D48F7B80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVu+QIEayAOS/EQ8MAQI2nxAAoiYBR7qpR2Fr+vJXsBhmexsfdaIYwi2j liESnfZ9C+QuVdVUTs4Ye9kdcN0EZxsckP7su8ZvspvSBpsVX16Cc+DTl21Ub4dY ylTSyXWlH7C9p/wJK/8ZjB3qaX54GuY2a4+ESoU4077bnZOaQMZxZ+2EC/tU+Rez vgmZVq1iWlCcWHZwNHKDWzGCmkZhvRXtul8vQuFUtSShYE0mjvMOwnf+4cDxzYUJ OO4KnmZCal0l/VevOsm2hcHO9zcIGtuJlqlLia20Ml+4JDkXWMw8aEbdJYtIgwLK 2Ra3KtPgRUea2soFpeBqiJwi5bdtoi8hcVIFFGRWijcE7bP5Q9+q2H77EIMR4zeS FkJB9uqJLWNWVHs/QJwIlzxKef4plp/EabCgi5bK+cu1YylHzp6m4mU0MGNaFLQl kC10mlNS6R8XBdWV1aNpNh09R8g6xUFWovA6fJJ8c7h0tNxmXXLdMDhc5NL3kAqs L5JZq4uaRrqTut0CpnQJDbD4h0S3K2beemhQWuw1RVMoIBF5vB8EUaz50IX/TTSz iFiwMW2rpvAjXN8q1OddH3tA2a/kvjzRI90gkmdgSjCZoC8yCiWLfkrs9RCYBa0J q76B/LjUnfi98dNs/Lw074f7IBdaMEOfJzbQzO5efwIk/D5toOxs15ZQrVap+6m7 7pEk+kelMjQ= =ce1s -----END PGP SIGNATURE----- --Apple-Mail=_17B13578-1259-465A-B27A-B4D1D48F7B80-- From nobody Mon Mar 21 06:14:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5384212D7BD for ; Mon, 21 Mar 2016 06:14:45 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNOzua2_81bD for ; Mon, 21 Mar 2016 06:14:43 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5232412D807 for ; Mon, 21 Mar 2016 06:14:43 -0700 (PDT) Received: from [192.168.1.16] (unknown [151.48.139.0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 81632801C7; Mon, 21 Mar 2016 14:14:37 +0100 (CET) To: otroan@employees.org, Nick Hilliard References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.504 0209@foobar.org> <56E9A16B.4030605@si6networks.com> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <56EB2630.2020208@foobar.org> <9B901C5C-6BD1-4EFE-B448-AFFE9E07F972@cisco.com> <56EC25D2. 2090101@foobar.org> <7AD49A5B-B449-408B-A8E5-B2983E01E259@employees.org> From: Fernando Gont Message-ID: <56EFE720.50100@si6networks.com> Date: Mon, 21 Mar 2016 13:20:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7AD49A5B-B449-408B-A8E5-B2983E01E259@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 13:14:45 -0000 On 03/18/2016 07:34 PM, otroan@employees.org wrote: > Nick, > >> The ipv6-ehs-in-real-world draft notes that if you attach a >> fragmentation extension header to a packet, it stands a good chance of >> being dropped on the floor. Protocols don't work when they are dropped >> by the network. This matters for frags / ipsec. > > Fragment drop probability is not significantly different between IPv6 and IPv4. > > https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters > "We measure that about 8.5% to 9% of RIPE Atlas probes have problems with fragmentation in IPv4, and 10% of probes have fragmentation problems in IPv6. The IPv6 number agrees with a study that was performed by NLNetLabs in 2012, at which point the number of deployed RIPE Atlas probes was considerably smaller then now. In the meantime NLNetLabs have resumed their work on fragmentation, and the RIPE NCC is closely cooperating with this effort to better inform the Internet operations and research communities on this issue." > > Which might be more of an argument against fragmentation at the network layer than EHs in particular. How do you explain the drop rate of all other EHs? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Mar 22 11:55:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CB912D70F for ; Tue, 22 Mar 2016 11:55:15 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7HPkGO0LdTd for ; Tue, 22 Mar 2016 11:55:14 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5E412D0E7 for ; Tue, 22 Mar 2016 11:55:14 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id y89so186959171qge.2 for ; Tue, 22 Mar 2016 11:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=3L2x2cZaHK03IFNDV9fATiSQUOsIuSXVrEr9KZn8ZvI=; b=rtebH50GUfUAmjrOHKDH6rOV1d3yzuj9Jrkw/12f1FGlRTZ8yJzIxWRSEdz7Hbs+4B 6i8yA84vLo0T87vVtnqqZn9QTEOTPZ1eViizS5DbHvSSpNiNqntrrF4YeGmSDS0DeOrX GQyTQeMJI4jc81kLoshAQ/BumVt8QvMhBkQS24fiMJFd+sJxWLOv7HJPKOl4V7ioI0dD QBoDSa3Sh2U+4i/JdHSfZmdv55FGr7ZZWy58mD0hCTt/8HTicfzSoVZVXFZbFgOlChwm SnZzhDVv+ZvNOF7cNkDmghwnxMv9VsiKvoVNiiYXGPst0JOtkt2ckXooUOvaxPlxdVUq 0tsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=3L2x2cZaHK03IFNDV9fATiSQUOsIuSXVrEr9KZn8ZvI=; b=QR8o/7n9HQ8DchYgL0o7F5xaw+qObgQFyn0IpsArSAMYlF+e9bbNLbq39boqeBzs8K JtobtG8/uq01ifrMfudk5xqQhId5QyU4x+NTqTTUsRhe3jIBVrkr2/sQrXkscFK5+Lnj FnhjewEJLZVrv8t6zB080G/gXTCfiGMFnNgT0MAtJ/i/3rDrNPhALbB5V+Fvo6UmBAV8 tk16zOIHok0ODPL0WgxUMYC5rdsWvKi5/jjylvgeyyn6twZEknIrsL5GSAE62KWc6ld2 22WUwNfqxylhtrnJHOaVDWj9a8ZuINcrDC/J+/VKkkvpB44G1XYv8eHOr1EtOv0cgazy +Dhw== X-Gm-Message-State: AD7BkJIb8EhG4swuQvXDHrVoBE6/dLlZsmxl9d9GW+l6TgPw2ZVSq1wCyMCjDFaSWz9DAA== X-Received: by 10.140.93.44 with SMTP id c41mr48661828qge.74.1458672913387; Tue, 22 Mar 2016 11:55:13 -0700 (PDT) Received: from ?IPv6:2001:13c7:7001:7000:cddd:f2c2:68ea:e901? ([2001:13c7:7001:7000:cddd:f2c2:68ea:e901]) by smtp.googlemail.com with ESMTPSA id p31sm3022775qkp.31.2016.03.22.11.55.12 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 11:55:12 -0700 (PDT) To: v6ops list From: "Carlos M. Martinez" Message-ID: <56F1950E.90001@gmail.com> Date: Tue, 22 Mar 2016 15:55:10 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] LACNIC - CAF Field Research on IPv6 Adoption in Latin America X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 18:55:16 -0000 Hello all, I'd like to share with this wg the result of a research project carried out by LACNIC with financing provided by Banco CAF (one of the development banks active in the Latin American region) The full report is here: http://portalipv6.lacnic.net/wp-content/caf-lacnic/CAF-LACNIC-IPv6-Deployment-Social-Economic-Development-in-LAC.pdf A shorter version is available at: http://portalipv6.lacnic.net/en/caf-lacnic/ Thank you! -Carlos From nobody Thu Mar 24 05:56:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5872C12D1DE for ; Thu, 24 Mar 2016 05:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fit.vutbr.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKUCQCf8TOF6 for ; Thu, 24 Mar 2016 05:56:18 -0700 (PDT) Received: from kazi.fit.vutbr.cz (kazi6.fit.vutbr.cz [IPv6:2001:67c:1220:808::93e5:80c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E05012D667 for ; Thu, 24 Mar 2016 05:56:14 -0700 (PDT) Received: from [147.229.14.193] (dhcpz193.fit.vutbr.cz [147.229.14.193]) (authenticated bits=0) by kazi.fit.vutbr.cz (8.15.2/8.15.2) with ESMTPSA id u2OCu8d8009401 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 13:56:10 +0100 (CET) To: carlos@lacnic.net, v6ops list References: <56F1950E.90001@gmail.com> From: =?UTF-8?B?TWF0xJtqIEdyw6lncg==?= X-Enigmail-Draft-Status: N1110 Message-ID: <56F3E3E6.5060403@fit.vutbr.cz> Date: Thu, 24 Mar 2016 13:56:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56F1950E.90001@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fit.vutbr.cz; h=subject:to:references:from:message-id:date:mime-version:in-reply-to:content-type:content-transfer-encoding; s=mx1; bh=/zysPUG3a/EoazaVviRMW+YXKHXJTDT3PKdX+GfOJ8A=; b=SgRtVdZOuugmmuvV/lYEcIp4GF9PPm3JGm15eJt6YNBkznhAXqbHhbH1tpjqlZro4b9gdFs8Q3p7Komsxv+w2cqS2lp24TV07vSN9qKoDbKvJxUhVUNyao008cnx5tl34Pu+us4ceIrmFywtZitlc8pZWBqtQBGHIZshYMzylzg= X-Scanned-By: MIMEDefang 2.78 on 147.229.8.12 Archived-At: Subject: Re: [v6ops] LACNIC - CAF Field Research on IPv6 Adoption in Latin America X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 12:56:21 -0000 On 03/22/2016 07:55 PM, Carlos M. Martinez wrote: > Hello all, > > I'd like to share with this wg the result of a research project carried > out by LACNIC with financing provided by Banco CAF (one of the > development banks active in the Latin American region) > > The full report is here: > http://portalipv6.lacnic.net/wp-content/caf-lacnic/CAF-LACNIC-IPv6-Deployment-Social-Economic-Development-in-LAC.pdf > > A shorter version is available at: > http://portalipv6.lacnic.net/en/caf-lacnic/ > It always amuses me that reports claiming that IPv6 is the best solution for future are shared on web pages with broken IPv6 [1]. At least, I have the old legacy protocol that I can use for downloading the report. :) Cheers, M. [1] The webpage with the report is not accessible over IPv6 for me. It timeouts on gw01.lacnic.registro.br (2001:12ff:1:3::212). From nobody Thu Mar 24 06:26:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E95812D16B for ; Thu, 24 Mar 2016 06:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB-IybK3shpx for ; Thu, 24 Mar 2016 06:26:11 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [200.7.84.8]) by ietfa.amsl.com (Postfix) with ESMTP id E8DDB12D14F for ; Thu, 24 Mar 2016 06:25:31 -0700 (PDT) Received: from hermes.lacnic.net.uy (localhost [127.0.0.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id 1A72016B407E4; Thu, 24 Mar 2016 10:18:34 -0300 (UYT) X-Virus-Scanned: amavisd-new at lacnic.net.uy Received: from mail.lacnic.net.uy ([127.0.0.1]) by hermes.lacnic.net.uy (mail.lacnic.net.uy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoIIHMkYrbs2; Thu, 24 Mar 2016 10:18:33 -0300 (UYT) Received: from oliver.local (unknown [IPv6:2800:af:a73d:a0e5:4146:2de3:1b37:bde5]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lacnic.net.uy (Postfix) with ESMTPSA id 9161316B407E9; Thu, 24 Mar 2016 10:18:33 -0300 (UYT) To: =?UTF-8?B?TWF0xJtqIEdyw6lncg==?= , v6ops list References: <56F1950E.90001@gmail.com> <56F3E3E6.5060403@fit.vutbr.cz> From: "Carlos M. Martinez" Message-ID: <56F3EAC9.8090309@lacnic.net> Date: Thu, 24 Mar 2016 10:25:29 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56F3E3E6.5060403@fit.vutbr.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] LACNIC - CAF Field Research on IPv6 Adoption in Latin America X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 13:26:14 -0000 Thanks for the heads up. This only shows that we all have still a lot of work to do. See you in a few days. Carlos On 3/24/16 9:56 AM, Matěj Grégr wrote: > On 03/22/2016 07:55 PM, Carlos M. Martinez wrote: >> Hello all, >> >> I'd like to share with this wg the result of a research project carried >> out by LACNIC with financing provided by Banco CAF (one of the >> development banks active in the Latin American region) >> >> The full report is here: >> http://portalipv6.lacnic.net/wp-content/caf-lacnic/CAF-LACNIC-IPv6-Deployment-Social-Economic-Development-in-LAC.pdf >> >> A shorter version is available at: >> http://portalipv6.lacnic.net/en/caf-lacnic/ >> > It always amuses me that reports claiming that IPv6 is the best solution > for future are shared on web pages with broken IPv6 [1]. At least, I > have the old legacy protocol that I can use for downloading the report. :) > > Cheers, > > M. > > [1] The webpage with the report is not accessible over IPv6 for me. It > timeouts on gw01.lacnic.registro.br (2001:12ff:1:3::212). From nobody Thu Mar 24 11:25:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8724A12D7E8 for ; Thu, 24 Mar 2016 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaER451e09rk for ; Thu, 24 Mar 2016 11:25:53 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B309B12D7E6 for ; Thu, 24 Mar 2016 11:25:53 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id m184so92974947iof.1 for ; Thu, 24 Mar 2016 11:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FXEKBUrWhEpYKgLI/MiKwe3hwbM7cJSe1yCZ66slWis=; b=RZ79o19RUOPwAgxlrFyr1JXYTHZE/iGRCCGNCeTtUZZtt4dUl7naYptE3OMWwqt3S5 BQp9lW/cbhgGJpvX3VyI4aSBstrLqlrTFFqQ9MpbOaFNX77rP6Orzk7OR34RQQS+F7DB eIxTuOytMoSszdcYfJIFOegR0zwnSH4Rx0Wo3NUt8XnzD4r4GoOlNJJhwlJsadZqxRLb nciBk0gOivwTMAFx9XL1ODzVy1Kf1W6G6iDJpnJRXmKMkD72dGmLiLKcdFA0FDx5qfjD ZoGLVjFV6lUzg0xee9P4e3UmNoOhwfzudXwKaU/byyHNmOqoIBmh1qrVqeLZi/ApG7af waSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FXEKBUrWhEpYKgLI/MiKwe3hwbM7cJSe1yCZ66slWis=; b=axRAsH7SUFb9oqlLn9n7cdxZtWNMoUZ4TK79pMN/CDft2yQUzUXd/3PlQFSmaWnReV ZjEaxEGQULcdmTdj6z5zjREueiaPomQkQnhbWxBwLyM+uG5K1tnpyw5CGw4TmIXyUpvB Gpc1JkKNrCdZmgsJUQ1t4nw+88BzHeAEZh/7yJxFMIhMSA6rJ8umu83mgaq3/Que7kPO 17NrcXpsLkB3JyubpHqqhweDjdQOeiTgU/JTZK7+DoBZnR8BtFeRKj2+V47KSbWK48D5 l+9ApQ6df0d1YJONSKCMmNuA1Jvke9TH+tg8OAuPl/V0Wta9s38RpypbbVTOrlp86VOf OlHg== X-Gm-Message-State: AD7BkJLJ2IbNTHMKOWhe2Kc7dbK7O73k26zX9r7FZh7WcYlv8pcasUuKiDJUzwN1+r6FcqqxF05Iv3TQUBqT6g== X-Received: by 10.107.132.18 with SMTP id g18mr11099488iod.47.1458843952971; Thu, 24 Mar 2016 11:25:52 -0700 (PDT) MIME-Version: 1.0 References: <56F1950E.90001@gmail.com> <56F3E3E6.5060403@fit.vutbr.cz> <56F3EAC9.8090309@lacnic.net> In-Reply-To: <56F3EAC9.8090309@lacnic.net> From: Arturo Servin Date: Thu, 24 Mar 2016 18:25:43 +0000 Message-ID: To: "Carlos M. Martinez" , =?UTF-8?B?TWF0xJtqIEdyw6lncg==?= , v6ops list Content-Type: multipart/alternative; boundary=001a113ecbe49986f2052ecf9365 Archived-At: Subject: Re: [v6ops] LACNIC - CAF Field Research on IPv6 Adoption in Latin America X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 18:25:56 -0000 --001a113ecbe49986f2052ecf9365 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It works for me: curl -6 -I http://portalipv6.lacnic.net/ HTTP/1.1 200 OK Date: Thu, 24 Mar 2016 18:21:11 GMT Server: Apache/2.4.17 (FreeBSD) PHP/5.6.14 X-Powered-By: PHP/5.6.14 Set-Cookie: _icl_current_language=3Des; expires=3DFri, 25-Mar-2016 18:21:11 GMT; Max-Age=3D86400; path=3D/ Set-Cookie: PHPSESSID=3Ddqevucd9f5h7poruq8l8t8i9m5; path=3D/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=3D0, pre-check=3D0 Pragma: no-cache Set-Cookie: _icl_current_language=3Des; expires=3DFri, 25-Mar-2016 18:21:11 GMT; Max-Age=3D86400; path=3D/ Link: ; rel=3D"https://api.w.org/" Content-Type: text/html; charset=3DUTF-8 Perhaps your ISP has broken connectivity in v6. How did you conclude that the document was in gw01.lacnic.registro.br? Regards .as On Thu, 24 Mar 2016 at 06:26 Carlos M. Martinez wrote: > Thanks for the heads up. This only shows that we all have still a lot of > work to do. > > See you in a few days. > > Carlos > > On 3/24/16 9:56 AM, Mat=C4=9Bj Gr=C3=A9gr wrote: > > On 03/22/2016 07:55 PM, Carlos M. Martinez wrote: > >> Hello all, > >> > >> I'd like to share with this wg the result of a research project carrie= d > >> out by LACNIC with financing provided by Banco CAF (one of the > >> development banks active in the Latin American region) > >> > >> The full report is here: > >> > http://portalipv6.lacnic.net/wp-content/caf-lacnic/CAF-LACNIC-IPv6-Deploy= ment-Social-Economic-Development-in-LAC.pdf > >> > >> A shorter version is available at: > >> http://portalipv6.lacnic.net/en/caf-lacnic/ > >> > > It always amuses me that reports claiming that IPv6 is the best solutio= n > > for future are shared on web pages with broken IPv6 [1]. At least, I > > have the old legacy protocol that I can use for downloading the report. > :) > > > > Cheers, > > > > M. > > > > [1] The webpage with the report is not accessible over IPv6 for me. It > > timeouts on gw01.lacnic.registro.br (2001:12ff:1:3::212). > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113ecbe49986f2052ecf9365 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It works for me:

curl -6 -I http://portalipv6.lacnic.net/

HTTP/1.1 200 OK

Date: Thu, 24 Mar 2016 18:21:11 GMT

Server: Apache/2.4.17 (FreeBSD) PHP/5.6.= 14

X-Powered-By: PHP/5.6.14

Set-Cookie: _icl_current_language=3Des; = expires=3DFri, 25-Mar-2016 18:21:11 GMT; Max-Age=3D86400; path=3D/

Set-Cookie: PHPSESSID=3Ddqevucd9f5h7poru= q8l8t8i9m5; path=3D/

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-= revalidate, post-check=3D0, pre-check=3D0

Pragma: no-cache

Set-Cookie: _icl_current_language=3Des; = expires=3DFri, 25-Mar-2016 18:21:11 GMT; Max-Age=3D86400; path=3D/

Link: <http://portalipv6.lacnic.net/wp-json/>; rel=3D&q= uot;https://api.w.org/"

Content-Type: text/html; charset=3DUTF-8=


Perhaps your ISP has broken connectivity in v6.=


How d= id you conclude that the document was in=C2=A0gw01.lacnic.registro.br?


<= /span>

Regards

.as


On Thu, 24 Mar 2016 at 06:26 Carlos M. Martinez <<= a href=3D"mailto:carlos@lacnic.net">carlos@lacnic.net> wrote:
Thanks for the heads up. This only shows = that we all have still a lot of
work to do.

See you in a few days.

Carlos

On 3/24/16 9:56 AM, Mat=C4=9Bj Gr=C3=A9gr wrote:
> On 03/22/2016 07:55 PM, Carlos M. Martinez wrote:
>> Hello all,
>>
>> I'd like to share with this wg the result of a research projec= t carried
>> out by LACNIC with financing provided by Banco CAF (one of the
>> development banks active in the Latin American region)
>>
>> The full report is here:
>> http://portalipv6.lacnic.net/wp-content/caf-lacnic= /CAF-LACNIC-IPv6-Deployment-Social-Economic-Development-in-LAC.pdf
>>
>> A shorter version is available at:
>> http://portalipv6.lacnic.net/en/caf-lacnic/<= br> >>
> It always amuses me that reports claiming that IPv6 is the best soluti= on
> for future are shared on web pages with broken IPv6 [1]. At least, I > have the old legacy protocol that I can use for downloading the report= . :)
>
> Cheers,
>
> M.
>
> [1] The webpage with the report is not accessible over IPv6 for me. It=
> timeouts on gw01.lacnic.registro.br (2001:12ff:1:3::212).

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a113ecbe49986f2052ecf9365-- From nobody Thu Mar 24 12:43:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAB312D4FF for ; Thu, 24 Mar 2016 12:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNHxSMPaI4JT for ; Thu, 24 Mar 2016 12:43:13 -0700 (PDT) Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA20A12D19D for ; Thu, 24 Mar 2016 12:43:08 -0700 (PDT) X-MDAV-Processed: mail.consulintel.com, Thu, 24 Mar 2016 20:43:04 +0100 Received: from [10.10.10.212] by mail.consulintel.com (MDaemon PRO v11.0.3) with ESMTP id md50000377180.msg for ; Thu, 24 Mar 2016 20:43:02 +0100 X-Spam-Processed: mail.consulintel.com, Thu, 24 Mar 2016 20:43:02 +0100 (not processed: spam filter heuristic analysis disabled) X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Return-Path: prvs=18911ef970=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Thu, 24 Mar 2016 20:43:01 +0100 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: Thread-Topic: [v6ops] LACNIC - CAF Field Research on IPv6 Adoption in Latin America References: <56F1950E.90001@gmail.com> <56F3E3E6.5060403@fit.vutbr.cz> In-Reply-To: <56F3E3E6.5060403@fit.vutbr.cz> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] LACNIC - CAF Field Research on IPv6 Adoption in Latin America X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 19:43:15 -0000 Works for me ! Actually is a very nice work, congratulations. Regards, Jordi -----Mensaje original----- De: v6ops en nombre de Mat=C4=9Bj Gr=C3=A9gr Responder a: Fecha: jueves, 24 de marzo de 2016, 13:56 Para: , v6ops list Asunto: Re: [v6ops] LACNIC - CAF Field Research on IPv6 Adoption in Latin A= merica >On 03/22/2016 07:55 PM, Carlos M. Martinez wrote: >> Hello all, >>=20 >> I'd like to share with this wg the result of a research project carried >> out by LACNIC with financing provided by Banco CAF (one of the >> development banks active in the Latin American region) >>=20 >> The full report is here: >> http://portalipv6.lacnic.net/wp-content/caf-lacnic/CAF-LACNIC-IPv6-Deplo= yment-Social-Economic-Development-in-LAC.pdf >>=20 >> A shorter version is available at: >> http://portalipv6.lacnic.net/en/caf-lacnic/ >>=20 > >It always amuses me that reports claiming that IPv6 is the best solution >for future are shared on web pages with broken IPv6 [1]. At least, I >have the old legacy protocol that I can use for downloading the report. :) > >Cheers, > >M. > >[1] The webpage with the report is not accessible over IPv6 for me. It >timeouts on gw01.lacnic.registro.br (2001:12ff:1:3::212). > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 24 15:32:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9C412D770 for ; Thu, 24 Mar 2016 15:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6QMuS0uPFiF for ; Thu, 24 Mar 2016 15:32:53 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [200.7.84.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2933B12D758 for ; Thu, 24 Mar 2016 15:32:53 -0700 (PDT) Received: from hermes.lacnic.net.uy (localhost [127.0.0.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id A8F8316B40AEB; Thu, 24 Mar 2016 19:25:53 -0300 (UYT) X-Virus-Scanned: amavisd-new at lacnic.net.uy Received: from mail.lacnic.net.uy ([127.0.0.1]) by hermes.lacnic.net.uy (mail.lacnic.net.uy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4f796XCDLqk; Thu, 24 Mar 2016 19:25:52 -0300 (UYT) Received: from [127.0.0.1] (ec2-54-175-189-205.compute-1.amazonaws.com [54.175.189.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lacnic.net.uy (Postfix) with ESMTPSA id E0A3816B40594; Thu, 24 Mar 2016 19:25:51 -0300 (UYT) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14588587674510.008272466249763966" From: Carlos Martinez To: Arturo Servin In-Reply-To: References: <56F1950E.90001@gmail.com> <56F3E3E6.5060403@fit.vutbr.cz> <56F3EAC9.8090309@lacnic.net> Date: Thu, 24 Mar 2016 19:32:42 -0300 X-Cm-Message-Id: 14588587673258165cebce967c8e4d1a928f2e554a2d451756f46b0f4f9671536621451 X-Cm-Draft-Id: WyJhIiw1LCJkcmFmdF9pZCIsMTQ1ODg1ODc2MjIyNywidiIsMV0= X-Mailer: CloudMagic Message-Id: <1458858769079-d7b231eb-d9398f9d-525d138d@lacnic.net> MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] LACNIC - CAF Field Research on IPv6 Adoption in Latin America X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 22:32:58 -0000 ------sinikael-?=_1-14588587674510.008272466249763966 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There was indeed a problem which was resolved earlier today Thanks Arturo ! Sent from a mobile device. Enviado desde un dispositivo = movil. Sent using CloudMagic Email [https://cloudmagic.com/k/d/mailapp?= ct=3Dpa&cv=3D8.3.8&pv=3D6.0.1&source=3Demail_footer_2] On Thu, Mar 24, 2016= at 3:18 PM, Arturo Servin < arturo.servin@gmail.com [arturo.servin@gmail.= com] > wrote: It works for me: curl -6 -I http://portalipv6.lacnic.net/ = [http://portalipv6.lacnic.net/] HTTP/1.1 200 OK Date: Thu, 24 Mar 2016 = 18:21:11 GMT Server: Apache/2.4.17 (FreeBSD) PHP/5.6.14 X-Powered-By: PHP/5.6.14 Set-Cookie: _icl_current_language=3Des; = expires=3DFri, 25-Mar-2016 18:21:11 GMT; Max-Age=3D86400; path=3D/ Set-Cookie: PHPSESSID=3Ddqevucd9f5h7poruq8l8t8i9m5; path=3D/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, = must-revalidate, post-check=3D0, pre-check=3D0 Pragma: no-cache Set-Cookie: _icl_current_language=3Des; expires=3DFri, 25-Mar-2016 18:21:11= GMT; Max-Age=3D86400; path=3D/ Link: < http://portalipv6.lacnic.= net/wp-json/ [http://portalipv6.lacnic.net/wp-json/] >; rel=3D" https://api= .w.org/ [https://api.w.org/] " Content-Type: text/html; charset=3DUTF-8 Perhaps your ISP has broken connectivity in v6. How did you conclude that the document was in gw01.lacnic.registro.br = [http://gw01.lacnic.registro.br/] ? Regards .as On Thu, 24 Mar 2016 at 06:26 Carlos M. Martinez < carlos@lacnic.net = [carlos@lacnic.net] > wrote: Thanks for the heads up. This only shows that = we all have still a lot of work to do. See you in a few days. Carlos On 3/24/16 9:56 AM, Mat=C4=9Bj Gr=C3=A9gr wrote: > On 03/22/2016 07:55 PM, = Carlos M. Martinez wrote: >> Hello all, >> >> I'd like to share with this = wg the result of a research project carried >> out by LACNIC with financing= provided by Banco CAF (one of the >> development banks active in the Latin= American region) >> >> The full report is here: >> http://portalipv6.= lacnic.net/wp-content/caf-lacnic/CAF-LACNIC-IPv6-Deployment-Social-Economic= -Development-in-LAC.pdf [http://portalipv6.lacnic.net/wp-content/caf-lacnic= /CAF-LACNIC-IPv6-Deployment-Social-Economic-Development-in-LAC.pdf] >> >> A shorter version is available at: >> http://portalipv6.lacnic.= net/en/caf-lacnic/ [http://portalipv6.lacnic.net/en/caf-lacnic/] >> > It always amuses me that reports claiming that IPv6 is the best solution > for future are shared on web pages with broken IPv6 [1]. At least, I > have the old legacy protocol that I can use for downloading the report. = :) > > Cheers, > > M. > > [1] The webpage with the report is not accessible= over IPv6 for me. It > timeouts on gw01.lacnic.registro.br [http://gw01.= lacnic.registro.br] (2001:12ff:1:3::212). ________________________________= _______________ v6ops mailing list v6ops@ietf.org [v6ops@ietf.org] https://www.ietf.org/mailman/listinfo/v6ops [https://www.ietf.= org/mailman/listinfo/v6ops] ------sinikael-?=_1-14588587674510.008272466249763966 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

There was indeed a problem which was resolved earlier = today

Thanks Arturo !

= Sent from a mobile device. 
Enviado desde un dispositivo movil.=

Sent using CloudMag= ic Email
On Thu= , Mar 24, 2016 at 3:18 PM, Arturo Servin <arturo.servin@gmail.com> wrote:


It works for me:

<= div>

curl -6 -I http://portalipv6.lacnic.= net/

HTTP/1.1= 200 OK

Date: Thu, 24 Mar = 2016 18:21:11 GMT

Server: = Apache/2.4.17 (FreeBSD) PHP/5.6.14

X-Powered-By: PHP/5.6.14

Set-Cookie: _icl_current_language=3Des; expires=3DFri, = 25-Mar-2016 18:21:11 GMT; Max-Age=3D86400; path=3D/

Set-Cookie: PHPSESSID=3Ddqevucd9f5h7poru= q8l8t8i9m5; path=3D/

Expires:= Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, = post-check=3D0, pre-check=3D0

Pragma: no-cache

Set-Cookie: _icl_current_language=3Des; expires=3DFri, = 25-Mar-2016 18:21:11 GMT; Max-Age=3D86400; path=3D/

Link: <http://portalipv6.lacnic.net/wp-json/>; = rel=3D"https://api.w.org/"

Content-Type: text/html; = charset=3DUTF-8


Perhaps your ISP has broken = connectivity in v6.


How did you conclude that the = document was in gw01.lacnic.registro.br?=


Regards

.= as


On= Thu, 24 Mar 2016 at 06:26 Carlos M. Martinez <carlos@lacnic.net> = wrote:
Thanks for the heads up. = This only shows that we all have still a lot of
work to do.

See you in a few days.

Carlos

On 3/24/16 9:56 AM, = Mat=C4=9Bj Gr=C3=A9gr wrote:
> On 03/22/2016 07:55 PM, Carlos M. = Martinez wrote:
>> Hello all,
>>
>> I'd like to share with this wg the result of a research project = carried
>> out by LACNIC with financing provided by Banco CAF = (one of the
>> development banks active in the Latin American = region)
>>
>> The full report is here:
>> http://portalipv6.lacnic.net/wp-content/caf-lacnic/CAF-L= ACNIC-IPv6-Deployment-Social-Economic-Development-in-LAC.pdf
>>
>> A shorter version is available at:
>> http://portalipv6.lacnic.net/en/caf-lacnic/
>>
> It always amuses me that reports claiming that IPv6 is = the best solution
> for future are shared on web pages with broken = IPv6 [1]. At least, I
> have the old legacy protocol that I can use = for downloading the report. :)
>
> Cheers,
>
> M.
>
> [1] The webpage with the report is not accessible= over IPv6 for me. It
> timeouts on gw01.lacnic.registro.br = (2001:12ff:1:3::212).

____________________________________________= ___
v6ops mailing list
v6ops@ietf= .org
https://www.ietf.org/mailman/listinfo/v6ops
------sinikael-?=_1-14588587674510.008272466249763966-- From nobody Fri Mar 25 08:36:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407BC12D6D9 for ; Fri, 25 Mar 2016 08:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx50L0-4af8M for ; Fri, 25 Mar 2016 08:36:23 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E3F12DB33 for ; Fri, 25 Mar 2016 08:36:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2PFaLXb010469 for ; Fri, 25 Mar 2016 16:36:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 204AB205369 for ; Fri, 25 Mar 2016 16:37:13 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 18236205354 for ; Fri, 25 Mar 2016 16:37:13 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2PFaL8c023084 for ; Fri, 25 Mar 2016 16:36:21 +0100 To: v6ops@ietf.org References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk> <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no> <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com> <20160218003504.18E73428C484@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: <56F55AF5.4020502@gmail.com> Date: Fri, 25 Mar 2016 16:36:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160218003504.18E73428C484@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 15:36:25 -0000 Le 18/02/2016 01:35, Mark Andrews a écrit : > > In message > > , Tom Coffeen writes: >> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong >> wrote: >> >>> >>>> On Feb 15, 2016, at 23:51 , sthaug@nethelp.no wrote: >>>> >>>>> I believe we should not even suggest that it might be OK to >>>>> allocate manually. This draft isn't a BCP so we can use >>>>> normal English, for example: >>>>> >>>>> o Prefix generation: prefixes must be randomly generated >>>>> according to the algorithms defined in [RFC4193]. There are >>>>> on-line tools available to do this interactively, if not >>>>> performed automatically by the CPE. Manual assignment of >>>>> easy-to-remember prefixes must never be done because of the >>>>> high risk of collision, recreating the problems of >>>>> [RFC1918]. >>>> >>>> Assume I want to number my lab using ULA. There's no way I'm >>>> going to be using randomly generated addresses - I want to have >>>> an *address plan*, and predictable addresses acording to a >>>> suitable pattern, just as I would do with regular IPv6 >>>> addresses. >>> >>> You’re supposed to randomly select a /48 from fc00::/7 >> >> My understanding from RFC4193 is that the L bit (8th MSB) is not >> yet defined (i.e., not "locally defined") when set to 0. Should >> this impact at all one's confidence in allocating /48s from >> fc00::/8? > > fc00::/8 is reserved - DO NOT USE fd00::/8 is where you should be > generating your prefixes in. > > If you need to simulate a /32 then generate bits 9..32 randomly and > prefix with 11111101. Repeat if you are simulating more than one > ISP. > > There is never a valid case for not generating the high bits > randomly. You don't get "nice" upper bits from RIR's unless you are > very lucky. There is one question of getting "nice" upper bits from RIRs, and there is another question of getting "nice" intermediary bits from intermediaries. I managed to persuade my intermediary to give me the intermediary bits of my choice. I struggled a lot to decide what would be nice, I used some generator, some dictionaries, some well-known niceties - and then the intermediary agreed. This deliberation of "nice" intermediary did not exist in IPv4, and it is new in IPv6. Faceb00c put their names into their addresses, imagine that. Google put RFC numbers in theirs too. Alex > > Mark > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Mar 25 08:40:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CD712DC16 for ; Fri, 25 Mar 2016 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1HBpldYGL2F for ; Fri, 25 Mar 2016 08:40:07 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE0C12DC01 for ; Fri, 25 Mar 2016 08:40:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2PFe4Fb019202 for ; Fri, 25 Mar 2016 16:40:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C9D11205411 for ; Fri, 25 Mar 2016 16:40:55 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C4938205410 for ; Fri, 25 Mar 2016 16:40:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2PFe3Np027171 for ; Fri, 25 Mar 2016 16:40:03 +0100 To: v6ops@ietf.org References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk> <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no> <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com> <56C50DFC.7050908@gmail.com> From: Alexandre Petrescu Message-ID: <56F55BD3.9000605@gmail.com> Date: Fri, 25 Mar 2016 16:40:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C50DFC.7050908@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 15:40:09 -0000 Le 18/02/2016 01:19, Brian E Carpenter a écrit : > On 18/02/2016 12:52, Tom Coffeen wrote: >> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong wrote: >> >>> >>>> On Feb 15, 2016, at 23:51 , sthaug@nethelp.no wrote: >>>> >>>>> I believe we should not even suggest that it might be OK to allocate >>>>> manually. This draft isn't a BCP so we can use normal English, for >>>>> example: >>>>> >>>>> o Prefix generation: prefixes must be randomly generated according >>>>> to the algorithms defined in [RFC4193]. There are on-line tools >>>>> available to do this interactively, if not performed automatically >>>>> by the CPE. Manual assignment of easy-to-remember prefixes must >>>>> never be done because of the high risk of collision, recreating >>>>> the problems of [RFC1918]. >>>> >>>> Assume I want to number my lab using ULA. There's no way I'm going to >>>> be using randomly generated addresses - I want to have an *address >>>> plan*, and predictable addresses acording to a suitable pattern, just >>>> as I would do with regular IPv6 addresses. >>> >>> You’re supposed to randomly select a /48 from fc00::/7 >>> >> >> My understanding from RFC4193 is that the L bit (8th MSB) is not yet >> defined (i.e., not "locally defined") when set to 0. Should this impact at >> all one's confidence in allocating /48s from fc00::/8? > > You should only allocate in fd00::/8. fc00::/8 is reserved for future use. > I think this detail should be added to the IANA registry, which only > mentions fc00::/7 . This fd00 vs fc00 ULAs should be clearer than is now and if IANA can help then let's ask. The fd00 vs fc00 difference is too hard to explain for someone who needs an address to put there now. In IPv4 it was simple: just use 192.x, or maybe a 10.y address - a simple incantation. In IPv6 it needs meetings after meetings to explain something that is so simple in fact. Alex > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Mar 25 08:46:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887F012DAD2 for ; Fri, 25 Mar 2016 08:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7lHzr1PlLX5 for ; Fri, 25 Mar 2016 08:46:09 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F2112DB83 for ; Fri, 25 Mar 2016 08:46:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2PFk5Po014659 for ; Fri, 25 Mar 2016 16:46:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 450D52053F8 for ; Fri, 25 Mar 2016 16:46:57 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3D3542052F6 for ; Fri, 25 Mar 2016 16:46:57 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2PFk5xv023327 for ; Fri, 25 Mar 2016 16:46:05 +0100 To: v6ops@ietf.org References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D4491A@nkgeml514-mbx.china.huawei.com> From: Alexandre Petrescu Message-ID: <56F55D3D.9050908@gmail.com> Date: Fri, 25 Mar 2016 16:46:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D4491A@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 15:46:12 -0000 Le 17/02/2016 10:13, Liubing (Leo) a écrit : > Hi Dale, > > Thanks much for your elaborating explanation. Replies inline. > > >> To clarify, to mitigate the ULA prefix overlap internally after a >> merger of two internal networks, nothing related to off-site >> connectivity. We have had this issue at our site on ipv4 when our >> healthcare system and campus enterprise network ended up >> overlapping in 10/8 and needed NAT just to get between the two, >> completely unrelated to off-site connectivity. Having first-hand >> experienced getting burned I hope we can emphasize the risk to >> avoid poorly chosen ULA prefixes in non-trivial (more than just a >> CPE) networks. > >> I was going to make a similar comment that I initially withheld >> about section "6.1. Used in Isolated Networks" to which I would >> claim isolation, though often well-intended in my experience ends >> up being temporary when it is found that devices later need >> external software updates, control, logging, or ancillary support >> systems for which proxying is too hard. >> >> If it's not obvious I do not like ULA at all, and I know a lot of >> the arguments have already been hashed out. I am hoping that this >> guidance can at least be clear about the corners that people will >> (in my mind) inevitably back themselves into so it can be avoided. >> There's a lot of value getting that out. > > [Bing] From your above comments, I read two warnings: 1. Warning > people that when they use human-friendly/poorly-chosen ULA prefixes, > it might result in renumbering or ULA-to-ULA NAT if collision happens > when sites merging. This is good warning in some contexts which may be dynamic. In some office medium-scale environments, which are not evolving at the current speed of markets, there are plans that need to make sense to successive generations of adminsitrators. For that to work these address plans need to be simple to understand, to describe, to communicate, to maintain fixed. Random addresses make these plans hard to do. Human-readable-sense-making identifiers are often preferred in these plans. Google choses and sticks to an RFC number in an IPv6 address that they communicate to a large number of people. It could have been something more difficult to remember and more random. > 2. Warning people that isolation would be probably temporary, when > connected, they either deal with ULA+PA, or they'll have to let > NAT/proxy involved. I agree. Alex > > In current Section 4.1, there is some text discuss the two points a > bit, but I think the text needs to be tilt up and be put at a more > noteworthy place in the next version. Thanks for raising these issues > up. > > Best regards, Bing > >> Dale >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Mar 25 09:06:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518A712D91C for ; Fri, 25 Mar 2016 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZlpYS7OJRjt for ; Fri, 25 Mar 2016 09:06:21 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648A312D525 for ; Fri, 25 Mar 2016 09:06:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2PG6Ii9021627 for ; Fri, 25 Mar 2016 17:06:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2A10D20545D for ; Fri, 25 Mar 2016 17:07:10 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 164382053D9 for ; Fri, 25 Mar 2016 17:07:10 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2PG6IiS000643 for ; Fri, 25 Mar 2016 17:06:18 +0100 To: v6ops@ietf.org References: <56BB639E.5010505@si6networks.com> From: Alexandre Petrescu Message-ID: <56F561FA.10605@gmail.com> Date: Fri, 25 Mar 2016 17:06:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56BB639E.5010505@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Comment on draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 16:06:23 -0000 Hi v6opers, I have a few comments on draft-ietf-v6ops-ula-usage-considerations-05. > o Default Routing: connectivity may be broken if ULAs are used as > default route. [explanation based on RFC7084 and RFC4191]. Well this should really be formulated differently. In some enterprise networks the ULAs _are_ used as default routes and connectivity is ok with Internet ("Enterprise" described in bullet 2 of section 4.2.2). These are not home nets (RFC7084) nor do they use RFC4191 "specific routes". I suggest the following: o Default Route: a default route is selected when all other routes in the routing table can not be matched against the destination address of a packet by using a particular IPv6 longest-match method. As such, one would expect that ULA addresses be reached by the mechanism of default routing as well. However, in implementation it is not clear whether or not ULA addresses are reached through default routes, and which ones; the default routing concept does not have a distinctor. As such, connectivity with ULAs through default routes may be broken. Dont expect to reach ULA prefixes through default routes (other than an ULA itself if that's the default route), better use specific routes for ULAs. And yes ULAs _are_ used as default routes. A route is a tuple: [prefix, next-hop address] A default route is: [::/0, next-hop address] A ULA used as a default route is: [::/0, ULA] Alex From nobody Fri Mar 25 09:11:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2BD12DAE3 for ; Fri, 25 Mar 2016 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMnwJggY2vUs for ; Fri, 25 Mar 2016 09:11:51 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9340712DACF for ; Fri, 25 Mar 2016 09:11:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2PGBne5023718 for ; Fri, 25 Mar 2016 17:11:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 80DE3202E03 for ; Fri, 25 Mar 2016 17:12:41 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6E91B202E02 for ; Fri, 25 Mar 2016 17:12:41 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2PGBnBJ003295 for ; Fri, 25 Mar 2016 17:11:49 +0100 To: v6ops@ietf.org References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D4491A@nkgeml514-mbx.china.huawei.com> <56F55D3D.9050908@gmail.com> From: Alexandre Petrescu Message-ID: <56F56345.20203@gmail.com> Date: Fri, 25 Mar 2016 17:11:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F55D3D.9050908@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] ipv6 unicast-routing CLI option is mandatory on some hardware X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 16:11:53 -0000 Hi v6opers, Contrary to IPv4, on some routers it is mandatory to say "ipv6 unicast-routing" otherwise routing is not working. In IPv4 you dont have to say that, but in IPv6 yes. I guess this is a negative side effect of the importance multicast has in IPv6. In a perspective of IPv6 now everywhere, s/IPv6/IP/g in all CLI. Alex From nobody Fri Mar 25 09:32:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5107412D52B for ; Fri, 25 Mar 2016 09:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlGp86gaNc_z for ; Fri, 25 Mar 2016 09:32:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5FE12D4FF for ; Fri, 25 Mar 2016 09:32:44 -0700 (PDT) Received: from mb-2.local ([IPv6:2601:647:4204:51:f118:1457:81ef:6ef3]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u2PGWgrF082816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Mar 2016 16:32:42 GMT (envelope-from joelja@bogus.com) To: Alexandre Petrescu , v6ops@ietf.org References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D4491A@nkgeml514-mbx.china.huawei.com> <56F55D3D.9050908@gmail.com> <56F56345.20203@gmail.com> From: joel jaeggli Message-ID: <857d1499-8fe9-f07c-3962-d565dcbadeb5@bogus.com> Date: Fri, 25 Mar 2016 09:32:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <56F56345.20203@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xvoBR3DkiHXs1OSK39Bb0OpcR608FVMqT" Archived-At: Subject: Re: [v6ops] ipv6 unicast-routing CLI option is mandatory on some hardware X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 16:32:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xvoBR3DkiHXs1OSK39Bb0OpcR608FVMqT Content-Type: multipart/mixed; boundary="dwV1btUi6NAMPEBSwUOSsAeEvrauAbQVk" From: joel jaeggli To: Alexandre Petrescu , v6ops@ietf.org Message-ID: <857d1499-8fe9-f07c-3962-d565dcbadeb5@bogus.com> Subject: Re: [v6ops] ipv6 unicast-routing CLI option is mandatory on some hardware References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D4491A@nkgeml514-mbx.china.huawei.com> <56F55D3D.9050908@gmail.com> <56F56345.20203@gmail.com> In-Reply-To: <56F56345.20203@gmail.com> --dwV1btUi6NAMPEBSwUOSsAeEvrauAbQVk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/25/16 9:11 AM, Alexandre Petrescu wrote: > Hi v6opers, >=20 > Contrary to IPv4, on some routers it is mandatory to say "ipv6 > unicast-routing" otherwise routing is not working. In IPv4 you dont > have to say that, but in IPv6 yes. >=20 > I guess this is a negative side effect of the importance multicast has > in IPv6. if your user interface conventions for enabling protocols on a router are embedded in conventions you came up with in the 80s there are going to be few warts. > In a perspective of IPv6 now everywhere, s/IPv6/IP/g in all CLI. Not violating the expectations derived for the existing configuration / convention is something vendors overlook at their peril... > Alex >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --dwV1btUi6NAMPEBSwUOSsAeEvrauAbQVk-- --xvoBR3DkiHXs1OSK39Bb0OpcR608FVMqT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlb1aCoACgkQ8AA1q7Z/VrISSQCfYyTtgdwCAJuGTZ2B2VKuVblF 1TIAn3pgpaHmVzFgUnCITjjOepsA883A =jVBH -----END PGP SIGNATURE----- --xvoBR3DkiHXs1OSK39Bb0OpcR608FVMqT-- From nobody Fri Mar 25 11:24:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669912D627 for ; Fri, 25 Mar 2016 11:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoYKjJbZ79Mv for ; Fri, 25 Mar 2016 11:24:04 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990B112D620 for ; Fri, 25 Mar 2016 11:23:57 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6B02662ACB for ; Fri, 25 Mar 2016 19:23:55 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2098F60397 for ; Fri, 25 Mar 2016 19:23:55 +0100 (CET) Received: (qmail 78216 invoked by uid 1007); 25 Mar 2016 19:23:55 +0100 Date: Fri, 25 Mar 2016 19:23:55 +0100 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160325182355.GC62900@Space.Net> References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D4491A@nkgeml514-mbx.china.huawei.com> <56F55D3D.9050908@gmail.com> <56F56345.20203@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F56345.20203@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] ipv6 unicast-routing CLI option is mandatory on some hardware X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 18:24:08 -0000 Hi, On Fri, Mar 25, 2016 at 05:11:49PM +0100, Alexandre Petrescu wrote: > Contrary to IPv4, on some routers it is mandatory to say "ipv6 > unicast-routing" otherwise routing is not working. In IPv4 you dont > have to say that, but in IPv6 yes. > > I guess this is a negative side effect of the importance multicast has > in IPv6. This is just a matter of defaults. Back in the day, you had to turn on "ip unicast-routing" as well - if not set, the device would be a host, not a router (read: not forward packets). > In a perspective of IPv6 now everywhere, s/IPv6/IP/g in all CLI. No, because that does not make sense - but s/ip/ipv4/ (as IOS XR does) is reasonable. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Mar 25 14:16:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0E712D5A2 for ; Fri, 25 Mar 2016 14:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.531 X-Spam-Level: X-Spam-Status: No, score=-114.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQHfnbHS5hSu for ; Fri, 25 Mar 2016 14:16:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AB112D165 for ; Fri, 25 Mar 2016 14:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3578; q=dns/txt; s=iport; t=1458940582; x=1460150182; h=from:to:cc:subject:date:message-id:mime-version; bh=OVW0g5qCiGHkq4g588OvOVWZ/JNdD7YiRhpxxR5mCaQ=; b=T4UlJVgFmVrS682TJdVIH8f9P268lsI3E05cNY7W6Gdmnn1j6fWtohxN WfWmLldsRWhsle3FUYrwPNhqnWzoVm83qacijCtAP7K+dLVQVykfsfiG1 yXAb9ezLtE7RngxGK4UjgGyEZXpP2xGQKO6U42iLm0ppPwEZifUORwvH0 A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAwDhqfVW/4UNJK1egy5TgQO4SYIPD?= =?us-ascii?q?oFwIYVsgTU4FAEBAQEBAQFkHAuERAR5EgGBACcEDhOIGQ7BMgEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQ0EBIgRCIowgisFh1cGhxGIcgGDHYFmbYgTgWaNJYYPiHoBH?= =?us-ascii?q?gFDg2WITAQ7fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,392,1454976000"; d="asc'?scan'208";a="90292018" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2016 21:16:21 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u2PLGLgf031344 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Mar 2016 21:16:22 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Mar 2016 16:16:21 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Fri, 25 Mar 2016 16:16:21 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: IETF 95 Agenda for v6ops Thread-Index: AQHRhtuUlvpx/pHywkKwz9ZQRPqzxw== Date: Fri, 25 Mar 2016 21:16:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_DA092582-B0E0-411E-A6B7-66C855CBBAB8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] IETF 95 Agenda for v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 21:16:24 -0000 --Apple-Mail=_DA092582-B0E0-411E-A6B7-66C855CBBAB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You may find our agenda at IETF 95 at = https://datatracker.ietf.org/meeting/95/agenda/v6ops/. We will discuss = two internet drafts, and have a presentation on IPv6 deployment = successes and failures in Latin America. We have cancelled the Tuesday morning meeting. Current Internet Draft status: Published since IETF 94: draft-ietf-v6ops-pmtud-ecmp-problem published as RFC 7690 draft-ietf-v6ops-siit-dc published as RFC 7755 draft-ietf-v6ops-siit-dc-2xlat published as RFC 7756 draft-ietf-v6ops-siit-eam published as RFC 7757 draft-ietf-v6ops-reducing-ra-energy-consumption published as RFC = 7772 RFC Editor: EDIT, Sent to the RFC Editor (being edited by the RFC = Editor) 2016-02-29 draft-ietf-v6ops-mobile-device-profile IESG: Approved-announcement to be sent (RFC Editor's in-basket) 2016-03-17 draft-ietf-v6ops-ipv6-ehs-in-real-world IESG: Waiting for Writeup (Joel's in-basket following IETF LC) 2016-03-09 draft-bao-v6ops-rfc6145bis 2016-03-09 draft-ietf-v6ops-host-addr-availability WG: WG Document, but needs update following IETF 94 discussion 2015-10-19 draft-ietf-v6ops-design-choices WG: WG Document, but need updates following list discussion 2016-02-16 draft-ietf-v6ops-dhcpv6-slaac-problem (needs an = update) 2016-02-08 draft-ietf-v6ops-ula-usage-considerations (needs = an update) 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host = (needs an update) Individual Submission: Unuqdated since IETF 94 2015-10-19 draft-xu-v6ops-dslite-redundancy Individual Submission: Updated and on agenda 2016-03-11 draft-gont-v6ops-ipv6-ehs-packet-drops (on = agenda) 2016-02-27 = draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node (on agenda) Individual Submission: Updated but no list discussion 2016-03-21 draft-ybai-v6ops-ipv6-for-openstack 2016-01-05 draft-templin-v6ops-pdhost 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment 2016-01-03 draft-xli-v6ops-cernet-deployment Expired; the chair notes that there was little interest in them: draft-liu-v6ops-running-multiple-prefixes draft-yang-v6ops-ipv6tran-select draft-sun-v6ops-xlat-multi draft-hui-v6ops-ipv6trans-select-nfv --Apple-Mail=_DA092582-B0E0-411E-A6B7-66C855CBBAB8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVvWqpEayAOS/EQ8MAQKO/xAAigeiPhnxPTWTaHNB7YQMO1ktwfkHTQZB 2I8p8sm8p6ln/pP6pV3ppuqtgCm+w1BHl4jl6NR1PFxnz57D13hhR+JbfeogOCFe +s/jO40xwKQknMXL3PhqN1LlccJUN+eQ0Vsz+LraHHO0pJckL8LsUDuj7Wg6/bgJ 4JvmXOC+oBannFJ2MXfDP7vkqUpkdAF6DVpM2mKD3FdZq3QkQRUWvbcI7DR7GTXt 3DFH7KL7PDHpgTNk6wy0cHNMxifgGs6a5LTzL94ReIJLlbdBcaEZrcTso9ODz8kN VYDWuBi58tp6+VXhbZGI5dRW610URiS/ItAAPVl4GIrSAyERxc0g3ftMeedsR1Zt d5P6/wbjWyIQPzpg+p8QF0wao4f3EgAwQQS877sNN3OMMc+8doN7GXRsU/9AC7bZ HoGGyt+u9JTmwre+iytkXdrziq1rLq1VHiQPr/wTER2+thH2+B0ZOCrXrwvmqpn4 4FKOhECgpPvN0QoGHUHMrDc7Kdb1YCipjjn73UAoW/X8tiB9A31HvXwIIGRUb6rz +Ms+mglbhOF9UuPYEN1hAqcFSaNSZKpIOob6atulzYYSQRRcNuDElm7O0+KSQgk9 5ALmE1DIrZD+uFzpax2GcifCGi0+W8MB+6IpEixnbWuoWTNb/vgSlrexqsOFqv2N YoyzIxw5ipQ= =alWJ -----END PGP SIGNATURE----- --Apple-Mail=_DA092582-B0E0-411E-A6B7-66C855CBBAB8-- From nobody Mon Mar 28 11:38:52 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8AA12DB69 for ; Mon, 28 Mar 2016 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMxI8SuHPD1f for ; Mon, 28 Mar 2016 11:38:49 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB8812DB4D for ; Mon, 28 Mar 2016 11:38:47 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id AA1A862A91 for ; Mon, 28 Mar 2016 20:38:44 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.space.net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7A6B760612 for ; Mon, 28 Mar 2016 20:38:44 +0200 (CEST) Received: (qmail 2557 invoked by uid 1007); 28 Mar 2016 20:38:44 +0200 Date: Mon, 28 Mar 2016 20:38:44 +0200 From: Gert Doering To: otroan@employees.org Message-ID: <20160328183844.GR62900@Space.Net> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5LiOUhUlsRX0HDkW" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 18:38:51 -0000 --5LiOUhUlsRX0HDkW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Mar 16, 2016 at 06:38:12PM +0100, otroan@employees.org wrote: > making processing of extension headers hard was considered by Steve to be= a feature. >=20 > that's well known.=20 Well, the advertising literature for IPv6 claims that the EHs are there to make processing *easier*... Maybe we should just document this formally "the IETF considers the difficulties caused by EHs a feature, so feel free to drop them if that annoys you, or stay with IPv4" and go on? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --5LiOUhUlsRX0HDkW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVvl6NN9WwGXkzn/FAQLwJRAAod/rB7q0r+kllAqPhQ4JRqIjtDDxZY18 SZfTSbZ0UNiFqXMfTRzMopBhyGdbM1PEM2UhilaGELYGytS9zvZli+duVQ9NVzPO HMRgqS46jd/t4Qn1g/uijFc1km3nN9HfGlLJEP0B86S5ZAVyVVIE0DunriMf+TaN GB/HdBcGcyk22UenrJjU1udToiU+9XYfGz7F1+5o5j2h7zIU1kjz3uHVHym6/C4y yh0epx21iVxhhLbEzyWd6mC1l2sih7TdGKnia5xgigzxWYB3CnXhegaj0TaLLzQJ 1d9+fM2jeivF1LfoWzwF67+nKw4P+qSA/IiDHkLDKAhNk0cKmJHT7mJ/gYpHJ2QQ 6bYCEd9+PPsxTsN8Mj8UMLAKoVzycR1aJ4B4/ltiXrt8EbYglmr/MI9zmt1vMcav dvLiKfxKuv0X64XN25XiE9lIiU5B8FOd/ONpYlN9ieevbo8HfTBizHSWeNGRZxmD 9xC69+Q4RstXRbEUya7VgL/uvYQFmdmCOB1EX/6hdHDEdkD0Mcq7rrHYKVsN4uq3 8cK+8hHj/cNbD1ka65skUeCSYwP8KCQiQ8oCguBlTmATObVM0iZ8QBN5/WF9AGE5 FUs+HrsEWbqMzl3RQiuKzNPScOgCxCilFh+TNKdA8zlDqk8ryzB3lPtf8ldRAsiQ kYFK3CCgaC0= =mxBL -----END PGP SIGNATURE----- --5LiOUhUlsRX0HDkW-- From nobody Mon Mar 28 14:29:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7712D538 for ; Mon, 28 Mar 2016 14:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACPFgQ3aHHT8 for ; Mon, 28 Mar 2016 14:29:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E9912D0BD for ; Mon, 28 Mar 2016 14:29:31 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2SLTFPW024678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Mar 2016 14:29:15 -0700 (PDT) To: Gert Doering , otroan@employees.org References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> From: Joe Touch Message-ID: <56F9A22B.2030301@isi.edu> Date: Mon, 28 Mar 2016 14:29:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160328183844.GR62900@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 21:29:33 -0000 On 3/28/2016 11:38 AM, Gert Doering wrote: > Well, the advertising literature for IPv6 claims that the EHs are there > to make processing *easier*... The alternative in IPv4 is unstructured header extensions, which are harder to handle. In IPv6, at least the HBH and E2E headers are separated. Note, however, that the idea of an offset to "jump" to the transport header makes no sense. There's no rule that HBH header lengths never change in transit, which means you just end up with another field that might be inconsistent with the actual header. Better to admit that something that runs at the speed of an endpoint should be setting a flow label. Joe From nobody Mon Mar 28 14:36:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0012D12D4FD for ; Mon, 28 Mar 2016 14:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.531 X-Spam-Level: X-Spam-Status: No, score=-114.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qGdshnTSVlU for ; Mon, 28 Mar 2016 14:36:30 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F1312D0C1 for ; Mon, 28 Mar 2016 14:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1459200990; x=1460410590; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NfHViaL9xwZyLqS+Dpl8eE64R1jsVu97vpIAvtDm4MI=; b=ZL+wUvMkRBC+rlw6VDySf30r7+C7ce1SuPGhykoboNNnDWEK3GoDLrDX agMPwrR1i1cMkLBB5B4iHS6ei8D+JTOv0Boh2GSWkgJL2mdiqkzhJXFQI Ms/JSFETPSF78ULK8+c0JJfaD1bYgUddgb6rk2H3X8vcDATGmIrCQ3eAJ 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCBQAAo/lW/4oNJK1dDoMggVAGunyBc?= =?us-ascii?q?IYNAoEkORMBAQEBAQEBZBwLhEIBAQR5EAIBCBguMiUCBA4FDogZwCgBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQENCIgQglGHZ4IrBZdhAYMdgWaJAoFQjTuPCgEhAUCDK?= =?us-ascii?q?jtsh3x+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,408,1454976000"; d="asc'?scan'208";a="87454187" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2016 21:36:29 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2SLaT76028988 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2016 21:36:29 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Mar 2016 16:36:28 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 28 Mar 2016 16:36:28 -0500 From: "Fred Baker (fred)" To: "touch@isi.edu" Thread-Topic: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRiTniuC9r2YC2skGBfdtx5Op9bQ== Date: Mon, 28 Mar 2016 21:36:28 +0000 Message-ID: <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> In-Reply-To: <56F9A22B.2030301@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_1979583D-D47E-4871-8B93-2E12153C80E3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 21:36:32 -0000 --Apple-Mail=_1979583D-D47E-4871-8B93-2E12153C80E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote: > Note, however, that the idea of an offset to "jump" to the transport > header makes no sense. There's no rule that HBH header lengths never > change in transit, which means you just end up with another field that > might be inconsistent with the actual header. Don't tell the 6man chairs. They think that changing the length of a HBH = header (or any header) in transit would be a problem, and I can confirm = that in the event that there is an AH header in the packet. We had that = discussion in 6man at IETF 94. --Apple-Mail=_1979583D-D47E-4871-8B93-2E12153C80E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVvmj20ayAOS/EQ8MAQKMKw/+KgiJBKawcethtD5pAYjG58y+R4gMhFJT HrQgvUjNJtDrChZtTzFg7BvUYbUz9pzD1237G+KtkvmTFIzq0E8jE+Q2/nooNPX6 JdBcg8xI+gG3a/e0n7Dz1UH5aOh3keBfMziGR7MEAg2cr5o/YOPpscW6E/hpBxnh r2MVYQIZJT3h7q9rk+nHiWdZB1U3sNUawXTAESEJIcSAudLW0F8hOTTohrpVE4Q5 +Xh5Lu2gPZLhm3Uj251bcPcsxd3z18Xeeg6x8TapgeqrQajEv9k8nWiu6NkRkCGv YOiExwYlR/V9xHutGnH2AM45KQ/R2FXwypCHQ7Y1vQcNgaipR0rotQyXzwc474NQ be2Zmw5kpOsYBxMJ9Q+l6z2akp17qqhQcvxfgflvQW6LoEo5jXxoC3iXmSAcjDEt Xj5wxkr3/07peWuSeiGXItPNo+yMdmSHKn0Oy7F5tx4NgwePRJrQqHQNVoVVn5fz yPauoPQ7Wu67vwRLu7xgwBU2xTevf2okvz4BF6j9e0o/VX9otwa16SUOo7aY58oc B0kDLdis+QM4aB9uh1gujAFftawbBRjOQ63WD8qZ7z9ZYfL2Tpz2PngE3cpTYpm9 rfhQl1iSk5fgSL73InFg/vrG4rAuq8i4AKtvoXEHiMWsKQZxKKaisP+CCc4zz7gH Ys9MrDcRCF8= =DnJb -----END PGP SIGNATURE----- --Apple-Mail=_1979583D-D47E-4871-8B93-2E12153C80E3-- From nobody Mon Mar 28 14:40:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD3912D55F for ; Mon, 28 Mar 2016 14:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pacvo8kQtmQP for ; Mon, 28 Mar 2016 14:40:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E6E12D196 for ; Mon, 28 Mar 2016 14:40:37 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2SLeLCF026932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Mar 2016 14:40:22 -0700 (PDT) To: "Fred Baker (fred)" References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> From: Joe Touch Message-ID: <56F9A4C5.1020804@isi.edu> Date: Mon, 28 Mar 2016 14:40:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 21:40:39 -0000 On 3/28/2016 2:36 PM, Fred Baker (fred) wrote: > > On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote: >> Note, however, that the idea of an offset to "jump" to the transport >> header makes no sense. There's no rule that HBH header lengths never >> change in transit, which means you just end up with another field that >> might be inconsistent with the actual header. > > Don't tell the 6man chairs. They think that changing the length of a > HBH header (or any header) in transit would be a problem, and I can > confirm that in the event that there is an AH header in the packet. We > had that discussion in 6man at IETF 94. It should not be a problem because it is not prohibited. I agree that it probably IS a problem, but that just means more devices that claim compliance inaccurately. This isn't going to be fixed by OPS or 6MAN docs. IMO, we really need to start talking about compliance certification. Joe From nobody Mon Mar 28 15:21:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66F212D194 for ; Mon, 28 Mar 2016 15:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fAlRnQR6QbS for ; Mon, 28 Mar 2016 15:21:11 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF2812D0F6 for ; Mon, 28 Mar 2016 15:21:10 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 4so147617905pfd.0 for ; Mon, 28 Mar 2016 15:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=m8SV3yMmZpszmq1W+wmpSEXzvuGAqXav2SpjdgbjL3Y=; b=FWtAu6R7IFE7Q1aJt+Ltuau51MHGeIMD9Qd/PPKyPNuEiAjAmTUA01xbwF9GX7kGJt 8OZRfa8nijhZw41Sn1bsFVFD61u/3KF3mg1fVToLkhZRspDL2x8IBVtjXlGi/WxAH0rf IzLyaLedjhcL0GhiwhkkWeXmK5dBazLtkrk0dsC8kVHdZpyjnlAFUNFwoAE2O49u35cM AgkJEdM9uTZIOxpMxSIcClA4aKrxXjgv1QthHiz5k5G1FLmin0Ns4ezfXmfu+v5YU6uO fp0tne0ehK229YM+T5HNFPQW7Li/yiEzZDKiYuEFPrBfmma512a6lKf265kon8H1ToeC FR4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=m8SV3yMmZpszmq1W+wmpSEXzvuGAqXav2SpjdgbjL3Y=; b=NoY+18PqRXFOWsn0JwrjRBJU6dkmWB5BVztqFNEIc56K9PWocMw4Ay92wA3PiJKHA6 vzv3lvVmyM1HGGMfLxwKR2Ytwhti1BFuSxtMtfI+at5GDqzuOxTJjnPPZZRTVDiOgpEL wzPKXd4kJ0ud/qMK4jHFovEnCFKg+2lUlxUyRTq0QFwUHaHRGDFZ60sFX9Y9Hh0kILr9 NI4l7cPr3t2U9FnQ4Kg/bSNv3VSyrwtLXCF2HXZ+34s8BY8UnEhmrlOxSFqx/uXuq5AM 8ZUmE49Gl/CrmmNc1CfvnLbsVrB7Bemf2G4NoHqg/ZaOiW9Kse8/jeiWz0AVoOEZgM94 EdUA== X-Gm-Message-State: AD7BkJI47uv6d5Wv2EBJYQPPXpFs0tgySLaI3a9a/hl2WPXEQgrClLNUigib2tbFi/rtrQ== X-Received: by 10.98.15.17 with SMTP id x17mr47222089pfi.52.1459203670519; Mon, 28 Mar 2016 15:21:10 -0700 (PDT) Received: from ?IPv6:2406:e007:71e7:1:28cc:dc4c:9703:6781? ([2406:e007:71e7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s64sm37972052pfi.77.2016.03.28.15.21.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 15:21:08 -0700 (PDT) To: "Fred Baker (fred)" , "touch@isi.edu" References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56F9AE53.8060903@gmail.com> Date: Tue, 29 Mar 2016 11:21:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 22:21:21 -0000 On 29/03/2016 10:36, Fred Baker (fred) wrote: > > On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote: >> Note, however, that the idea of an offset to "jump" to the transport >> header makes no sense. There's no rule that HBH header lengths never >> change in transit, which means you just end up with another field that >> might be inconsistent with the actual header. > > Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94. In any case, that issue is foreseen in https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6 By the way, would an incorrect offset option be any more harmful than an incorrect IHL (with a correponding checksum) in IPv4? Brian From nobody Mon Mar 28 15:41:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EEB12D1BA for ; Mon, 28 Mar 2016 15:41:26 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO35RGEm9lPm for ; Mon, 28 Mar 2016 15:41:24 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C802D12D16A for ; Mon, 28 Mar 2016 15:41:24 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id e3so1476254ioa.1 for ; Mon, 28 Mar 2016 15:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OPXlJSp6fDnY2yqkPr0OGgNQvBafn6PCO55QnHXfAAI=; b=w7XZu+cR8eBmTMAOlDSqroPIsT3IVBbSiR0gvML5YN53Aihe34Cs2lPwd31AU3BwN3 rAkVTSwKzfUeiMeCw73xN9+WEyc5GsvsK6QaVVCImW0+OVQTCM7nAUwWrnq+92OFOh27 UAHPYeM9nvupUv6LIpEZg0hXtZpfSr3idOXOD4fYas8e+oeKjeE7cZ844z/zDXgT9/8B hF9OjLuaO/mMvooMiHD90LqLol4nh0/HSH80nu60o4hB+GqEUthQINFyCQn2LoopHFsz zg9qSCxIj8kZRBjhYwof1eXOqfvPJ+wdj2kQNiQkuyHKrtu2JrYCygsvYojFvkIpWzL4 YCGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OPXlJSp6fDnY2yqkPr0OGgNQvBafn6PCO55QnHXfAAI=; b=H2TW4LgPehMQ4W5i3reRz1KdyiQU+Kwj+gyE4y96YisR099nK34hEuo32SO5BzrpA8 dU1ierNK4lYRRuUeXmDblFsw3N5+099zdf0YNCY21QA8sCre88cQMbq1vuUF8s980dy9 1KS1W5cl+DjG7mgnJPPf4VbmqbTT+iq/ij4wVUFB7XuczwM7bbGtsfjZRFjvOkSq2Y7c vAMaQZHP5g/3jTu7PFaOX01aW3LwyFC7DB+uIe5VKXERGqNZR4VHU4MONGwsZ98q8sP/ zzOfTc/wdxW5qmU0mc22LxjQQsI1qWV0H2gPMznMICiFzovcq4PUeW7wjS/ZraZh451i CXCA== X-Gm-Message-State: AD7BkJKNTM5tpl4lUBes8TOE1vd/hbwGYDRDrCV44Ee2b7YIGuyHLhQolSa5UMs5SWAixMLWWCSHklk4T/zPRg== MIME-Version: 1.0 X-Received: by 10.107.7.72 with SMTP id 69mr31867305ioh.107.1459204884141; Mon, 28 Mar 2016 15:41:24 -0700 (PDT) Received: by 10.107.130.198 with HTTP; Mon, 28 Mar 2016 15:41:23 -0700 (PDT) In-Reply-To: <56F9AE53.8060903@gmail.com> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> Date: Mon, 28 Mar 2016 15:41:23 -0700 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 22:41:26 -0000 On Mon, Mar 28, 2016 at 3:21 PM, Brian E Carpenter wrote: > On 29/03/2016 10:36, Fred Baker (fred) wrote: >> >> On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote: >>> Note, however, that the idea of an offset to "jump" to the transport >>> header makes no sense. There's no rule that HBH header lengths never >>> change in transit, which means you just end up with another field that >>> might be inconsistent with the actual header. >> >> Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94. > > In any case, that issue is foreseen in > https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6 > > By the way, would an incorrect offset option be any more harmful > than an incorrect IHL (with a correponding checksum) in IPv4? > I would speculate that someone might use the offset option to spoof the transport header. The idea would be that an attacker would use the options to spoof the transport header inside some other EH. So a FW might inspect the fake header and and end host would process the real one. A solution for this would be that end hosts need to validate the option is correct. Tom > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Mar 28 16:31:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9317512D4FD for ; Mon, 28 Mar 2016 16:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1KBiKYORC_s for ; Mon, 28 Mar 2016 16:30:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AD412D0CF for ; Mon, 28 Mar 2016 16:30:57 -0700 (PDT) Received: from [128.9.184.162] ([128.9.184.162]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2SNUhFk016229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Mar 2016 16:30:43 -0700 (PDT) To: Brian E Carpenter , "Fred Baker (fred)" References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> From: Joe Touch Message-ID: <56F9BEA3.9050409@isi.edu> Date: Mon, 28 Mar 2016 16:30:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56F9AE53.8060903@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:30:59 -0000 On 3/28/2016 3:21 PM, Brian E Carpenter wrote: > On 29/03/2016 10:36, Fred Baker (fred) wrote: >> >> On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote: >>> Note, however, that the idea of an offset to "jump" to the transport >>> header makes no sense. There's no rule that HBH header lengths never >>> change in transit, which means you just end up with another field that >>> might be inconsistent with the actual header. >> >> Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94. > > In any case, that issue is foreseen in > https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6 Simple counterexample - quickstart (RFC4782). Intermediate routers are allowed to indicate they do not support the option by *deleting* it. Note that routers that do this have no idea about the proposed offset-option, so this will interfere with the calculated offset. That's one example. I wonder how many other existing IPv6 HBH headers are *not prohibited* from changing length, being added, or being deleted en-route. Joe From nobody Mon Mar 28 16:44:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E162112D0EC for ; Mon, 28 Mar 2016 16:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.531 X-Spam-Level: X-Spam-Status: No, score=-114.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRuQjXhZqaGW for ; Mon, 28 Mar 2016 16:44:39 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8039F12D0CF for ; Mon, 28 Mar 2016 16:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3132; q=dns/txt; s=iport; t=1459208679; x=1460418279; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0nNP1v/clxk5Sw66vNimsWx28tGcNQq+39xg3DG8yIs=; b=f59DfgyWw8CLqmrooZSun45nADvyMlhvPrCrqB7UjHvuBRmdKSHs4oM/ piLcopjTDTcwTr/THHaZ8P7aknSwA/ypDeTvbnQja8iLw0DaxYBuQQKmo z1J0/ZpXx1lj1eIAR33B55e93EeLaxhpqHVS4sxgsplMyEPbXeRXp8vpQ 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAgC9wflW/4YNJK1dDoMgU30Gum8Og?= =?us-ascii?q?XAhhWwCgSU4FAEBAQEBAQFkJ4RBAQEBAwF5BQsCAQgYLjIlAgQOBQ6IEQgOwFE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQENBASIEIJRh2eCKwWXYQGDHYFmbYgVjwuPC?= =?us-ascii?q?gEeAUOCAByBDjtsh3x+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,408,1454976000"; d="asc'?scan'208";a="254710386" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2016 23:44:38 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2SNiclk029066 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2016 23:44:38 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Mar 2016 18:44:37 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 28 Mar 2016 18:44:37 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRiTnjuC9r2YC2skGBfdtx5Op9bQ== Date: Mon, 28 Mar 2016 23:44:37 +0000 Message-ID: <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> In-Reply-To: <56F9BEA3.9050409@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_576A2565-1EBA-414B-81C6-A8B519957671"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:44:42 -0000 --Apple-Mail=_576A2565-1EBA-414B-81C6-A8B519957671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 28, 2016, at 4:30 PM, Joe Touch wrote: >=20 >=20 >=20 > On 3/28/2016 3:21 PM, Brian E Carpenter wrote: >> On 29/03/2016 10:36, Fred Baker (fred) wrote: >>>=20 >>> On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote: >>>> Note, however, that the idea of an offset to "jump" to the = transport >>>> header makes no sense. There's no rule that HBH header lengths = never >>>> change in transit, which means you just end up with another field = that >>>> might be inconsistent with the actual header. >>>=20 >>> Don't tell the 6man chairs. They think that changing the length of a = HBH header (or any header) in transit would be a problem, and I can = confirm that in the event that there is an AH header in the packet. We = had that discussion in 6man at IETF 94. >>=20 >> In any case, that issue is foreseen in >> = https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6 >=20 > Simple counterexample - quickstart (RFC4782). >=20 > Intermediate routers are allowed to indicate they do not support the > option by *deleting* it. There's deleting and deleting. One could move any succeeding options = forward 8 bytes (not six, as the document says), shorten the HBH header = by 8 bytes, remove the HBH option entirely if it is now empty perhaps, = and move everything else forward by 8+ bytes as well. Or, one could = overwrite the quickstart option with an 8 byte PAD option. Guess which = one I would do... > Note that routers that do this have no idea about the proposed > offset-option, so this will interfere with the calculated offset. >=20 > That's one example. I wonder how many other existing IPv6 HBH headers > are *not prohibited* from changing length, being added, or being = deleted > en-route. >=20 > Joe --Apple-Mail=_576A2565-1EBA-414B-81C6-A8B519957671 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVvnB5EayAOS/EQ8MAQIrvhAAsPy+jxd9AdJ5EjCB8IB0Z2avmX5AIRDN MZYHgohOb4DniE7azxCS7347RtvoFR3bQmJ/O2XpMZt25x8oNdUfVhwz9OVM4kSc 4r680odNk+yKgGWAmL5Qb8qDmBZxuzKQi0XYRPZqYWZnj8ZF0NYo0LEnQnVos4BF wrUQtSRg7v03Wg0XitSf0TEGDD/s2CrEAuqvWfizAicssT3MteVwC8BvmFmSwHgk zXUJDoc3yijfr1Bx/uJohpM0+QL9leeF5HD1Z2px86zSknxjxfG7ElFV2z9+Kail N+oEGWeS5A/c7lPQTLFvW7gT2GPJOUa8IqtuXLzAwkW88mxD8UIeJGtxgp46wuCg eraw/nW+PRwR84QZd8Lz6pGcO+OrP++pwY9vbHLazW4ctC6u0R8i694M2HoeZp3C o5k2s9lT+FUohnZ1h7j9Eg6tP6pIPHs1Ud6wrvH6Vh5aX5IbEw9XnLxIsLSTzvfT 9TmzYxDjdnIvYPRTwGHR26VLa+QRLzLrhhZqVhL6bEI+8Gc47/97AYy4Ijimrb2M nwsT6OGlvT/st+ZUg66c424wY6rcB7/Y0kG2erxeuhyuBYcGHMOgzMtFlVN6zKl9 7U+7u8cXBYkZ+SgVRJf4F8IKZy7zd7x34Ru/WGPTdBkV8ugp4m+JulYQhdKlF29N X9ahwblJq9A= =pEZf -----END PGP SIGNATURE----- --Apple-Mail=_576A2565-1EBA-414B-81C6-A8B519957671-- From nobody Mon Mar 28 16:51:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2E12D0CC for ; Mon, 28 Mar 2016 16:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJ1xMM5xzMwJ for ; Mon, 28 Mar 2016 16:50:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E887127058 for ; Mon, 28 Mar 2016 16:50:59 -0700 (PDT) Received: from [128.9.184.162] ([128.9.184.162]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2SNomkw019416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Mar 2016 16:50:49 -0700 (PDT) To: "Fred Baker (fred)" References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> From: Joe Touch Message-ID: <56F9C358.3030509@isi.edu> Date: Mon, 28 Mar 2016 16:50:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:51:00 -0000 On 3/28/2016 4:44 PM, Fred Baker (fred) wrote: > >> On Mar 28, 2016, at 4:30 PM, Joe Touch wrote: >> >> >> >> On 3/28/2016 3:21 PM, Brian E Carpenter wrote: >>> On 29/03/2016 10:36, Fred Baker (fred) wrote: >>>> >>>> On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote: >>>>> Note, however, that the idea of an offset to "jump" to the transport >>>>> header makes no sense. There's no rule that HBH header lengths never >>>>> change in transit, which means you just end up with another field that >>>>> might be inconsistent with the actual header. >>>> >>>> Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94. >>> >>> In any case, that issue is foreseen in >>> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6 >> >> Simple counterexample - quickstart (RFC4782). >> >> Intermediate routers are allowed to indicate they do not support the >> option by *deleting* it. > > There's deleting and deleting. One could move any succeeding options > forward 8 bytes (not six, as the document says), shorten the HBH header > by 8 bytes, remove the HBH option entirely if it is now empty perhaps, > and move everything else forward by 8+ bytes as well. Or, one could > overwrite the quickstart option with an 8 byte PAD option. Guess which > one I would do... There are many ways that COULD work, but unfortunately there are as many that won't. The trouble happens when (not if) this jump option is part of a header that is modified by an endpoint that knows the old option and not this jump one. There's no rule that requires that HBH headers be modified in a way that won't affect offsets, and unless the offset is mandatory-to-support for intermediate devices, the situation gets worse as new options are added. Joe From nobody Mon Mar 28 17:12:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F0C12D136 for ; Mon, 28 Mar 2016 17:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQJe88m5CKfV for ; Mon, 28 Mar 2016 17:12:08 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBF712D0DF for ; Mon, 28 Mar 2016 17:12:08 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id fe3so23221pab.1 for ; Mon, 28 Mar 2016 17:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ex+peYvimmnRL+AYXJ9aTXGUjUXjPZ1iMobxJX6IMLg=; b=Dams3JjlVYUzzNg0aEye2t4oDju5FvmYrj20JhTYYiks2vJ8fzXzDPtUtRTSM4ciyy tJKLh/f4o2dzG//2xXHR+mDF/0K/rPeho5DSnl75/oksY+4hnkCnH78HEChEu9zdQLI6 HSpF4vwYH49Zg1cu+52jxjKo937zZFNnHyuVE/21Ic9HNSkxf8fw/sL3NWoLg3ALS5S9 le0iH5lJW2Ua4YtIIrmiTXdjBrhWvIANE6Ij17pTgptrj2JSDo5jPyRm7Jns+59yu86d 9e4qjBmNs+tzEgjA4giOB/n5pk9BuAqzFhGv0YVrRs7CcgHbGOpaeML20vUDPQgIRXJY 2QTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Ex+peYvimmnRL+AYXJ9aTXGUjUXjPZ1iMobxJX6IMLg=; b=cqGYVw888uhY6ccoZWEL2YKosuiw1XNPeAYFe0QhGq+fWgiWEej/Gdc6QQ7k3UK7lu bgt8BYLLMafJyyFNlNK861U0m7hi6kr7XkVkDILashdVTwMZ2j91Z+AK1NWuoyrBCGOW UAtLvAu1ipveCLZJGyHUUUupXIdPXcG3Wzv4y9qmLBgEbGcIaSUzql/EvDncrcZ0hzgm rW5YLWxMktz/xMiH1qtpBPpHkF2zoQzJHNoQsOPVOd6VJWX/7pd4m9XN8LIhwxhkRxhB fRvH2oDWWdI7dvkNlqc6Ejucm1Lt6AqOm8ypKLn2Avg3HzGIdia2bAgYv5QIhx43ySJw NC0w== X-Gm-Message-State: AD7BkJJ57n/2SSmWtl2Kc7eJsJYXFl49CxROOVQokJhfty42udg6UGmQ+igHodqexFU6Vw== X-Received: by 10.66.66.234 with SMTP id i10mr26402870pat.114.1459210328322; Mon, 28 Mar 2016 17:12:08 -0700 (PDT) Received: from ?IPv6:2406:e007:71e7:1:28cc:dc4c:9703:6781? ([2406:e007:71e7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ql1sm38308144pac.24.2016.03.28.17.12.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 17:12:06 -0700 (PDT) To: "Fred Baker (fred)" , Joe Touch References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56F9C856.2030403@gmail.com> Date: Tue, 29 Mar 2016 13:12:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 00:12:10 -0000 On 29/03/2016 12:44, Fred Baker (fred) wrote: > >> On Mar 28, 2016, at 4:30 PM, Joe Touch wrote: >> >> >> >> On 3/28/2016 3:21 PM, Brian E Carpenter wrote: >>> On 29/03/2016 10:36, Fred Baker (fred) wrote: >>>> >>>> On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote: >>>>> Note, however, that the idea of an offset to "jump" to the transport >>>>> header makes no sense. There's no rule that HBH header lengths never >>>>> change in transit, which means you just end up with another field that >>>>> might be inconsistent with the actual header. >>>> >>>> Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94. >>> >>> In any case, that issue is foreseen in >>> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6 >> >> Simple counterexample - quickstart (RFC4782). >> >> Intermediate routers are allowed to indicate they do not support the >> option by *deleting* it. I find it disturbing that we published an RFC suggesting that, which is IMNSHO inconsistent with the intent, if not the words, in RFC2460. My distress is increased by the fact that I ballotted No Objection to it at the time. The Gen-ART reviewer picked up the issue but it was only partially fixed. Fortunately it's only Experimental. > > There's deleting and deleting. One could move any succeeding options forward 8 bytes (not six, as the document says), shorten the HBH header by 8 bytes, remove the HBH option entirely if it is now empty perhaps, and move everything else forward by 8+ bytes as well. Or, one could overwrite the quickstart option with an 8 byte PAD option. Guess which one I would do... Yes, and if overwriting with a PAD had been mandated in the RFC, we wouldn't be discussing this example. >> Note that routers that do this have no idea about the proposed >> offset-option, so this will interfere with the calculated offset. >> >> That's one example. I wonder how many other existing IPv6 HBH headers >> are *not prohibited* from changing length, being added, or being deleted >> en-route. Yes. It's a bug in RFC2460 that this ambiguity arises. Brian From nobody Mon Mar 28 17:15:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF39112D0E8 for ; Mon, 28 Mar 2016 17:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1R1s8TIqpne for ; Mon, 28 Mar 2016 17:15:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C639912D0DF for ; Mon, 28 Mar 2016 17:15:29 -0700 (PDT) Received: from [128.9.184.162] ([128.9.184.162]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2T0FHoh024853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Mar 2016 17:15:18 -0700 (PDT) To: Brian E Carpenter , "Fred Baker (fred)" References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> From: Joe Touch Message-ID: <56F9C915.9070408@isi.edu> Date: Mon, 28 Mar 2016 17:15:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56F9C856.2030403@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 00:15:31 -0000 On 3/28/2016 5:12 PM, Brian E Carpenter wrote: > Yes. It's a bug in RFC2460 that this ambiguity arises. I took it as a feature. IMO, the idea of a chain enables this feature, and I don't think it should be so quickly dismissed as potentially useful. I appreciate that not everyone agrees, though. Joe From nobody Mon Mar 28 19:25:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B102F12D1EA for ; Mon, 28 Mar 2016 19:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuqpCdJPFShp for ; Mon, 28 Mar 2016 19:25:18 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A247D12D0B3 for ; Mon, 28 Mar 2016 19:25:18 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id e6so2887878vkh.2 for ; Mon, 28 Mar 2016 19:25:18 -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; bh=GadUTZnSfiE74pFpEatoNjia2B4sySXuqvLHTQBtDXk=; b=Jql0kRSBOyMb2XTotRo2NIxjMrXo9vlsrXMVQAjx1AKEUufgEHTuQ/QS5eDVvUoniD mWDsow096igiRLdsy1oZYLKjQZb0nfu3AF8ooUN9TDun1iHhjmu9wlCS2BqU9E5Q0sEK waLowJIWssaG4ZL7tBLZr+nyLz2FZxo7Ivr1wAS9o/AjPFtLzb2QSkQ8IQCYnWaDZbs/ DxsarEMVQVV7HxKwft5HwBJV11DUt5angamyHpkOz8YNwOM3VGF4ItOBxUqaRHZSq7yL shKoaH2MK9CjHa/KxVs2CYdXm6NwXD0A71/+P7G9D3Sq6lZDkI2eB5JRYSDqbTCyHib7 0Taw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GadUTZnSfiE74pFpEatoNjia2B4sySXuqvLHTQBtDXk=; b=gxSBsAxZphArD/8+qxWtxQbpAqubUjBdMUS8HbW87AlPF4XXOoYMxiz7+6VsiSmxFp kpIG4suqPlnqih9l13hfnUdbQad+8GmOff2cHA7JwcD8NSycCuDQD10sYgkOm2vcET8o 0DnLAtyyQBPpPdcDwLxeJaNGJaqkSx172KLG9vc4exOk7vczxZfstNIdXtpQ2+Gwfzka 3ZGkaB+G3fQIdYiYsH6anQNs3nL+zhy0EL1OofTE7v6Stzp6Poqqh9dooqXAKIwSvdP8 gk3s6dXWBWOuYog1stw/ayV91A/0PR6O0jjRS/s3sX/ikWZ99uhLDOxdnyGi2wAmZyi4 B5BA== X-Gm-Message-State: AD7BkJKpZ6NwBJCcr6Np939CuzQWYHd/3cyxpsBbt25FgS9maQWTiwjXRE3KVW2FulL6bS/ceB5kHqJmUJ1jUw== MIME-Version: 1.0 X-Received: by 10.159.37.146 with SMTP id 18mr2954297uaf.140.1459218317695; Mon, 28 Mar 2016 19:25:17 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Mon, 28 Mar 2016 19:25:17 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Mon, 28 Mar 2016 19:25:17 -0700 (PDT) In-Reply-To: <56F9C915.9070408@isi.edu> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> Date: Tue, 29 Mar 2016 13:25:17 +1100 Message-ID: From: Mark Smith To: Joe Touch Content-Type: multipart/alternative; boundary=001a113e163e79e0be052f26bd33 Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 02:25:20 -0000 --001a113e163e79e0be052f26bd33 Content-Type: text/plain; charset=UTF-8 On 29 Mar 2016 11:15 AM, "Joe Touch" wrote: > > > > On 3/28/2016 5:12 PM, Brian E Carpenter wrote: > > Yes. It's a bug in RFC2460 that this ambiguity arises. > > I took it as a feature. IMO, the idea of a chain enables this feature, > and I don't think it should be so quickly dismissed as potentially useful. > So I think the question to ask about such a packets is what does the source address now mean when it arrives? Deleting information from the packet means the source address is responsible for all the field values, but it isn't possible to know that some was deleted on the way. Adding/updating is far more ambiguous. The source address really just now means that the specified device decided to send a packet and that is it. There is no way to tell what was in the original packet - everything else could have been added or replaced along the way. RH0 allowed updating in the network, however it preserved and carried the list of devices that updated the destination address. > I appreciate that not everyone agrees, though. > I wouldn't want to be troubleshooting those sorts of packets if I don't know and can't be sure if the source address of the packet is the creator of all of its contents. I think tunneling is the correct approach for "modifying" packets in the network, because it completely preserves the semantics of the inner packet's fields. Regards, Mark. > Joe > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a113e163e79e0be052f26bd33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 Mar 2016 11:15 AM, "Joe Touch" <touch@isi.edu> wrote:
>
>
>
> On 3/28/2016 5:12 PM, Brian E Carpenter wrote:
> > Yes. It's a bug in RFC2460 that this ambiguity arises.
>
> I took it as a feature. IMO, the idea of a chain enables this feature,=
> and I don't think it should be so quickly dismissed as potentially= useful.
>

So I think the question to ask about such a packets is what = does the source address now mean when it arrives?

Deleting information from the packet means the source addres= s is responsible for all the field values, but it isn't possible to kno= w that some was deleted on the way.

Adding/updating is far more ambiguous. The source address re= ally just now means that the specified device decided to send a packet and = that is it. There is no way to tell what was in the original packet - every= thing else could have been added or replaced along the way.

RH0 allowed updating in the network, however it preserved an= d carried the list of devices that updated the destination address.

> I appreciate that not everyone agrees, though.
>

I wouldn't want to be troubleshooting those sorts of pac= kets if I don't know and can't be sure if the source address of the= packet is the creator of all of its contents.

I think tunneling is the correct approach for "modifyin= g" packets in the network, because it completely preserves the semanti= cs of the inner packet's fields.

Regards,
Mark.

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

--001a113e163e79e0be052f26bd33-- From nobody Mon Mar 28 20:00:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D1C12D095 for ; Mon, 28 Mar 2016 20:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcagKCfUtaZe for ; Mon, 28 Mar 2016 20:00:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9750D12D099 for ; Mon, 28 Mar 2016 20:00:00 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u2T2xMxt014841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Mar 2016 19:59:24 -0700 (PDT) To: Mark Smith References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> From: Joe Touch Message-ID: <56F9EF8A.6090903@isi.edu> Date: Mon, 28 Mar 2016 19:59:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 03:00:02 -0000 On 3/28/2016 7:25 PM, Mark Smith wrote: > > On 29 Mar 2016 11:15 AM, "Joe Touch" > wrote: >> >> >> >> On 3/28/2016 5:12 PM, Brian E Carpenter wrote: >> > Yes. It's a bug in RFC2460 that this ambiguity arises. >> >> I took it as a feature. IMO, the idea of a chain enables this feature, >> and I don't think it should be so quickly dismissed as potentially useful. >> > > So I think the question to ask about such a packets is what does the > source address now mean when it arrives? > > Deleting information from the packet means the source address is > responsible for all the field values, That's provably not true, as per the RFC I cited previously. > but it isn't possible to know that some was deleted on the way. > > Adding/updating is far more ambiguous. Route headers are updated too. > The source address really just > now means that the specified device decided to send a packet and that is > it. There is no way to tell what was in the original packet - everything > else could have been added or replaced along the way. If that matters, it's up to the other layers to decide. That's partly why TCP and UDP include a subset of the IP header values in their checksum, but also why they do not include the entirety of the IP header including options. ... > I think tunneling is the correct approach for "modifying" packets in the > network, because it completely preserves the semantics of the inner > packet's fields. Encapsulation does that too, when honored as it is defined. Joe From nobody Tue Mar 29 01:31:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0038D12D589 for ; Tue, 29 Mar 2016 01:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnBItfVDMR-T for ; Tue, 29 Mar 2016 01:31:03 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D85212D57D for ; Tue, 29 Mar 2016 01:31:03 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D039ED7893; Tue, 29 Mar 2016 01:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=zKKSkLedSI64jONFYvQ/Bj2mCSM=; b= hUQKavS+vx4+95CVqWYLkifvHoh2U4+8rHEDga+hveOr0w6wRmxGZTc+UYp/qGx5 FrWpzJPJTFoQSWEzD17WJS5rLiExAaQAbKxW7odsgeGyhMWjisA6FKQcYWtNNF3z O4MTI92fCczuf+KKO8N/e2CpnPFVqL5vwIiVGh9IMkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=nbfMxWobnjcwaEr5LJjxs5GiiS m9px8FwsUDtErzUFbB6v/BnXtN/JKo3hrNA9wPrVC7FwD5aDkgMKHYsPCHvwPiSn hGY4ScuPdg+cs5AE8C8khmlycNIobgYATJFXJji+0Q8CO4qeuAoJBxsSO3SiOTAR EEXyRTryXMUjvl+mg= Received: from h.hanazo.no (unknown [173.38.220.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 9BC60D7884; Tue, 29 Mar 2016 01:31:02 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5913C13BB61F; Tue, 29 Mar 2016 10:31:06 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A59CFFD0-876B-4298-9051-73A6E9ED4BDD"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56F9C915.9070408@isi.edu> Date: Tue, 29 Mar 2016 10:31:05 +0200 Message-Id: References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 08:31:06 -0000 --Apple-Mail=_A59CFFD0-876B-4298-9051-73A6E9ED4BDD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii >> Yes. It's a bug in RFC2460 that this ambiguity arises. > > I took it as a feature. IMO, the idea of a chain enables this feature, > and I don't think it should be so quickly dismissed as potentially useful. > > I appreciate that not everyone agrees, though. It does break PMTUD though. Best regards, Ole --Apple-Mail=_A59CFFD0-876B-4298-9051-73A6E9ED4BDD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW+j1KAAoJEL7aWKiYQt924REP/0aBUW58z1fvZNytpv4hEOt2 EBEVEazmExFxiAgjnqXeo464OgStWLDTLLBE9k291KjY36iad9AH0AD3iRJtdvAY 7/cVhsMy6sBfO8xImz9Lfec1LMidIKIQSFSjme8Tps11tKMABkBNSc7Caek91vNO JFcXYWNzW8WrLTt1IcYTLZUcixXvF7IDFO3MQruxjw7R4WwW73o4pZLyAJgrYQpV tvp1vReYtSa7sQnfxQWEQRodD6XgQzaYGCLG9189lyUELeURGY/4hv900OaEnmRT Dss9ZbDF/H/Y/ZGCTOOQtkyn9uZomtrP1qUBn/sxgzoexQVW6iYjKJxQUZXWLyew G/kjRa19g6hou1yI7gvjX85h0vWDew7rkMnL8NqePAasQxZlnMTwU76+Q8aXvalw dnkrD0yJz8s7veWLIoFXjrQiXukvuB5yU65XlN9da9kUGhykCP9L/T2TMsoxSUHy q5RVAysBeyGo3RhiYCRICfsTGT7J1N5LGiJQgupq2U0AKzPv9bGTOw3rcOSvcgFF NjbjCtsocbfrYVcBHpgU5Ujx+2s6hvkprsZAbRPOm8Eun4ltVkom+cQEx2OegN8z jUrcBgZX7I3iYdbViddt269ZtHNkSuWITmIZOhPkFQenRlE/6vxkGpKsAmtH+NXY Wwsz9ol2xsFkQzqerA65 =Egtr -----END PGP SIGNATURE----- --Apple-Mail=_A59CFFD0-876B-4298-9051-73A6E9ED4BDD-- From nobody Tue Mar 29 02:46:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8611412D0A4 for ; Tue, 29 Mar 2016 02:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lQSJSpdhh2h for ; Tue, 29 Mar 2016 02:46:04 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED9612D12A for ; Tue, 29 Mar 2016 02:37:35 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id e185so11642211vkb.1 for ; Tue, 29 Mar 2016 02:37:35 -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; bh=1Qlwmg7aDG/erqG7Vi8ijkQMzC8Hjm1sSzm6esED1zQ=; b=CB3fHmwK6pL+sxF4kWprcFQdf74D9C5JA3C8oIj86o7eTUHgk727C6+/LYq/7HaDgI msJUcYJ2idfzHphN29BrRYsIhndARBVWJjfd74qIlJvbqnux7LNcYxiDX6cl3wvGcyc7 IX2IUEdAzarwGj3dDDa/w4PmFJ1KsFynBETiZRBlzTiMDC6XtU09H2/0SDvtvtPeFFJm 3Pm3OGnabVyIe1Zy7wg/MCtntxLaA7fhQ+7Dl8bE/+UG5zqNNB8DN8k2eZv5XhLR1eGQ FkTci4+c38dlHaq5UdAIR68azTuCF8osQfq9SUQAr3G35IjzVJiCdElnnVESHoOcePj2 g8mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1Qlwmg7aDG/erqG7Vi8ijkQMzC8Hjm1sSzm6esED1zQ=; b=VP9BAfXtmcK1Yn/jbOgEOe+I6kUfaOXFkC1T5m6Icc/vlEGaoYHgmcjBQZ8ZjBRy9X GiXbLu7Ozgk/401DgXqqTzq4Pt2lKBWkEuXrrRoCQWklD7tsTe+YeRmkLB1NQ33HY6B6 +EnUR4eXt1ivN42da0pcf0BgeoarwsTMTja4DKPY5ia192aKuy6PokasB3QT0UUi4xAY Q60OEwYurzWjEj0ddBtPv1AHbSf3IaafoFkter4uvbkHUsyHjiEZPfM4flnj77H77z4z 9GnlMSoLk6qAF/+xjc+F0eQmjTe6t2bF/198fq9TNVEHOj0EDQ9m1LLCG8AzeAlDJVCQ SBUA== X-Gm-Message-State: AD7BkJIA+6QQA+vAGXHhNsGe47hN99qAXjmlsVO3+gBGalPmmaxAYQjOAP7SzWEbTGZAl5/gb6rp7ACbJifvfQ== MIME-Version: 1.0 X-Received: by 10.31.167.195 with SMTP id q186mr585550vke.113.1459244254139; Tue, 29 Mar 2016 02:37:34 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Tue, 29 Mar 2016 02:37:34 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Tue, 29 Mar 2016 02:37:34 -0700 (PDT) In-Reply-To: References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> Date: Tue, 29 Mar 2016 20:37:34 +1100 Message-ID: From: Mark Smith To: Ole Troan Content-Type: multipart/alternative; boundary=001a11425fba689c16052f2cc713 Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 09:46:05 -0000 --001a11425fba689c16052f2cc713 Content-Type: text/plain; charset=UTF-8 On 29 Mar 2016 7:31 PM, wrote: > > >> Yes. It's a bug in RFC2460 that this ambiguity arises. > > > > I took it as a feature. IMO, the idea of a chain enables this feature, > > and I don't think it should be so quickly dismissed as potentially useful. > > > > I appreciate that not everyone agrees, though. > > It does break PMTUD though. > Which I think is because of an expectation that the device identified in the packet source address (the "sender") is responsible for creating the whole packet. It can't be a "unicast source address" field if there are multiple sources of the information in the packet. It also breaks troubleshooting methods and assumptions about the source address field that have been true for IPv6, IPv4 and many, if not all, past layer 3 protocols. One perspective on tunneling is that when it modifies the packet, it adds another source address field to record that another device, other than the original packet source device, has made additions to the packet. Regards, Mark. --001a11425fba689c16052f2cc713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 Mar 2016 7:31 PM, <otroan@= employees.org> wrote:
>
> >> Yes. It's a bug in RFC2460 that this ambiguity arises. > >
> > I took it as a feature. IMO, the idea of a chain enables this fea= ture,
> > and I don't think it should be so quickly dismissed as potent= ially useful.
> >
> > I appreciate that not everyone agrees, though.
>
> It does break PMTUD though.
>

Which I think is because of an expectation that the device i= dentified in the packet source address (the "sender") is responsi= ble for creating the whole packet. It can't be a "unicast source a= ddress" field if there are multiple sources of the information in the = packet.

It also breaks troubleshooting methods and assumptions about= the source address field that have been true for IPv6, IPv4 and many, if n= ot all, past layer 3 protocols.

One perspective on tunneling is that when it modifies the pa= cket, it adds another source address field to record that another device,= =C2=A0 other than the original packet source device, has made additions to = the packet.

Regards,
Mark.

--001a11425fba689c16052f2cc713-- From nobody Tue Mar 29 02:51:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50E112D5E7 for ; Tue, 29 Mar 2016 02:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sliaXm_ML8RA for ; Tue, 29 Mar 2016 02:51:29 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800AB12D578 for ; Tue, 29 Mar 2016 02:51:29 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id E7853D7884; Tue, 29 Mar 2016 02:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=35x+2OOzfT2MOLNfmR3kEiJ+zHA=; b= ZbOlKyFQSWWyuc9Od2Xi2YLz1VF+H6aRGlFi7iiuPUiAD1RM2omnKy+VyKq/EXDa WglUXMqUEeDrNMnOiBsAyeb+4FKb47Ey7IHKB38c4ns/V9/wz7Wl6W0u5B8xaYQ0 2bvxS6A3hOiGXEzHL4yG7ePEtUuO0NBaevVHUu/qvE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=ehdDU20j5sU2FJ01+Mm3OSMUkE Fzol35Nb2ccEq6YMPyvmlOzn/emIP2HUPvVqfn8qYjSB9tRV9y8aVo6cG6Heu2YI kOJ6kZHT2dqO5kBWSs5qkphRU7++9dwkqngVwo2qlTMjVUbV4pSwHp0GQxpAdIju afr2ucbQpPTLEJ/IU= Received: from h.hanazo.no (unknown [173.38.220.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 75654D7882; Tue, 29 Mar 2016 02:51:27 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1938713BBF46; Tue, 29 Mar 2016 11:51:33 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9B476833-44F5-4255-A25A-94BA5357B3B4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Tue, 29 Mar 2016 11:51:32 +0200 Message-Id: <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> To: Mark Smith X-Mailer: Apple Mail (2.3124) Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 09:51:31 -0000 --Apple-Mail=_9B476833-44F5-4255-A25A-94BA5357B3B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > > >> Yes. It's a bug in RFC2460 that this ambiguity arises. > > > > > > I took it as a feature. IMO, the idea of a chain enables this = feature, > > > and I don't think it should be so quickly dismissed as potentially = useful. > > > > > > I appreciate that not everyone agrees, though. > > > > It does break PMTUD though. > > >=20 > Which I think is because of an expectation that the device identified = in the packet source address (the "sender") is responsible for creating = the whole packet. It can't be a "unicast source address" field if there = are multiple sources of the information in the packet. >=20 > It also breaks troubleshooting methods and assumptions about the = source address field that have been true for IPv6, IPv4 and many, if not = all, past layer 3 protocols. >=20 > One perspective on tunneling is that when it modifies the packet, it = adds another source address field to record that another device, other = than the original packet source device, has made additions to the = packet. indeed, and is why 2460 bis states: "Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473]." cheers, Ole --Apple-Mail=_9B476833-44F5-4255-A25A-94BA5357B3B4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW+lAkAAoJEL7aWKiYQt92na0P/AnbQthyMvBM0hh3v8+O4F7H aAnSqQXVE9H3UdOGvLH7l0SZZrNSfvOGYSVgnsuJvwJFYs7djPKQ3Xw3X6eWlWhW CX/B/8k6AQjvv4ElgNClZg6yqEudS3+W95Sd+sBJePv3tJ1YF+5RCSURwCMkDrcn F9o2FXUS08IK3lKPaQDeZ7VtvprzIqtwQZYwhvUYa2MG3PekIlpjI+EeGPoSBw4T 1ZsQAmjUSrkgM/yahadKxUOllNoB3a1x+PMd0loIhK4CDw9Pd0iQ40U2tLq3QHBi K7Dz3jzDAu6s23+TLBvpnV1hs8qkkvg7n51z8qefEyscpcPJNMTXUECgRy9M4Vko uF+dbPvaHnZou9r5Sn5HfiBZctdBLlp2MrZyt+ZKHZIaaECZ+BhyGCoz2xFbbs8I fN3Hizj5j/SiSxk3LP8N56xPHTvcQuItnlKf3ABAcPGsyvUpBFSFoVD1Z3r8CI/F SRa87yVUbB95eRHpkgIQKYE197bzD3I1XnBGTSlL5hGI6JAN4gLhoCXsa2GVURy6 GTSKU0peTkptX0p0h7xxVDj6oTZ0Fr1fjcFCOVyMntlILU72R9v0iKlwITxMfSf1 IzuQdBwIqQYjfDuuuUVbr+mVPVKdqz88VCxPJdaGWc8qcRdmYz77rrDMTeuIX1gJ D+WxqPz/eWAMWfNbeu3I =6ZnE -----END PGP SIGNATURE----- --Apple-Mail=_9B476833-44F5-4255-A25A-94BA5357B3B4-- From nobody Tue Mar 29 03:18:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD0512D607 for ; Tue, 29 Mar 2016 03:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrL1SBVB5UyF for ; Tue, 29 Mar 2016 03:18:20 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0542D12D149 for ; Tue, 29 Mar 2016 03:18:20 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id k1so12648609vkb.0 for ; Tue, 29 Mar 2016 03:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kDju9YLfEH8wImYhvHzFmieZaVS0nk+1OkGn9ufif3U=; b=E8J/tCAz+UQMdEmmJlFyfjEnR9iZ7KpWK7AR4Wf+JGBzu3spHWhxSb7OWjJo6yXkRz M0qrwcny17x5OdC2apWcAfFwLEhonLAxyZImXhYiywQeQtErojrmMroUH6VftjtgUOBw cwlWmPCBOpGv8/6eod9RJ3+ai51twZmzRpiI3/9GLvIQ1B0baYuFAIPeCajb6Ummhg9j r0Pjx5NrPTsLXmVaXfFBVwf7CbeETyKYkjdPXbOG7Pty3ajH3mon+W5ebgrFEftyTmoW GURKTODijpk13IKKE7Esjg0COAHEerdnwtEQKUZQpfxIDc/crD4Z0E0f9OZhQXATHvJ1 i7eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kDju9YLfEH8wImYhvHzFmieZaVS0nk+1OkGn9ufif3U=; b=PVM3UV3PoHvQN/Za7IeZp8cW/6WZzQ2StpESyDkPfmKe+XmH0mx+sWVOJ0AC6jAXD/ Y24poxf2ACwfBjoT76u/XNfEL1NKkS1ypeUoyrTCEKixCXm06cCb8cSU5n3R2fS60r47 RTGhJ87s7OfghL0K8EWB2Y2SA2Crejntd/nO8JLdGpMSqYIpttR5jKBe9b7SybarCiMB DLI5PfgT8FmVBMtBWcb1sR3gUZJJqiWlbtpQ6+hFK5WgBHIOm7xbQRQotnqVflLOv1mH cg74DagcTSWofZhCq0IBun+o8DL0XW1qtAQSRVijmVAE4AhfCKfLKRIFgp0mB16fCrWI h09Q== X-Gm-Message-State: AD7BkJICnyjmenPSZeIrjwrzwvLJZNmokQ3u5jz3w/B1zBLV74DUkj6BMoZE3c9Ik90ekvuuwvNLC79fMYBLLQ== MIME-Version: 1.0 X-Received: by 10.31.48.216 with SMTP id w207mr716970vkw.36.1459246699145; Tue, 29 Mar 2016 03:18:19 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Tue, 29 Mar 2016 03:18:19 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Tue, 29 Mar 2016 03:18:19 -0700 (PDT) In-Reply-To: <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> Date: Tue, 29 Mar 2016 21:18:19 +1100 Message-ID: From: Mark Smith To: Ole Troan Content-Type: multipart/alternative; boundary=001a1143fd04246e9c052f2d5906 Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 10:18:21 -0000 --001a1143fd04246e9c052f2d5906 Content-Type: text/plain; charset=UTF-8 On 29 Mar 2016 8:51 PM, wrote: > > > > >> Yes. It's a bug in RFC2460 that this ambiguity arises. > > > > > > > > I took it as a feature. IMO, the idea of a chain enables this feature, > > > > and I don't think it should be so quickly dismissed as potentially useful. > > > > > > > > I appreciate that not everyone agrees, though. > > > > > > It does break PMTUD though. > > > > > > > Which I think is because of an expectation that the device identified in the packet source address (the "sender") is responsible for creating the whole packet. It can't be a "unicast source address" field if there are multiple sources of the information in the packet. > > > > It also breaks troubleshooting methods and assumptions about the source address field that have been true for IPv6, IPv4 and many, if not all, past layer 3 protocols. > > > > One perspective on tunneling is that when it modifies the packet, it adds another source address field to record that another device, other than the original packet source device, has made additions to the packet. > > indeed, and is why 2460 bis states: > "Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]." > I suppose given Joe's example experimental RFC, 2460bis should also be explicit about EHs not being able to be deleted on the trip too. Regards, Mark. > cheers, > Ole --001a1143fd04246e9c052f2d5906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 Mar 2016 8:51 PM, <otroan@= employees.org> wrote:
>
> > > >> Yes. It's a bug in RFC2460 that this ambiguity = arises.
> > > >
> > > > I took it as a feature. IMO, the idea of a chain enable= s this feature,
> > > > and I don't think it should be so quickly dismissed= as potentially useful.
> > > >
> > > > I appreciate that not everyone agrees, though.
> > >
> > > It does break PMTUD though.
> > >
> >
> > Which I think is because of an expectation that the device identi= fied in the packet source address (the "sender") is responsible f= or creating the whole packet. It can't be a "unicast source addres= s" field if there are multiple sources of the information in the packe= t.
> >
> > It also breaks troubleshooting methods and assumptions about the = source address field that have been true for IPv6, IPv4 and many, if not al= l, past layer 3 protocols.
> >
> > One perspective on tunneling is that when it modifies the packet,= it adds another source address field to record that another device,=C2=A0 = other than the original packet source device, has made additions to the pac= ket.
>
> indeed, and is why 2460 bis states:
> =C2=A0 =C2=A0"Extension headers must never be inserted by any nod= e other than the
> =C2=A0 =C2=A0source of the packet.=C2=A0 IP Encapsulation must be used= to meet any
> =C2=A0 =C2=A0requirement for inserting headers, for example, as define= d in
> =C2=A0 =C2=A0[RFC2473]."
>

I suppose given Joe's example experimental RFC, 2460bis = should also be explicit about EHs not being able to be deleted on the trip = too.

Regards,
Mark.

> cheers,
> Ole

--001a1143fd04246e9c052f2d5906-- From nobody Tue Mar 29 08:41:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2A12D8CF for ; Tue, 29 Mar 2016 08:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYCGXEl0NLMZ for ; Tue, 29 Mar 2016 08:41:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0254D12D8CD for ; Tue, 29 Mar 2016 08:41:33 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2TFeQ6K015720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2016 08:40:36 -0700 (PDT) To: otroan@employees.org References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> From: Joe Touch Message-ID: <56FAA1EA.80206@isi.edu> Date: Tue, 29 Mar 2016 08:40:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 15:41:53 -0000 On 3/29/2016 1:31 AM, otroan@employees.org wrote: >>> Yes. It's a bug in RFC2460 that this ambiguity arises. >> >> I took it as a feature. IMO, the idea of a chain enables this feature, >> and I don't think it should be so quickly dismissed as potentially useful. >> >> I appreciate that not everyone agrees, though. > > It does break PMTUD though. Only increasing the length would break PMTUD, but that's already deprecated in favor of PLMTUD - which would still work. Joe From nobody Tue Mar 29 08:44:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C958B12D923 for ; Tue, 29 Mar 2016 08:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ErsIm3fv6py for ; Tue, 29 Mar 2016 08:44:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0650F12D72A for ; Tue, 29 Mar 2016 08:44:45 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2TFhibu016486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2016 08:43:55 -0700 (PDT) To: Mark Smith , Ole Troan References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> From: Joe Touch Message-ID: <56FAA2B0.3030608@isi.edu> Date: Tue, 29 Mar 2016 08:43:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 15:44:54 -0000 On 3/29/2016 2:37 AM, Mark Smith wrote: > > On 29 Mar 2016 7:31 PM, > wrote: >> >> >> Yes. It's a bug in RFC2460 that this ambiguity arises. >> > >> > I took it as a feature. IMO, the idea of a chain enables this feature, >> > and I don't think it should be so quickly dismissed as potentially > useful. >> > >> > I appreciate that not everyone agrees, though. >> >> It does break PMTUD though. >> > > Which I think is because of an expectation that the device identified in > the packet source address (the "sender") is responsible for creating the > whole packet. It can't be a "unicast source address" field if there are > multiple sources of the information in the packet. > > It also breaks troubleshooting methods and assumptions about the source > address field that have been true for IPv6, IPv4 and many, if not all, > past layer 3 protocols. I presume then that you're then arguing that NATs shouldn't exist? (I'd be glad if that were the case, but it's clear it's not). > One perspective on tunneling is that when it modifies the packet, it > adds another source address field to record that another device, other > than the original packet source device, has made additions to the packet. Yes, but encapsulation performs a very similar function. That's why we try very hard to avoid cross-layer dependencies (though the idea of a pseudoheader in the checksum of transports breaks this) and why intermediate devices shouldn't be peeking past layer 3. So again, I'm interested to see this perspective on the "sanctity of the header chain" when nearly every other presumably "immutable" field of the header has been the subject of modification. Joe From nobody Tue Mar 29 08:45:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E805D12D959 for ; Tue, 29 Mar 2016 08:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2XnCMpNig-D for ; Tue, 29 Mar 2016 08:45:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F057112D94C for ; Tue, 29 Mar 2016 08:45:47 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2TFius3016994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2016 08:45:08 -0700 (PDT) To: Mark Smith , Ole Troan References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> From: Joe Touch Message-ID: <56FAA2F8.90703@isi.edu> Date: Tue, 29 Mar 2016 08:44:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 15:45:57 -0000 On 3/29/2016 3:18 AM, Mark Smith wrote: > > On 29 Mar 2016 8:51 PM, > wrote: >> >> > > >> Yes. It's a bug in RFC2460 that this ambiguity arises. >> > > > >> > > > I took it as a feature. IMO, the idea of a chain enables this > feature, >> > > > and I don't think it should be so quickly dismissed as > potentially useful. >> > > > >> > > > I appreciate that not everyone agrees, though. >> > > >> > > It does break PMTUD though. >> > > >> > >> > Which I think is because of an expectation that the device > identified in the packet source address (the "sender") is responsible > for creating the whole packet. It can't be a "unicast source address" > field if there are multiple sources of the information in the packet. >> > >> > It also breaks troubleshooting methods and assumptions about the > source address field that have been true for IPv6, IPv4 and many, if not > all, past layer 3 protocols. >> > >> > One perspective on tunneling is that when it modifies the packet, it > adds another source address field to record that another device, other > than the original packet source device, has made additions to the packet. >> >> indeed, and is why 2460 bis states: >> "Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]." >> > > I suppose given Joe's example experimental RFC, 2460bis should also be > explicit about EHs not being able to be deleted on the trip too. And that only HBH MAY be modified (i.e., E2E MUST NOT be modified). However, this is also going to require more than an assertion in a -bis doc; it requires issuing updates to every dependent doc that isn't compliant. Joe From nobody Tue Mar 29 11:45:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2B412E0F2 for ; Tue, 29 Mar 2016 11:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_z6bQ2xtWof for ; Tue, 29 Mar 2016 11:44:59 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA6B12E099 for ; Tue, 29 Mar 2016 11:13:12 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 01CE4D78A0; Tue, 29 Mar 2016 11:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=GhGa8cijAzbdTgPAk0UDmTlYmvU=; b= q+R6f3X1SomKyTZvC0Uq+wRonuBQ2/qFkviYShKwDTU+dox98eGkQXX3BxhGp/A8 Gvavd3cEj/AjJTRKYrMliizMzKrDAQUwdBUHXX0xJv0UJWxg9llx/sm3M4aMTAN/ q/99gRj2/RKQTuAMzbDccjPWMp0IPwnFzvIMj7aDO28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=VSLjeQCHfItBj68AN6yDltc1Aq vyv3cS0Ceuf+/cUPpvuT+6e8XfFGTpm3mRvf+c+ieROeG3PMEjSlaF+kjpwgO1rC gJ/r+nzoBfShhLzSMBUG+F48ovUESuprcN0cwCGlbz+Ss3K22hXWUIL3K5Mm+bIz HDKRnRaYmN0Zp6V/0= Received: from h.hanazo.no (unknown [195.159.234.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B879DD789D; Tue, 29 Mar 2016 11:13:11 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4358F13BE3AF; Tue, 29 Mar 2016 20:13:18 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_548CDA8E-7139-4E32-9F1E-9A83293D7215"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56FAA1EA.80206@isi.edu> Date: Tue, 29 Mar 2016 20:13:17 +0200 Message-Id: <4B4BD1F4-6381-400D-A82E-524DDAD5170B@employees.org> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <56FAA1EA.80206@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 18:45:01 -0000 --Apple-Mail=_548CDA8E-7139-4E32-9F1E-9A83293D7215 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Joe, >>>> Yes. It's a bug in RFC2460 that this ambiguity arises. >>>=20 >>> I took it as a feature. IMO, the idea of a chain enables this = feature, >>> and I don't think it should be so quickly dismissed as potentially = useful. >>>=20 >>> I appreciate that not everyone agrees, though. >>=20 >> It does break PMTUD though. >=20 > Only increasing the length would break PMTUD, but that's already > deprecated in favor of PLMTUD - which would still work. in 6man we're in the process of moving RFC1981 to Internet Standard. in your view, what should we do with this document? Best regards, Ole --Apple-Mail=_548CDA8E-7139-4E32-9F1E-9A83293D7215 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW+sW+AAoJEL7aWKiYQt9268gP/RgHVyJ51sm5KhJChqK6dsu2 QHcnPEL2sIqMJOEAAOoeNnozRwk+dlpFj0tdy1XCmZkbJTiToZ+tzO70EZd2y/1f qxJ/0iv1FemSqDm9OcuIvmSOOCkDaamSh0sjGPhVviqTD5oAy1qe3JBtguNh9ihy jseQImhXqb90uGEnxxfC720CScK9HNjpF7WImyHZTf3CpdQdQ+Xx86zXo+AH2rMg PhPCfvKW80pfzWnlPPXDhwVKhfSqOeYVUvATlSlLPORcEvmGyqFEUCvvQe3KoBCa DaHIjl+9CmF6cKUgRPVBVl/raCPaHqwgLNvZRSvFv8q0BNeSXsUhEwcNJ+DFIEa/ q+PPHyq0PV7tBnmqlUIl5LdH9oaSn4Tw0V24quhW+XEv1udB6qhXHM/2Sk5/jXfR murtdNTO53k9I4cIsK5j0Dhrbk/fYHkF4QCk9lZqXkH7yTOJH65wWWBlIGt0UNIg Qd1oUQsfjXcnMu7brgWmP6aj9NsRi0RXDTQxlkpwga3u6bECEaSJOV0+hYIjnTN2 5u9R27aCDJ2UgMYhkHGv5nTNZ6/nKHEOPXUiC1T36jILYdcerRGD4zvHPwtYdRDn wUfTOf5tTZRmskRTcccSJ5cGMuENHhg6V5rEQlSjeSKDRKShMXXg6oo97kDQNwG8 VcLyYwtulYNTaw8YsIga =qIQn -----END PGP SIGNATURE----- --Apple-Mail=_548CDA8E-7139-4E32-9F1E-9A83293D7215-- From nobody Tue Mar 29 13:02:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64C12E32A for ; Tue, 29 Mar 2016 13:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDC7wtwStiSq for ; Tue, 29 Mar 2016 13:02:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBFD12DA44 for ; Tue, 29 Mar 2016 12:25:44 -0700 (PDT) Received: from [10.123.84.190] (usc-secure-wireless-206-190.usc.edu [68.181.206.190]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2TJP0Cl018487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2016 12:25:10 -0700 (PDT) To: otroan@employees.org References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <56FAA1EA.80206@isi.edu> <4B4BD1F4-6381-400D-A82E-524DDAD5170B@employees.org> From: Joe Touch Message-ID: <56FAD68B.1030200@isi.edu> Date: Tue, 29 Mar 2016 12:24:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <4B4BD1F4-6381-400D-A82E-524DDAD5170B@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 20:02:16 -0000 On 3/29/2016 11:13 AM, otroan@employees.org wrote: > Joe, > >>>>> Yes. It's a bug in RFC2460 that this ambiguity arises. >>>> >>>> I took it as a feature. IMO, the idea of a chain enables this feature, >>>> and I don't think it should be so quickly dismissed as potentially useful. >>>> >>>> I appreciate that not everyone agrees, though. >>> >>> It does break PMTUD though. >> >> Only increasing the length would break PMTUD, but that's already >> deprecated in favor of PLMTUD - which would still work. > > in 6man we're in the process of moving RFC1981 to Internet Standard. > in your view, what should we do with this document? I wasn't aware we were still bothering differentiating tracks within standards-track (does anyone really care?), but if we are, then we might reconsider whether to shift this to IS. IS indicates a level of confidence that I think we don't have, given the level to which ICMPs are filtered and the potential of the techniques in that RFC to result in blackholes if not otherwise addressed. Finally, I am astounded that this change would occur in 6man. This is not an IPv6-specific doc . Any such change should happen in INTAREA IMO. IETF WGs have some serious issues with the concept of scope, IMHO. Joe From nobody Tue Mar 29 13:07:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06E12D147 for ; Tue, 29 Mar 2016 13:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.531 X-Spam-Level: X-Spam-Status: No, score=-114.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F8X9Akt2q0m for ; Tue, 29 Mar 2016 13:07:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D2812DB17 for ; Tue, 29 Mar 2016 12:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2915; q=dns/txt; s=iport; t=1459279827; x=1460489427; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eorW2PWiGYGVD45tc37RIyGh0Np6iLDMvb0f2qgdCkQ=; b=Z5thEiwolW8NBZWWkco1ij2XZIBo823+rrUCDJXoirKyZWC+STmlmrU0 1Db+/dfZpaJsv30WZvikwiXHzFbrL+IY13/ncW2cTnZsTE2Agf/OytPcY 1hTWjNc4rxJIUzZESBmI7q/coxUmnWj9tmOpt/idthVmPtmtrYsJTmVWX k=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAgDJ1vpW/4wNJK1dDoMgU30GungOg?= =?us-ascii?q?XAdhXACgTY4FAEBAQEBAQFkJ4RBAQEBAwF5BQsCAQgYLjIlAgQOBQ6IEQgOwC8?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQENBASIEIJRh2iCKwWXbAGDHoFmbYgVjw2PD?= =?us-ascii?q?gEeAUODKjtsh0F+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,412,1454976000"; d="asc'?scan'208";a="87976791" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2016 19:30:26 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u2TJUQll018951 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Mar 2016 19:30:26 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Mar 2016 14:30:25 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Tue, 29 Mar 2016 14:30:25 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRiTnjuC9r2YC2skGBfdtx5Op9bQ== Date: Tue, 29 Mar 2016 19:30:25 +0000 Message-ID: References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <56FAA1EA.80206@isi.edu> <4B4BD1F4-6381-400D-A82E-524DDAD5170B@employees.org> <56FAD68B.1030200@isi.edu> In-Reply-To: <56FAD68B.1030200@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_9F41A646-2F03-4262-942C-9BA31A0B8869"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 20:07:14 -0000 --Apple-Mail=_9F41A646-2F03-4262-942C-9BA31A0B8869 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Mar 29, 2016, at 12:24 PM, Joe Touch wrote: >=20 >=20 >=20 > On 3/29/2016 11:13 AM, otroan@employees.org wrote: >> Joe, >>=20 >>>>>> Yes. It's a bug in RFC2460 that this ambiguity arises. >>>>>=20 >>>>> I took it as a feature. IMO, the idea of a chain enables this = feature, >>>>> and I don't think it should be so quickly dismissed as potentially = useful. >>>>>=20 >>>>> I appreciate that not everyone agrees, though. >>>>=20 >>>> It does break PMTUD though. >>>=20 >>> Only increasing the length would break PMTUD, but that's already >>> deprecated in favor of PLMTUD - which would still work. >>=20 >> in 6man we're in the process of moving RFC1981 to Internet Standard. >> in your view, what should we do with this document? >=20 > I wasn't aware we were still bothering differentiating tracks within > standards-track (does anyone really care?), but if we are, then we = might > reconsider whether to shift this to IS. Perhaps. https://tools.ietf.org/html/rfc6410 > IS indicates a level of confidence that I think we don't have, given = the > level to which ICMPs are filtered and the potential of the techniques = in > that RFC to result in blackholes if not otherwise addressed. >=20 > Finally, I am astounded that this change would occur in 6man. This is > not an IPv6-specific doc . Any such change should happen in INTAREA = IMO. > IETF WGs have some serious issues with the concept of scope, IMHO. RFC 1981 is specific to IPv6. RFC 4821, as you say, is about TCP and = transports that operate like it. --Apple-Mail=_9F41A646-2F03-4262-942C-9BA31A0B8869 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVvrX0UayAOS/EQ8MAQKEBw//dITdM75BN8c0aG8rTA7jMWhl1napB1LH i83moA7x+guVj1sxW7RQE7VaPDIKdusjsIJu4ugAPc5LMD1PRpFQPGieJO/gNHMd VpZWARkT1DK0p2i622af87VpsVsdQrHGcw0Hszod5414i/Q5saqUFDodW5ISsmhJ jmx74NzpibHQ1Ukdl34oe6vwBd9fvGhowobgN0N77FPR19GCQQ3383z1pq5oitbI i2b7lv5YSILvdtGYW1xTCEkAUqp8lKgfyhAnsvBAzb2VG9UkYkBENJJvjWo5umIP bajAzx528Lyn/3Xl4Om3pqZpX+yo4gsiMuatRZ5Hvbryq4XD7RRXIPelAOPL60wk wELzqD5NzloOJyZQPkGXT9jqAoIfI9O8cSDHARYZXCnoNuSv7Kro8cgL75nfMO0m 3nPnUnWAcX0luK752wpvk6v4MDiS9MWcDdJj/yZgwZbCOk9KKbyCKwEmz8DmrTI2 NqEWf0zoicTP9uYupBR9xFb1c8MIrRC1SXgf3QwcttLvFURLIJXvqLpheuR3e9R5 63ucyDGAM4xmz4xc16OQLdzhPjcapSYtKnblKsxWKRFnrZigVtExjRgAL4Uj7131 MgDS5qFiNP7XF+vKHa3WubnEmCMBlrS+jUW8CqkNg7m/M8biXvh/9MKfI1toyJ5o 1/C+ZrAYTO8= =4HNL -----END PGP SIGNATURE----- --Apple-Mail=_9F41A646-2F03-4262-942C-9BA31A0B8869-- From nobody Tue Mar 29 13:31:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC3C12DD8D for ; Tue, 29 Mar 2016 13:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbQ7fMEXMMBT for ; Tue, 29 Mar 2016 13:31:08 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4136C12E08C for ; Tue, 29 Mar 2016 12:54:16 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id k1so33662587vkb.0 for ; Tue, 29 Mar 2016 12:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rjf66xQ8wePjhmI3d0MYd7a/9HQOb6HmrW4wXRAnqHw=; b=t29suolQVPZLQPFkTXi2O1rf26rIl6XPdNH4wUm4CJ+egyY+LaFfK9O6gli89Ud5J5 RfPWbLTeW60wrt7uuEsV8Lj0Dj973VoQtdQoKJRyfEOHYUcH+H/hpoSyXevnUy27xP3T Er/Jg6ReQORxusMfTnuKKzPEiMB6b5SZ8zLTFmZK7rQqxrpm1u+tty4tgr8BoOrya3yc bIYS4Rz62VCMGs49/w9GYGVYk+hg3qUVAlJxNuaivmm03Dv/dOxfAXXQ1vh75q6WxgW4 HnvtjH+DnK3rKqlucPjrdC3cvzG31449coWFpiPrhtv8wfe+fOb8rLGUq+klSycszjZG 9u0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rjf66xQ8wePjhmI3d0MYd7a/9HQOb6HmrW4wXRAnqHw=; b=Eetsrrt3W3mfHxuiiYHUdcJG9H1PBmyRXNSrYxziUj9JbWdCi7XGh/F8dJHQJqEWZ7 G0INGyXlO9yZ7DA6eX0x3yu/rw6rsNb+YLWszWfSYQxblOjtS8nLpwgkxx9ZVLcue1bl OYBVi5ctwByYHVgEjeuLflQxzEI2ka9HgdOqztKB3N+esIUY1UNP3U7YviKOe3rIvBkV EkeRlw9SwO9co9SfFgr3FnBwUdJ49jgkwaRAPruwrltZpbwGrjt4e1FuSr7puPLzlqgE KHf2gFU+HZsGRQVNE9jFxhR7/vfeAkhJ2kY+SYYVv6j1cn/1bjHntMap1AGQfm7BJOCR ov+Q== X-Gm-Message-State: AD7BkJKw6p6f7vfMMJlgQNmAh3k+6J2tRF7ygXLOpQVZyNo4VLEQ1dAYSpw/ddmX/Ha1zvmwyE//ZEPbYRF+vA== X-Received: by 10.176.2.49 with SMTP id 46mr2683218uas.39.1459281255374; Tue, 29 Mar 2016 12:54:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.32.228 with HTTP; Tue, 29 Mar 2016 12:53:45 -0700 (PDT) In-Reply-To: <56FAA2B0.3030608@isi.edu> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <56FAA2B0.3030608@isi.edu> From: Mark Smith Date: Wed, 30 Mar 2016 06:53:45 +1100 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 20:31:10 -0000 On 30 March 2016 at 02:43, Joe Touch wrote: > > > On 3/29/2016 2:37 AM, Mark Smith wrote: >> >> On 29 Mar 2016 7:31 PM, > > wrote: >>> >>> >> Yes. It's a bug in RFC2460 that this ambiguity arises. >>> > >>> > I took it as a feature. IMO, the idea of a chain enables this feature, >>> > and I don't think it should be so quickly dismissed as potentially >> useful. >>> > >>> > I appreciate that not everyone agrees, though. >>> >>> It does break PMTUD though. >>> >> >> Which I think is because of an expectation that the device identified in >> the packet source address (the "sender") is responsible for creating the >> whole packet. It can't be a "unicast source address" field if there are >> multiple sources of the information in the packet. >> >> It also breaks troubleshooting methods and assumptions about the source >> address field that have been true for IPv6, IPv4 and many, if not all, >> past layer 3 protocols. > > I presume then that you're then arguing that NATs shouldn't exist? (I'd > be glad if that were the case, but it's clear it's not). > Yes. >> One perspective on tunneling is that when it modifies the packet, it >> adds another source address field to record that another device, other >> than the original packet source device, has made additions to the packet. > > Yes, but encapsulation performs a very similar function. That's why we > try very hard to avoid cross-layer dependencies (though the idea of a > pseudoheader in the checksum of transports breaks this) and why > intermediate devices shouldn't be peeking past layer 3. > I agree that encapsulation/tunnelling is performing that function. I'm observing that when tunnelling occurs an additional source address field is added that records the identity of the device that added the tunnelling encapsulation. That address and the tunnelling protocol creates a very clear boundary between what the original host sent and what has been added and by whom during tunnelling/encapsulation. > So again, I'm interested to see this perspective on the "sanctity of the > header chain" when nearly every other presumably "immutable" field of > the header has been the subject of modification. > So when packets are modified while they travel through the network, the identity of the modifier isn't recorded, which makes troubleshooting harder if the modifications fail. So my philosophy is that packet modification in the network should be minimised as much as possible, even though some fields are mutable because they're not covered by e.g, TCP or UDP pseudoheader checksums. That really only leaves the hop count field as one that is always going to be modified. I think Flow label and TC are the other two that are mutable. In the case of flow label, there are fairly strict rules on when they can be modified by the network (if FL=0). TC has no strict rules, however within in a network the devices that may modify TC are usually limited to the edge and are well known as performing that role, making them easier to identify if they're broken. Regards, Mark. > Joe From nobody Tue Mar 29 14:34:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA12D12DBEE for ; Tue, 29 Mar 2016 14:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUoCBsjyxtID for ; Tue, 29 Mar 2016 14:34:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A476212DD22 for ; Tue, 29 Mar 2016 14:17:35 -0700 (PDT) Received: from [10.123.84.190] (usc-secure-wireless-206-190.usc.edu [68.181.206.190]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u2TLGtSW017782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2016 14:16:56 -0700 (PDT) To: "Fred Baker (fred)" References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <56FAA1EA.80206@isi.edu> <4B4BD1F4-6381-400D-A82E-524DDAD5170B@employees.org> <56FAD68B.1030200@isi.edu> From: Joe Touch Message-ID: <56FAF0C6.7060509@isi.edu> Date: Tue, 29 Mar 2016 14:16:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 21:34:13 -0000 On 3/29/2016 12:30 PM, Fred Baker (fred) wrote: > RFC 1981 is specific to IPv6. Sorry - text was too small and I mapped this to 1191. Agreed- this is IPv6. Joe From nobody Tue Mar 29 14:40:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F5B12DA54 for ; Tue, 29 Mar 2016 14:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cjWS2-JQMFU for ; Tue, 29 Mar 2016 14:40:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23E212D121 for ; Tue, 29 Mar 2016 14:30:22 -0700 (PDT) Received: from [10.123.84.190] (usc-secure-wireless-206-190.usc.edu [68.181.206.190]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2TLTTG0021610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2016 14:29:39 -0700 (PDT) To: "Fred Baker (fred)" References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <56FAA1EA.80206@isi.edu> <4B4BD1F4-6381-400D-A82E-524DDAD5170B@employees.org> <56FAD68B.1030200@isi.edu> <56FAF0C6.7060509@isi.edu> From: Joe Touch Message-ID: <56FAF3B8.3040609@isi.edu> Date: Tue, 29 Mar 2016 14:29:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56FAF0C6.7060509@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 21:40:52 -0000 PS - what misdirected me was the idea that this would go to IS when it referred to an outdated version of the IPv6 spec. Given it predates RFC2460, it seems odd to have it go IS. Joe On 3/29/2016 2:16 PM, Joe Touch wrote: > > > On 3/29/2016 12:30 PM, Fred Baker (fred) wrote: >> RFC 1981 is specific to IPv6. > > Sorry - text was too small and I mapped this to 1191. Agreed- this is IPv6. > > Joe > From nobody Tue Mar 29 14:55:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8201912D52B for ; Tue, 29 Mar 2016 14:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.531 X-Spam-Level: X-Spam-Status: No, score=-114.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58y3YjeDp4y2 for ; Tue, 29 Mar 2016 14:55:51 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07BA12D523 for ; Tue, 29 Mar 2016 14:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1955; q=dns/txt; s=iport; t=1459288549; x=1460498149; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=q8637eBjWVGl8m8dzdSDF/mEDcad0sp4oiApM1xiv24=; b=T5/X3DY1l24rWvo8Sh+EyJZsjc94yUIwHwdeuafwGbK7lC0KeJWldBrT X0C0tHqT+SbhcJsaygBWmtgTDek415K+H2MwBBJ50EqhSKL8OXkLymskA l2D7TnGzBoIQuRRPp5CxeEReFO4XFzaYZse8gmzOkIvJCh6hYd+tQeFRj w=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+BQDI+PpW/4YNJK1dDoMlgVAGuweBc?= =?us-ascii?q?IYNAoE7ORMBAQEBAQEBZCeEQQEBAQMBeQULAgEIGC4yJQIEDgUOiBEIwAkBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQENCIgQCIJJh2iCKwEEl2wBgx6BZokCgVAWjSeGE?= =?us-ascii?q?oh8ASEBQIMqO2yHQX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,413,1454976000"; d="asc'?scan'208";a="253502835" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2016 21:55:48 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2TLtmnb028976 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Mar 2016 21:55:48 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Mar 2016 16:55:47 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Tue, 29 Mar 2016 16:55:47 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRiTnjuC9r2YC2skGBfdtx5Op9bQ== Date: Tue, 29 Mar 2016 21:55:47 +0000 Message-ID: <6F5C3AF5-3122-433A-BC6D-845CA1489AB5@cisco.com> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <56FAA1EA.80206@isi.edu> <4B4BD1F4-6381-400D-A82E-524DDAD5170B@employees.org> <56FAD68B.1030200@isi.edu> <56FAF0C6.7060509@isi.edu> <56FAF3B8.3040609@isi.edu> In-Reply-To: <56FAF3B8.3040609@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_2122FB8A-F572-4109-B3B1-E2A787C12536"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 21:55:52 -0000 --Apple-Mail=_2122FB8A-F572-4109-B3B1-E2A787C12536 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would assume the reference needs to be updated, just as 2460bis is an = update. > On Mar 29, 2016, at 2:29 PM, Joe Touch wrote: >=20 > PS - what misdirected me was the idea that this would go to IS when = it > referred to an outdated version of the IPv6 spec. Given it predates > RFC2460, it seems odd to have it go IS. >=20 > Joe >=20 > On 3/29/2016 2:16 PM, Joe Touch wrote: >>=20 >>=20 >> On 3/29/2016 12:30 PM, Fred Baker (fred) wrote: >>> RFC 1981 is specific to IPv6. >>=20 >> Sorry - text was too small and I mapped this to 1191. Agreed- this is = IPv6. >>=20 >> Joe >>=20 --Apple-Mail=_2122FB8A-F572-4109-B3B1-E2A787C12536 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVvr540ayAOS/EQ8MAQIWlQ/+Nw0xuTi+CFzjo1WYcOFr+9Sk0QFl6lDL SmLpKZueM3MHdzW5J97swOdIixGBF2DXGizruw6uxqLKMOmv877fnJrFsLjCal8W 4J3ur6EcFg7AIrSgTBrnoh6mohfQBaOOs8zABXdUkkIhpO4wVKFsmi6+4HpI9Qke L8n6JuB3scu+tJEGmezxhedhe/+7uzoGlQ3uhK8mzHc87Fltl3Y4I6nwf/2Ba5fG p+rWRwQvuKh4PB0hXmLVba/ZjNXq4LDhMwdEXy9k5qf5NGXKjO/2y1lAQ04hQjmu yvmvCj3JW6hmc63qEkgpaumkidnUw3WeugjwpNgUYKc7RtYMf146+ZjXq6PVMsVu j9tV/XUxHXt1CRwsDw1Y0KnsuJL2NoGCrBDkchJoB5OhyC8gLN0TVIRFwLQcnI/k kmHK56UlZHqKRDKmzLf5e6Vk94bFuG8rzJOajn35nTzZxVFow6WNet/Wb+mG2J2R J/o3Snb4P5euOCANGAZSB16TI5twaLcEdL2kWbsg2Pw6b18ltosJvCLwdWbKo0sJ KjiZS1M17+Yv8agHNJU0JGEh4JLFUQpH7+AkXkwMcI94sCMGpCAHcLXozFec9qMG r415i2z9tt0Sglrur90HDKCAoqhtRXMATqvhtTHuf5ig8MXsrlKJrYLflckVGnhx G7oYZUSrcFY= =RC1+ -----END PGP SIGNATURE----- --Apple-Mail=_2122FB8A-F572-4109-B3B1-E2A787C12536-- From nobody Tue Mar 29 15:19:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A6F12D996 for ; Tue, 29 Mar 2016 15:19:21 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcDUUFLE8_Dq for ; Tue, 29 Mar 2016 15:19:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E8112D9D4 for ; Tue, 29 Mar 2016 15:19:18 -0700 (PDT) Received: from [10.0.0.189] (unknown [176.245.35.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 399E78088E; Wed, 30 Mar 2016 00:19:14 +0200 (CEST) To: Joe Touch , otroan@employees.org References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <56FAA1EA.80206@isi.edu> <4B4BD1F4-6381-400D-A82E-524DDAD5170B@employees.org> <56FAD68B.1030200@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56FAF439.3070305@si6networks.com> Date: Tue, 29 Mar 2016 23:31:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FAD68B.1030200@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 22:19:21 -0000 On 03/29/2016 09:24 PM, Joe Touch wrote: > I wasn't aware we were still bothering differentiating tracks within > standards-track (does anyone really care?), but if we are, then we might > reconsider whether to shift this to IS. > > IS indicates a level of confidence that I think we don't have, given the > level to which ICMPs are filtered and the potential of the techniques in > that RFC to result in blackholes if not otherwise addressed. One could easily s/ICMPs/EHs/ in your statement.... > Finally, I am astounded that this change would occur in 6man. This is > not an IPv6-specific doc . Any such change should happen in INTAREA IMO. Why so? I think 6man is where the IPv6 std track expertise is. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492