From nobody Sun Mar 1 19:45:37 2015 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 001111A001A for ; Sun, 1 Mar 2015 19:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 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, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] 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 9MAxgWE_ANmU for ; Sun, 1 Mar 2015 19:45:34 -0800 (PST) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CDC1A0019 for ; Sun, 1 Mar 2015 19:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1425267933; bh=0AN4UjBTVeFdU9BcbP4uKUrtm15FYTntP3YaYZ0vgSI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=OAdYFhEQ132nmdnyvuV6c3JsG0a1raYAyy4PNEBRsoUDLZjHfaoPnxWAQAVRB0Epl9K7pHCLUJ9jbDNPPS16m6hhhOEnXD2+BzvVqXYJsDQrKT+u1pAbmH3ekB2GWiuAMyzZSuFA/C/KtnVBhBopzaHSdM2PBNDhHj86z1g6JR9lczXCVNSmTmSDlkb3rzsDoOQk2p2/yn4QY4aKgWXyxbAQRfxaAVJiAbEvIWXVEI3TgbRLuE8APD144DgHyA0P2rWhlZ5Vsc73EoOyydHeYlw1L1Zz0f2FAJKhQuQNVvJjPBgn1NaSVdccplsG6Zm7EJq4t/jTjnnJL101DdoPdw== Received: from [98.139.215.140] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2015 03:45:33 -0000 Received: from [98.139.212.248] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2015 03:45:33 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 02 Mar 2015 03:45:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 722889.92026.bm@omp1057.mail.bf1.yahoo.com X-YMail-OSG: RNlZxBAVM1nWJ45xMg5TYvLPuykEG8P7kyLgJqdChJHnr15AylZBkgkHgH0xI7r PjPPRaIaToEfVVr1MMUE2.5OTGzskMTFVwPkv0xpRN_eb04MqV2aHadMVLM.owKVmFSQ9jj0LjKc t0VC1ZaF0rj9V.cH2LrVs7BrNY0F2crNNVBye9dO_8O8fhD1bTyu8daEWGcntEu6C8.Dar3WzoAD UUxC9GdUgSqekk8OTVnNlWxuDohKUn753fGbds_OEYyT8Gt59QA8hD8a0fzu5z.DqKTEI2H.vh4v k.QcFyYVFh8.lJjsazutyLaYiyq0fuzLBLLSbnCIkz4UU2LUUAJz.Qcmxn.FBrkQlaI1M10jed2m zGKIM_ABIzuaUmfTwnY6FGEhDIoCv5kqTw8nzYdLeHMUH4bmRQuonL_Huvbw3MomiX6S7XxS7nqc FusPtO30wGQ.oJLktjJqvN0I3jxd3cYU38SVhuyPvONuozVxsYZF8.Le5exuuOvRdVY4C9nB27C4 zFCSjzEIK8vKuqWw- Received: by 76.13.26.109; Mon, 02 Mar 2015 03:45:33 +0000 Date: Mon, 2 Mar 2015 03:45:32 +0000 (UTC) From: Mark ZZZ Smith To: "Eric Vyncke (evyncke)" , "Fred Baker (fred)" , "v6ops@ietf.org" Message-ID: <641016955.1182330.1425267932506.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 03:45:36 -0000 Hi Eric, ----- Original Message ----- From: Eric Vyncke (evyncke) To: Mark ZZZ Smith ; Fred Baker (fred) ; "v6ops@ietf.org" Cc: "draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org" Sent: Saturday, 28 February 2015, 0:21 Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie Mark, Dan and Ray Thanks a lot for your comments. BTW, this is kind of an 'old' draft presented in Honolulu. Brain Carpenter brought my attention to section 8.2 of RFC 6883 "IPv6 Guidance for Internet Content Providers" which summarizes the same issue in one single paragraph. So, I am not sure whether this specific I-D should continue? On one side, it is repetition but on the other it makes this issue glaring and much more visible. / Reviewing the paragraph that Brian pointed out and your -00 version again= , I think there is value in having both. I see RFC 6883 as a high level gui= dance document, identifying and summarising all related issues to providing= content over IPv6, where as your document is providing more lower level de= tails of one of the specific issues identified in RFC 6883. I've found that it is commonly useful enough to have a high level understan= ding of a particular issue to be able to make value judgements on the metho= d or to identify likely causes of problems before investing time in the det= ails. Having the details available is of course useful if you have to inves= t time in the details. In other words, the audience for RFC 6883 might not = always be the same as the audience for your ID. Regards, Mark. Anyway, I am updating it with your comments (and others) then upload it. Regards and thanks -=C3=A9ric On 12/02/15 04:08, "Mark ZZZ Smith" wrote: >I think this is a good draft, and I agree with what it says, however I >think perhaps it really belongs in the httpbis working group, as they're >the HTTP experts? > >The only other thought I've had is that it might be worth documenting >that MPTCP shouldn't suffer from this problem as if an application cares >about IP addresses, then only the first subflow's IP addresses are >exposed to the application, even if a later subflow uses a different >address family. There may be a little confusion in this area as MPTCP and >HE might appear to be fairly similar at face value (and I think HE >techniques applied to initial MPTCP subflow setup might improve the MPTCP >establishment performance.). > >Regards, >Mark. > > >----- Original Message ----- >From: "fred@cisco.com" >To: v6ops@ietf.org >Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org >Sent: Wednesday, 11 February 2015, 23:47 >Subject: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie > >A new draft has been posted, at >http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. >Please take a look at it and comment. > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Mar 1 23:17:00 2015 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 1C6FE1A1A66 for ; Sun, 1 Mar 2015 23:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8dFtzjWwY4V2 for ; Sun, 1 Mar 2015 23:16:56 -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 611761A004A for ; Sun, 1 Mar 2015 23:16:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPT64706; Mon, 02 Mar 2015 07:16:54 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Mar 2015 07:16:53 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 2 Mar 2015 15:16:44 +0800 From: Sheng Jiang To: Brian E Carpenter , "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] Inviting discussion: draft-liu-v6ops-running-multiple-prefixes Thread-Index: AQHQT8u8J8lmkJBw0E60yhTq/eTBy50IzY4g Date: Mon, 2 Mar 2015 07:16:43 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B053D24@nkgeml512-mbx.china.huawei.com> References: <8C48B86A895913448548E6D15DA7553B0612B394@xmb-rcd-x09.cisco.com> <54EBCA81.30301@gmail.com> In-Reply-To: <54EBCA81.30301@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Inviting discussion: draft-liu-v6ops-running-multiple-prefixes 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, 02 Mar 2015 07:16:58 -0000 Pk9uIDIwLzAyLzIwMTUgMDk6NTQsIEZyZWQgQmFrZXIgKGZyZWQpIHdyb3RlOg0KPj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS12Nm9wcy1ydW5uaW5nLW11bHRpcGxlLXBy ZWZpeGVzDQo+PiAgICJDb25zaWRlcmF0aW9ucyBmb3IgUnVubmluZyBNdWx0aXBsZSBJUHY2IFBy ZWZpeGVzIiwgQmluZyBMaXUsIFNoZW5nDQo+PiAgIEppYW5nLCBZYW5nIEJvLCAyMDE0LTEwLTEx LA0KPj4NCj4+IFRoaXMgZHJhZnQgd2FzIHByZXBhcmVkIGZvciBJRVRGIDkxLCBidXQgZGlkbid0 IGdldCBkaXNjdXNzZWQgaW4gcGFydCBiZWNhdXNlDQo+PmEgbnVtYmVyIG9mIENoaW5lc2UgcGFy dGljaXBhbnRzIGRpZG4ndCBtYWtlIGl0IHRvIEhvbm9sdWx1IGZvciBhIE1vbmRheQ0KPj5tZWV0 aW5nLiBJcyB0aGVyZSBpbnRlcmVzdCBpbiBkaXNjdXNzaW5nIGl0IGF0IElFVEYgOTI/DQo+DQo+ SSB0aGluayB3ZSBzaG91bGQgZGlzY3VzcyB3aGV0aGVyIHRoZSBXRyB3YW50cyB0byBwdWJsaXNo DQo+YSBiYWNrZ3JvdW5kIGRvY3VtZW50IG9uIHRoaXMgdG9waWMuIFRoaXMgaXMgb25lIG9mIHRo ZSBhc3BlY3RzDQo+b2YgdjYgdGhhdCBzZWVtcyB0byBiZSBxdWl0ZSB1bmV4cGVjdGVkIGJ5IGN1 cnJlbnQgb3BlcmF0b3JzDQo+b2Ygc2l0ZSBuZXR3b3Jrcy4gRWR1Y2F0aW5nIHRoZW0gc2VlbXMg ZGVzaXJhYmxlLg0KDQpHaXZpbmcgdGhpcyBpcyBhIG1ham9yIGRpZmZlcmVudGlhIGZyb20gSVB2 NCBhbmQgbWFueSBvcGVyYXRvcnMgd291bGQgaGF2ZSBwcm9ibGVtcyB3aXRob3V0IGtub3dpbmcg DQoNCj5UaGUgb25seSB0aGluZw0KPmlzLCB0aGlzIHJlYWxseSBpcyBvbmx5IGEgYmFja2dyb3Vu ZCBkb2N1bWVudCwgbm90IGEgImhvdyB0byINCj5ndWlkZQ0KDQpJIGd1ZXNzIHRoaXMgaXMgYSBk aXJlY3Rpb24gdGhhdCB0aGUgY3VycmVudCBkb2N1bWVudCBzaG91bGQgYmUgaW1wcm92ZWQgdG93 YXJkLiBJdCB3YXMgY3JlYXRlZCBhcyBhIG1peHR1cmUgb2YgYmFja2dyb3VuZCBpbmZvcm1hdGlv biwgImhvdy10byIgZm9yIG9wZXJhdG9ycyBhbmQgInByb2JsZW1zIiBmb3Igc3RhbmRhcmQgYWN0 aW9ucy4gRm9jdXNpbmcgb24gYmFja2dyb3VuZCB3b3VsZCBnaXZlIHRoZSBkb2N1bWVudCBtdWNo IGNsZWFyZXIgcHVycG9zZS4NCg0KPi0gYW5kIGl0IGNpdGVzIDcgSS1Ecywgd2hpY2ggaXNuJ3Qg aWRlYWwgZm9yIGFuIGluZm9ybWF0aW9uYWwNCj5kb2N1bWVudC4gV2lsbCBpdCBoZWxwIHRob3Nl IG9wZXJhdG9ycywgb3Igd2lsbCB0aGV5IHRocm93IGl0DQo+b24gdGhlICJ0b28gaGFyZCIgaGVh cD8NCg0KTW9zdCBvZiB0aGVzZSBJLURzIGFyZSAicHJvYmxlbXMiIGZvciBzdGFuZGFyZCBhY3Rp b25zLiBUaGV5IGFyZSBvbiB0aGVpciBvd24gcHJvZ3Jlc3Nlcy4gU2luY2Ugd2Ugd2FudCB0byBm b2N1cyBvbiBiYWNrZ3JvdW5kIG9ubHksIHRoZXNlIEktRHMgd291bGQgYmUgcmVtb3ZlZCBjZXJ0 YWlubHkuDQoNCj5TbywgaWYgd2UgZ2l2ZSBpdCBhZ2VuZGEgdGltZSwgSSBzdWdnZXN0IHdlIGRp c2N1c3MgdGhlIHB1cnBvc2UNCj5vZiB0aGUgZG9jdW1lbnQsIG5vdCBpdHMgZGV0YWlscy4NCg0K R29vZCBhZHZpY2UuIFdlIHdpbGwgZm9sbG93LiBUaGFua3MuDQoNCkJlc3QgcmVnYXJkcywNCg0K U2hlbmcNCg0KPiAgICAgQnJpYW4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Mon Mar 2 01:35:24 2015 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 3700E1A7022 for ; Mon, 2 Mar 2015 01:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 h7TkrU0t_kFB for ; Mon, 2 Mar 2015 01:35:12 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AC91A700F for ; Mon, 2 Mar 2015 01:35:12 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 54FE91B819E; Mon, 2 Mar 2015 10:35:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 36412C8114; Mon, 2 Mar 2015 10:35:10 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Mon, 2 Mar 2015 10:35:10 +0100 From: To: "STARK, BARBARA H" Thread-Topic: comments on draft-ietf-v6ops-mobile-device-profile-19 Thread-Index: AdBTanJNvJBbZ0pnRLOCo1ESaXFM+ABW6ITw Date: Mon, 2 Mar 2015 09:35:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004917F6D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <2D09D61DDFA73D4C884805CC7865E61130F42835@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F42835@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19 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, 02 Mar 2015 09:35:21 -0000 Hi Barbara, Thank you for the comments.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de STARK, BARBARA= H > Envoy=E9=A0: samedi 28 f=E9vrier 2015 19:44 > =C0=A0: v6ops@ietf.org > Objet=A0: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19 >=20 > I've read through this draft and have some comments. I focused mostly on > "must" requirements, because it's always easy to justify not doing a > "should". The authors are free to change nothing as a result of my > comments. I'm not voicing opposition. I'm simply expressing in more detai= l > why I would not recommend to my employer (or any other service provider) > that they use this draft as an RFC reference without very careful thought > as to the desirability of each requirement. [Med] Why is this unique to this draft? Your statement applies for every do= cument of this kind. > Barbara >=20 > --------- > Note that the term "[3GPP] cellular host" includes a wide variety of > devices, including those which are considered "IoT" or "M2M" (such as > tracking/locating devices, health monitors, eReaders, automobiles, etc.). > Some of these devices are intended (by the service provider who procures > them) to be used with a service that does not support roaming to other > providers' networks. Some are single function devices, where the functio= n > is fully specified at time of procurement. These devices are generally > intended to be as low-complexity and energy-efficient as possible. [Med] M2M-specific considerations are out of scope of this I-D. We had this= sentence in the draft (http://tools.ietf.org/html/draft-ietf-v6ops-mobile-= device-profile-00): "M2M devices profile is out of scope." I lost the context why this sentence was removed from the draft.=20 If a > service provider is creating an RFP for such a device, that service > provider would be best advised to figure out their IPv6 architecture > before sending out an RFP with any of the requirements in this draft. For > a service provider to say "I have no clue what my IPv6 architecture is > going to be, so I want to require even the simplest and lowest complexity > cellular hosts to have support for all possible IPv6 archit > ectures" > is not an approach I would recommend. [Med] That exercise is needed anyway (including identifying which parts fro= m RFC6434 and RFC7066 are to be included in the list) . The question is whe= ther this I-D helps in simplifying that exercise or not. This draft positio= ns itself as follows: This profile is a superset of that of the IPv6 profile for 3GPP Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node Requirements [RFC6434]. The service provider you are referring to needs to figure out which parts f= rom RFC6434, RFC7066, and this I-D are to be included in his list. This I-D= completes RFC6434 and RFC7066 with IPv6-related features lists functions t= hat are not captured in existing RFCs (e.g., PDP part, TFT support, VoLTE p= rofile, etc.).=20 This I-D is a "helper" for SPs to customize their list. This is explicitly = called out in the I-D: 2. Help Operators with the detailed device requirement list preparation (to be exchanged with device suppliers). This is also a contribution to harmonize Operators' requirements towards device vendors. >=20 > But that is exactly what this draft recommends: > C_REC#1: In order to allow each operator to select their own > strategy regarding IPv6 introduction, the cellular host > must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. >=20 [Med] What's the problem with this recommendation? > There are also other requirements which appear to impose complexity on > low-end non-roaming/single-purpose cellular hosts in order to allow the > service provider maximum flexibility in ultimately deciding on an IPv6 > architecture. I'm not enough of a cellular expert to be able to properly > identify all of these. [Med] As said above, this kind of devices is not the target of this I-D. We= can make this more clearer. >=20 > As for cellular hosts that do roam, I think the service provider needs to > put some thought into how important it is for such devices to support all > IPv6 architectures. I'm not fully convinced that it won't be acceptable t= o > users of low-end cellular hosts that do roam to just do IPv4 on networks > with unsupported IPv6 architectures. [Med] I don't understand this point. >=20 > --------- >=20 > CPE (Customer Premises Equipment): The draft does provide the acronym > expansion of CPE, but does not define the term. Given the context in whic= h > the draft uses the term, I suspect that the authors are not intending a > definition consistent with that at, for example, [1] and [2].=20 [Med] The I-D includes this sentence:=20 There are several deployments, particularly in emerging countries, that relies on mobile networks to provide broadband services (e.g., customers are provided with mobile CPEs). The first of > these references includes the sentence "CPE generally refers to devices > such as telephones, routers, switches, residential gateways (RG), set-top > boxes, fixed mobile convergence products, home networking adapters and > Internet access gateways that enable consumers to access communications > service providers' services and distribute them around their house via a > local area network (LAN)." The second includes the sentence "Today, almos= t > any end-user equipment can be called customer premise [sic] equipment and > it can be owned by the customer or by the provider." But the set of CPE > that could also reasonably be expected to include a 3GPP interface are, o= f > course, much smaller than this broad def > inition. > One such piece of CPE, though, is a home automation/security gateway > that interfaces with various monitoring, automation, and security devices= . > Such CPE have both an Ethernet WAN interface (that allows them to be > behind the CE router) and a 3GPP interface (for backup and perhaps some > other management purposes). Since these are "CPE" and "cellular" and they > provide LAN connectivity to various home automation devices, they would > appear to fall under the requirements of Section 3, and specifically thos= e > that apply to "cellular CPE". I would not recommend applying RFC 7084 to > such CPE. [Med] Can you elaborate why L_REC#2 is not recommended for those? FWIW, the I-D includes this text: This recommendation does not apply to handsets with tethering capabilities; it is specific to cellular CPEs in order to ensure the same IPv6 functional parity for both fixed and cellular CPEs. Note, modern CPEs are designed with advanced functions such as link aggregation that consists in optimizing the network usage by aggregating the connectivity resources offered via various interfaces (e.g., DSL, LTE, WLAN, etc.) or offloading the traffic via a subset of interfaces. Mutualizing IPv6 features among these interface types is important for the sake of specification efficiency, service design simplification and validation effort optimization. If "CE router" is intended, instead of all devices that can be > classified as "CPE", then I suggest using the term "CE router". >=20 > [1] http://en.wikipedia.org/wiki/Customer-premises_equipment > [2] http://searchnetworking.techtarget.com/definition/customer-premises- > equipment >=20 From nobody Mon Mar 2 02:45:31 2015 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 24E631A86F5; Mon, 2 Mar 2015 02:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KMcCuUSCoVYh; Mon, 2 Mar 2015 02:45:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A4C1A8728; Mon, 2 Mar 2015 02:44:23 -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: 5.12.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150302104423.16985.27484.idtracker@ietfa.amsl.com> Date: Mon, 02 Mar 2015 02:44:23 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-20.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 10:45:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Dave Michaud Diego R. Lopez Filename : draft-ietf-v6ops-mobile-device-profile-20.txt Pages : 19 Date : 2015-03-02 Abstract: This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network) with a special focus on IPv4 service continuity features. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-20 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 Mon Mar 2 10:06:34 2015 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 D24161A8888; Mon, 2 Mar 2015 10:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hGhs3xdf66zj; Mon, 2 Mar 2015 10:06:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E551A8894; Mon, 2 Mar 2015 10:06:27 -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: 5.12.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150302180627.17077.75057.idtracker@ietfa.amsl.com> Date: Mon, 02 Mar 2015 10:06:27 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-pmtud-ecmp-problem-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:06:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB) Authors : Matt Byerly Matt Hite Joel Jaeggli Filename : draft-ietf-v6ops-pmtud-ecmp-problem-00.txt Pages : 8 Date : 2015-03-01 Abstract: This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination in ECMP load balanced, or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 3 01:56:54 2015 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 4BA181A1B12 for ; Tue, 3 Mar 2015 01:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 HGoBD5rlLK8h for ; Tue, 3 Mar 2015 01:56:50 -0800 (PST) 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 103351A1B0D for ; Tue, 3 Mar 2015 01:56:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t239ulS9013718 for ; Tue, 3 Mar 2015 10:56:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4FBC72064A2 for ; Tue, 3 Mar 2015 10:56:57 +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 47F192019B9 for ; Tue, 3 Mar 2015 10:56:57 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t239ukdT003599 for ; Tue, 3 Mar 2015 10:56:47 +0100 Message-ID: <54F5855E.6040204@gmail.com> Date: Tue, 03 Mar 2015 10:56:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E61130F42835@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933004917F6D@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004917F6D@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19 - M2M 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, 03 Mar 2015 09:56:53 -0000 Le 02/03/2015 10:35, mohamed.boucadair@orange.com a écrit : [...] >> Note that the term "[3GPP] cellular host" includes a wide variety >> of devices, including those which are considered "IoT" or "M2M" >> (such as tracking/locating devices, health monitors, eReaders, >> automobiles, etc.). Some of these devices are intended (by the >> service provider who procures them) to be used with a service that >> does not support roaming to other providers' networks. Some are >> single function devices, where the function is fully specified at >> time of procurement. These devices are generally intended to be as >> low-complexity and energy-efficient as possible. > > [Med] M2M-specific considerations are out of scope of this I-D. We > had this sentence in the draft > (http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-00): > > >"M2M devices profile is out of scope." > > I lost the context why this sentence was removed from the draft. Med, I dont know either. But I think we may have a more important problem here that we try to overlook somehow by putting M2M devices out of scope. The problem is that these M2M devices connect to the same cellular network, and practically in almost the same way, as the smartphones do. The main differences are in the way of billing, and the data rates afforded. Another problem lies in an apparent difficulty we have in defining what an M2M device is with respect to IP networking, although we do know they are full IP (as opposed to other IoT devices which are hardly IP or not IP at all). I think it would be advantageous to include M2M devices in this device profile draft. If so, we can start by conceptualizing in the text the fact that 3GPP is just an interface, not a computer per se. This interface can be added to computers like a smartphone, larger computers like a laptop, or smaller computers like the Sierra Wireless Air Prime (one notable M2M-class device in wide use with open source; there are others). It would be necessary also to describe how on the market M2M devices are only IPv4, and only smartphones are IPv6, today. Alex > > If a >> service provider is creating an RFP for such a device, that >> service provider would be best advised to figure out their IPv6 >> architecture before sending out an RFP with any of the requirements >> in this draft. For a service provider to say "I have no clue what >> my IPv6 architecture is going to be, so I want to require even the >> simplest and lowest complexity cellular hosts to have support for >> all possible IPv6 archit ectures" is not an approach I would >> recommend. > > [Med] That exercise is needed anyway (including identifying which > parts from RFC6434 and RFC7066 are to be included in the list) . The > question is whether this I-D helps in simplifying that exercise or > not. This draft positions itself as follows: > > This profile is a superset of that of the IPv6 profile for 3GPP > Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node > Requirements [RFC6434]. > > The service provider you are referring to needs to figure out which > parts from RFC6434, RFC7066, and this I-D are to be included in his > list. This I-D completes RFC6434 and RFC7066 with IPv6-related > features lists functions that are not captured in existing RFCs > (e.g., PDP part, TFT support, VoLTE profile, etc.). > > This I-D is a "helper" for SPs to customize their list. This is > explicitly called out in the I-D: > > 2. Help Operators with the detailed device requirement list > preparation (to be exchanged with device suppliers). This is also a > contribution to harmonize Operators' requirements towards device > vendors. > >> >> But that is exactly what this draft recommends: C_REC#1: In order >> to allow each operator to select their own strategy regarding IPv6 >> introduction, the cellular host must support both IPv6 and IPv4v6 >> PDP-Contexts [TS.23060]. >> > > [Med] What's the problem with this recommendation? > >> There are also other requirements which appear to impose complexity >> on low-end non-roaming/single-purpose cellular hosts in order to >> allow the service provider maximum flexibility in ultimately >> deciding on an IPv6 architecture. I'm not enough of a cellular >> expert to be able to properly identify all of these. > > [Med] As said above, this kind of devices is not the target of this > I-D. We can make this more clearer. > >> >> As for cellular hosts that do roam, I think the service provider >> needs to put some thought into how important it is for such devices >> to support all IPv6 architectures. I'm not fully convinced that it >> won't be acceptable to users of low-end cellular hosts that do roam >> to just do IPv4 on networks with unsupported IPv6 architectures. > > [Med] I don't understand this point. > >> >> --------- >> >> CPE (Customer Premises Equipment): The draft does provide the >> acronym expansion of CPE, but does not define the term. Given the >> context in which the draft uses the term, I suspect that the >> authors are not intending a definition consistent with that at, for >> example, [1] and [2]. > > [Med] The I-D includes this sentence: > > There are several deployments, particularly in emerging countries, > that relies on mobile networks to provide broadband services (e.g., > customers are provided with mobile CPEs). > > > The first of >> these references includes the sentence "CPE generally refers to >> devices such as telephones, routers, switches, residential gateways >> (RG), set-top boxes, fixed mobile convergence products, home >> networking adapters and Internet access gateways that enable >> consumers to access communications service providers' services and >> distribute them around their house via a local area network >> (LAN)." The second includes the sentence "Today, almost any >> end-user equipment can be called customer premise [sic] equipment >> and it can be owned by the customer or by the provider." But the >> set of CPE that could also reasonably be expected to include a >> 3GPP interface are, of course, much smaller than this broad def >> inition. One such piece of CPE, though, is a home >> automation/security gateway that interfaces with various >> monitoring, automation, and security devices. Such CPE have both an >> Ethernet WAN interface (that allows them to be behind the CE >> router) and a 3GPP interface (for backup and perhaps some other >> management purposes). Since these are "CPE" and "cellular" and they >> provide LAN connectivity to various home automation devices, they >> would appear to fall under the requirements of Section 3, and >> specifically those that apply to "cellular CPE". I would not >> recommend applying RFC 7084 to such CPE. > > [Med] Can you elaborate why L_REC#2 is not recommended for those? > > FWIW, the I-D includes this text: > > This recommendation does not apply to handsets with tethering > capabilities; it is specific to cellular CPEs in order to ensure the > same IPv6 functional parity for both fixed and cellular CPEs. Note, > modern CPEs are designed with advanced functions such as link > aggregation that consists in optimizing the network usage by > aggregating the connectivity resources offered via various interfaces > (e.g., DSL, LTE, WLAN, etc.) or offloading the traffic via a subset > of interfaces. Mutualizing IPv6 features among these interface types > is important for the sake of specification efficiency, service design > simplification and validation effort optimization. > > If "CE router" is intended, instead of all devices that can be >> classified as "CPE", then I suggest using the term "CE router". >> >> [1] http://en.wikipedia.org/wiki/Customer-premises_equipment [2] >> http://searchnetworking.techtarget.com/definition/customer-premises- >> >> >> >> equipment >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Tue Mar 3 02:11:52 2015 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 37F921A1A0F for ; Tue, 3 Mar 2015 02:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6HxQVH0OJRjP for ; Tue, 3 Mar 2015 02:11:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1841A008B for ; Tue, 3 Mar 2015 02:11:41 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8587022C116; Tue, 3 Mar 2015 11:11:39 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6622D35C086; Tue, 3 Mar 2015 11:11:39 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Tue, 3 Mar 2015 11:11:39 +0100 From: To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19 - M2M Thread-Index: AQHQVZho4eznCJtzxUSMYxEh6hAlcp0KhkGQ Date: Tue, 3 Mar 2015 10:11:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004918EEE@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <2D09D61DDFA73D4C884805CC7865E61130F42835@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933004917F6D@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54F5855E.6040204@gmail.com> In-Reply-To: <54F5855E.6040204@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.3.54819 Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19 - M2M 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, 03 Mar 2015 10:11:49 -0000 Hi Alex,=20 I'm all with you about the importance of having a profile for M2M devices b= ut I'm also hearing what is expressed by some WG participants who are askin= g to restrict the scope of this I-D. Their comments is fair, too. IMHO, incorporating M2M specificities should be conducted in coordination w= ith other WGs covering M2M-related matters. That will require more work.=20 I'm afraid reconciling both positions in the same profile I-D is unlikely. A way to proceed is to edit a dedicate M2M profile document that can rely o= n this one (tag which recommendations from the RFC6434, RFC7066, and mobile= -profile I-D are relevant for a pure M2M context + identify more items that= are M2M-specific). Hope you understand the constraints we have as editors. Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Alexandru > Petrescu > Envoy=E9=A0: mardi 3 mars 2015 10:57 > =C0=A0: v6ops@ietf.org > Objet=A0: Re: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-= 19 > - M2M >=20 > Le 02/03/2015 10:35, mohamed.boucadair@orange.com a =E9crit : > [...] > >> Note that the term "[3GPP] cellular host" includes a wide variety > >> of devices, including those which are considered "IoT" or "M2M" > >> (such as tracking/locating devices, health monitors, eReaders, > >> automobiles, etc.). Some of these devices are intended (by the > >> service provider who procures them) to be used with a service that > >> does not support roaming to other providers' networks. Some are > >> single function devices, where the function is fully specified at > >> time of procurement. These devices are generally intended to be as > >> low-complexity and energy-efficient as possible. > > > > [Med] M2M-specific considerations are out of scope of this I-D. We > > had this sentence in the draft > > (http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-00): > > > > > >"M2M devices profile is out of scope." > > > > I lost the context why this sentence was removed from the draft. >=20 > Med, I dont know either. But I think we may have a more important > problem here that we try to overlook somehow by putting M2M devices out > of scope. >=20 > The problem is that these M2M devices connect to the same cellular > network, and practically in almost the same way, as the smartphones do. > The main differences are in the way of billing, and the data rates > afforded. >=20 > Another problem lies in an apparent difficulty we have in defining what > an M2M device is with respect to IP networking, although we do know they > are full IP (as opposed to other IoT devices which are hardly IP or not > IP at all). >=20 > I think it would be advantageous to include M2M devices in this device > profile draft. >=20 > If so, we can start by conceptualizing in the text the fact that 3GPP is > just an interface, not a computer per se. This interface can be added > to computers like a smartphone, larger computers like a laptop, or > smaller computers like the Sierra Wireless Air Prime (one notable > M2M-class device in wide use with open source; there are others). >=20 > It would be necessary also to describe how on the market M2M devices are > only IPv4, and only smartphones are IPv6, today. >=20 > Alex >=20 >=20 > > > > If a > >> service provider is creating an RFP for such a device, that > >> service provider would be best advised to figure out their IPv6 > >> architecture before sending out an RFP with any of the requirements > >> in this draft. For a service provider to say "I have no clue what > >> my IPv6 architecture is going to be, so I want to require even the > >> simplest and lowest complexity cellular hosts to have support for > >> all possible IPv6 archit ectures" is not an approach I would > >> recommend. > > > > [Med] That exercise is needed anyway (including identifying which > > parts from RFC6434 and RFC7066 are to be included in the list) . The > > question is whether this I-D helps in simplifying that exercise or > > not. This draft positions itself as follows: > > > > This profile is a superset of that of the IPv6 profile for 3GPP > > Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node > > Requirements [RFC6434]. > > > > The service provider you are referring to needs to figure out which > > parts from RFC6434, RFC7066, and this I-D are to be included in his > > list. This I-D completes RFC6434 and RFC7066 with IPv6-related > > features lists functions that are not captured in existing RFCs > > (e.g., PDP part, TFT support, VoLTE profile, etc.). > > > > This I-D is a "helper" for SPs to customize their list. This is > > explicitly called out in the I-D: > > > > 2. Help Operators with the detailed device requirement list > > preparation (to be exchanged with device suppliers). This is also a > > contribution to harmonize Operators' requirements towards device > > vendors. > > > >> > >> But that is exactly what this draft recommends: C_REC#1: In order > >> to allow each operator to select their own strategy regarding IPv6 > >> introduction, the cellular host must support both IPv6 and IPv4v6 > >> PDP-Contexts [TS.23060]. > >> > > > > [Med] What's the problem with this recommendation? > > > >> There are also other requirements which appear to impose complexity > >> on low-end non-roaming/single-purpose cellular hosts in order to > >> allow the service provider maximum flexibility in ultimately > >> deciding on an IPv6 architecture. I'm not enough of a cellular > >> expert to be able to properly identify all of these. > > > > [Med] As said above, this kind of devices is not the target of this > > I-D. We can make this more clearer. > > > >> > >> As for cellular hosts that do roam, I think the service provider > >> needs to put some thought into how important it is for such devices > >> to support all IPv6 architectures. I'm not fully convinced that it > >> won't be acceptable to users of low-end cellular hosts that do roam > >> to just do IPv4 on networks with unsupported IPv6 architectures. > > > > [Med] I don't understand this point. > > > >> > >> --------- > >> > >> CPE (Customer Premises Equipment): The draft does provide the > >> acronym expansion of CPE, but does not define the term. Given the > >> context in which the draft uses the term, I suspect that the > >> authors are not intending a definition consistent with that at, for > >> example, [1] and [2]. > > > > [Med] The I-D includes this sentence: > > > > There are several deployments, particularly in emerging countries, > > that relies on mobile networks to provide broadband services (e.g., > > customers are provided with mobile CPEs). > > > > > > The first of > >> these references includes the sentence "CPE generally refers to > >> devices such as telephones, routers, switches, residential gateways > >> (RG), set-top boxes, fixed mobile convergence products, home > >> networking adapters and Internet access gateways that enable > >> consumers to access communications service providers' services and > >> distribute them around their house via a local area network > >> (LAN)." The second includes the sentence "Today, almost any > >> end-user equipment can be called customer premise [sic] equipment > >> and it can be owned by the customer or by the provider." But the > >> set of CPE that could also reasonably be expected to include a > >> 3GPP interface are, of course, much smaller than this broad def > >> inition. One such piece of CPE, though, is a home > >> automation/security gateway that interfaces with various > >> monitoring, automation, and security devices. Such CPE have both an > >> Ethernet WAN interface (that allows them to be behind the CE > >> router) and a 3GPP interface (for backup and perhaps some other > >> management purposes). Since these are "CPE" and "cellular" and they > >> provide LAN connectivity to various home automation devices, they > >> would appear to fall under the requirements of Section 3, and > >> specifically those that apply to "cellular CPE". I would not > >> recommend applying RFC 7084 to such CPE. > > > > [Med] Can you elaborate why L_REC#2 is not recommended for those? > > > > FWIW, the I-D includes this text: > > > > This recommendation does not apply to handsets with tethering > > capabilities; it is specific to cellular CPEs in order to ensure the > > same IPv6 functional parity for both fixed and cellular CPEs. Note, > > modern CPEs are designed with advanced functions such as link > > aggregation that consists in optimizing the network usage by > > aggregating the connectivity resources offered via various interfaces > > (e.g., DSL, LTE, WLAN, etc.) or offloading the traffic via a subset > > of interfaces. Mutualizing IPv6 features among these interface types > > is important for the sake of specification efficiency, service design > > simplification and validation effort optimization. > > > > If "CE router" is intended, instead of all devices that can be > >> classified as "CPE", then I suggest using the term "CE router". > >> > >> [1] http://en.wikipedia.org/wiki/Customer-premises_equipment [2] > >> http://searchnetworking.techtarget.com/definition/customer-premises- > >> > >> > >> > >> > equipment > >> > > > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Mar 3 04:47:06 2015 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 B61A91A1A30 for ; Tue, 3 Mar 2015 04:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 QwPAHnTtbouy for ; Tue, 3 Mar 2015 04:47:03 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959D71A1F1D for ; Tue, 3 Mar 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=135; q=dns/txt; s=iport; t=1425386825; x=1426596425; h=date:from:message-id:to:subject:cc; bh=itNMqNHGNkLGo/6lT/A7FxSM0mHrmyYMWX8FdJu4J0g=; b=U+qxQxh2bNZNUjTzc5haWvA0qGfQCD7ohU3oGdBFXe5CDXNhWgMqXjam cp/ysL4JJafT/6P66I+5yP1UGWEf8k6aqZoi24hn+NppbhDIHIf4394TO DXRV1/k9Ak/LGVwdcpIh+lFJnit3PcmT5J12t8tmRXCKLFbJ3cH2ulfTX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CkBQAzrPVU/4gNJK1agwJSsmMBjz6FZwmBKE0BAQEBAQF8hQ88NIkPAQ3WVgEBCAIBH4sShG4dhBUFil2IfIcDOYJpjyMjhA+DEQEBAQ X-IronPort-AV: E=Sophos;i="5.09,681,1418083200"; d="scan'208";a="128378289" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 03 Mar 2015 12:47:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t23Cl2rs020524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2015 12:47:02 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 t23Cl1rc025521; Tue, 3 Mar 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t23Cl15w025520; Tue, 3 Mar 2015 04:47:01 -0800 Date: Tue, 3 Mar 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201503031247.t23Cl15w025520@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-pmtud-ecmp-problem 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, 03 Mar 2015 12:47:04 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Wed Mar 4 17:37:45 2015 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 AA03E1ACCDC for ; Wed, 4 Mar 2015 17:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 a2Z1XfzwfoRJ for ; Wed, 4 Mar 2015 17:37:35 -0800 (PST) Received: from mail-08.primus.ca (mail23.primus.ca [216.254.141.190]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDC41A899F for ; Wed, 4 Mar 2015 17:37:35 -0800 (PST) Received: from [189.42.248.178] (helo=[10.125.135.30]) by mail-08.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YTKjF-00087d-CC; Wed, 04 Mar 2015 20:37:34 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <1184650378.7552509.1424682099969.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 4 Mar 2015 22:37:30 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9A994199-706D-4D3F-A9BA-C3D4EC44E32C@magma.ca> References: <53DB2211-946B-4C0C-AB8D-50398E25CFAA@magma.ca> <1184650378.7552509.1424682099969.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([10.125.135.30]) [189.42.248.178] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt 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, 05 Mar 2015 01:37:38 -0000 To Mark, Chairs and list: Been extremely busy last 1.5 weeks, but will try to get a revision of = the draft out on Monday March 9th (just before the deadline) addressing = the comments below. - Philip On 2015-02-23, at 6:01 , Mark ZZZ Smith wrote: > Hi Philip, >=20 >=20 > ----- Original Message ----- > From: Philip Matthews > To: Mark ZZZ Smith > Cc: v6ops list > Sent: Sunday, 22 February 2015, 14:40 > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >=20 >=20 > On 2015-02-19, at 23:13 , Mark ZZZ Smith wrote: >=20 >> Hi, >>=20 >>=20 >> ----- Original Message ----- >> From: Philip Matthews >> To: Mark ZZZ Smith >> Cc: v6ops list >> Sent: Friday, 20 February 2015, 14:09 >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >>=20 >> Mark: >>=20 >> Thanks for your comments. Replies inline. >>=20 >> Philip >>=20 > =20 >> /"Have global and/or unique-local addresses assigned in addition to = link-locals" would probably read better. > DONE >=20 > /There is a loose ')' in there though ;-) >=20 >>=20 >> /One thought about when to use 'addresses' verses 'prefixes'. I and I = think a lot of other people think at the level of assigning a prefix to = a link, with the assumption and implication that all interfaces attached = to the link would normally have addresses from each of the on-link = prefixes. The case where link attached interfaces wouldn't have = addresses from all of the present prefixes would be an exception (e.g., = in IPv4, when the subnet is too small, or in IPv6, perhaps when = migrating a prefix off of a link, or when the prefix has been configured = on a stateful DHCPv6 server, but not all hosts have asked for addresses = from it.) >>=20 >> / "2.1.2. Interfaces with Only Link-Local Addresses?" seems to be = written from with the unstated assumption that all interfaces will have = addresses from all on-link prefixes. As that isn't an IPv6 requirement, = I think it would be best to state that assumption, and that there may be = situations where that is not the case.=20 >>=20 >> / More broadly, it seems that although interfaces are where addresses = are assigned, this whole topic is really about whether to assign certain = types of prefix to a link or not (and therefore implicitly all = link-attached interfaces), rather than to individual interfaces or not. = So I wonder if it might be a bit clearer if the perspective was changed = slightly from addresses assigned to interfaces (implicitly all = interfaces on a link) to prefixes assigned to links, and then stating = the assumption that in most cases all interfaces will get addresses from = all on-link prefixes.=20 >=20 > Interesting comment. However, I confess that I am not seeing how this = section might be rewritten. Note that this section is just trying to = contrast zero vs non-zero numbers of GUAs and/or ULAs, and not discuss = one vs two vs ... GUAs/ULAs. >=20 > / I understand what it is trying to contrast, and I'd describe it as = contrasting whether to have just a link-local prefix on the link, or = whether to add one or more GUA and/or ULA prefixes to the link.=20 >=20 > / If that description is correct, then it is assuming that all = interfaces attached to the link will get addresses from what ever = prefixes are present on the link. Yet the text, by being 'Interface' = oriented', rather than 'link oriented' implies that it is a decision = that would be made on a per-interface rather than a per-link basis. = Technically it can be made on a per-Interface basis, but commonly isn't. >=20 > Perhaps you could give an example or two of rewritten sentences? >=20 > / How about something like this: >=20 > 2.1.2. Link-local prefix only links? >=20 > The Link-local prefix is automatically present on links on which IPv6 = is operating over, as all IPv6 interfaces are required to have a = Link-Local address [RFC4291]. Link-local addresses are or can be used = for IPv6 operation or applications when the source and destination are = on-link [RFC4007][RFC5942][RFC6724] >=20 > To provide on-link nodes with the ability to reach off-link = destinations, or for off-link sources to reach on-link destinations, one = or more GUA and/or ULA prefixes need to be present on the link. Note = that although it is not required, it is common and likely that the = attached nodes' link-attached interfaces will have addresses from all of = the present GUA and/or ULA prefixes, as the nodes will be likely to = automatically participate in the SLAAC and/or stateful DHCPv6 address = configuration protocols. >=20 > There are two advantages of interfaces that only have Link-Local = addresses. The first > advantage is ease of configuration. In a network with a large number > of Link-Local only interfaces, the operator can just enable an IGP on = each > router, without going through the tedious process of assigning and > tracking the addresses for each interface. The second advantage is > security. Since packets with Link-Local destination addresses should > not be routed, it is very difficult to attack the associated > nodes from an off-link device. This implies less effort around > maintaining security ACLs. >=20 > (etc.) >=20 >=20 > Regards, > Mark. >=20 >>=20 >>=20 >>=20 >>>=20 >>> "Proper" support for multiple prefixes on a link is one of IPv6's = enhanced capabilities over IPv4's. People should be encouraged to take = advantage of it if it would be useful to them. >>=20 >> I agree, though it is not often I find an situation where I can take = advantage of this. >>=20 >> / I think the case for ULAs is when link-local reachability is too = small, and global scope reachability is too large, because it reduces = security. For example, addressing internal only servers/services (e.g., = network printers), or network equipment management addresses. >>=20 >>=20 >>=20 >> Regards, >> Mark. >>=20 >>>=20 >>> Regards, >>> Mark. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>> From: Philip Matthews >>> To: v6ops list >>> Cc:=20 >>> Sent: Thursday, 19 February 2015, 8:23 >>> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >>>=20 >>> Hi Everyone: >>>=20 >>> Victor and I just posted this update, which addresses the comments = raised in Honolulu, and generally cleans up the draft. No really big = changes, but lots of little changes. =20 >>>=20 >>> A few highlights: >>> * The wording in the title, abstract and introduction has been = modified to narrow the scope of the document. The document no longer = claims to cover all choices around designing IPv6 network, but just = certain choices that are routing-related. This always been the de-facto = situation, but now the introduction etc reflect this. Some additional = sentences saying "X is not covered here, see doc Y" have also been = added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this = area. >>> * The text around using BGP sessions to link-local addresses has = been updated after some email exchanges with Francis Dupont (co-author = of RFC 2545), who observed that RFC 2545 forbids this (even though most = vendors support it). >>> * The text around security of link-local addresses has been modified = since some routers forward packets containing link-local source = addresses. Thanks to Jen Lincova for pointing this out. >>> * The initial few sentences in a number of sections has been changed = in an attempt to improve the document flow. >>> * The document now has a security considerations section. There is = nothing earth-shaking here; Victor and I elected to just point to some = existing documents that are relevant to the choices discussed in the = document. >>>=20 >>> There were many other small changes to try to improve document = wording and clarity, and I thank a number of my colleagues at = Alcatel-Lucent for their helpful reviews. >>>=20 >>> Overall, Victor and I feel this new version is much improved, and we = hope you guys will too. As always, we welcome further comments. >>>=20 >>> - Philip >>>=20 >>> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>>>=20 >>>> Title : Some Design Choices for IPv6 Networks >>>> Authors : Philip Matthews >>>> Victor Kuarsingh >>>> Filename : draft-ietf-v6ops-design-choices-04.txt >>>> Pages : 17 >>>> Date : 2015-02-18 >>>>=20 >>>> Abstract: >>>> This document presents advice on certain routing-related design >>>> choices that arise when designing IPv6 networks (both dual-stack = and >>>> IPv6-only). The intended audience is someone designing an IPv6 >>>> network who is knowledgeable about best current practices around = IPv4 >>>> network design, and wishes to learn the corresponding practices for >>>> IPv6. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-04= >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 >=20 >>=20 >>=20 >>=20 >>>=20 >>> "Proper" support for multiple prefixes on a link is one of IPv6's = enhanced capabilities over IPv4's. People should be encouraged to take = advantage of it if it would be useful to them. >>=20 >> I agree, though it is not often I find an situation where I can take = advantage of this. >>=20 >> / I think the case for ULAs is when link-local reachability is too = small, and global scope reachability is too large, because it reduces = security. For example, addressing internal only servers/services (e.g., = network printers), or network equipment management addresses. >>=20 >>=20 >>=20 >> Regards, >> Mark. >>=20 >>>=20 >>> Regards, >>> Mark. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>> From: Philip Matthews >>> To: v6ops list >>> Cc:=20 >>> Sent: Thursday, 19 February 2015, 8:23 >>> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >>>=20 >>> Hi Everyone: >>>=20 >>> Victor and I just posted this update, which addresses the comments = raised in Honolulu, and generally cleans up the draft. No really big = changes, but lots of little changes. =20 >>>=20 >>> A few highlights: >>> * The wording in the title, abstract and introduction has been = modified to narrow the scope of the document. The document no longer = claims to cover all choices around designing IPv6 network, but just = certain choices that are routing-related. This always been the de-facto = situation, but now the introduction etc reflect this. Some additional = sentences saying "X is not covered here, see doc Y" have also been = added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this = area. >>> * The text around using BGP sessions to link-local addresses has = been updated after some email exchanges with Francis Dupont (co-author = of RFC 2545), who observed that RFC 2545 forbids this (even though most = vendors support it). >>> * The text around security of link-local addresses has been modified = since some routers forward packets containing link-local source = addresses. Thanks to Jen Lincova for pointing this out. >>> * The initial few sentences in a number of sections has been changed = in an attempt to improve the document flow. >>> * The document now has a security considerations section. There is = nothing earth-shaking here; Victor and I elected to just point to some = existing documents that are relevant to the choices discussed in the = document. >>>=20 >>> There were many other small changes to try to improve document = wording and clarity, and I thank a number of my colleagues at = Alcatel-Lucent for their helpful reviews. >>>=20 >>> Overall, Victor and I feel this new version is much improved, and we = hope you guys will too. As always, we welcome further comments. >>>=20 >>> - Philip >>>=20 >>> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>>>=20 >>>> Title : Some Design Choices for IPv6 Networks >>>> Authors : Philip Matthews >>>> Victor Kuarsingh >>>> Filename : draft-ietf-v6ops-design-choices-04.txt >>>> Pages : 17 >>>> Date : 2015-02-18 >>>>=20 >>>> Abstract: >>>> This document presents advice on certain routing-related design >>>> choices that arise when designing IPv6 networks (both dual-stack = and >>>> IPv6-only). The intended audience is someone designing an IPv6 >>>> network who is knowledgeable about best current practices around = IPv4 >>>> network design, and wishes to learn the corresponding practices for >>>> IPv6. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-04= >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Mar 4 21:51:29 2015 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 8B0A41B29B3 for ; Wed, 4 Mar 2015 21:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 DpNbOiH83wlC for ; Wed, 4 Mar 2015 21:51:27 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0EF1B29B9 for ; Wed, 4 Mar 2015 21:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2401; q=dns/txt; s=iport; t=1425534684; x=1426744284; h=from:to:subject:date:message-id:references:mime-version; bh=J6O2XtqXqWCat307c3ablPxCgMiw1j17UZsEidmDyAM=; b=C01RpSiO33h2sNyBx7ES4CRMZ7iZp7sUiDaltH4KAPRh91Pn7svTkR5Y 7j6ap4tydkP3EpwKDqJj6nVS8YrT0LB356IAwnWZVXT+NPWzs0AbROCyS cOunVb+vz18H/Gz97QG2MRfU94ewD1ynJO7Te3I/aIzTr8YtiKu+B72yC s=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BwBm7vdU/4UNJK1agwKBLAS7JYtqAoEkTQEBAQEBAXyEDwEBAQMBfgsCARkDAQIvMhsCCAIEEw6IGQjXeQEBAQEBAQEDAQEBAQEBAQEBGYsUhF0egxGBFAWFdYoQgWSBLoY7k2wjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,345,1422921600"; d="asc'?scan'208";a="401006681" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 05 Mar 2015 05:51:23 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t255pN7l006593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Mar 2015 05:51:23 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 23:51:23 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: v6ops - Requested sessions have been scheduled for IETF 92 Thread-Index: AQHQVwhp1TWQ1IQggUidsT3EawB7QQ== Date: Thu, 5 Mar 2015 05:51:22 +0000 Message-ID: References: <20150227222718.22539.20819.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: multipart/signed; boundary="Apple-Mail=_387453AB-5F66-4018-9C92-1AE3668FD368"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: v6ops - Requested sessions have been scheduled for IETF 92 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, 05 Mar 2015 05:51:28 -0000 --Apple-Mail=_387453AB-5F66-4018-9C92-1AE3668FD368 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI > Begin forwarded message: > > From: "\"IETF Secretariat\"" > To: > Cc: , , > Subject: v6ops - Requested sessions have been scheduled for IETF 92 > Date: February 27, 2015 at 2:27:18 PM PST > > 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:30:00) > Thursday, Morning Session I 0900-1130 > Room Name: Gold size: 300 > --------------------------------------------- > v6ops Session 2 (2:00:00) > Wednesday, Afternoon Session I 1300-1500 > Room Name: International size: 450 > --------------------------------------------- > > > > 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.5 Hours, 2 Hours > Number of Attendees: 150 > Conflicts to Avoid: > First Priority: opsec softwire homenet pcp 6man aqm dclcrg sunset4 > Second Priority: tsvwg tsvarea iccrg intarea mif lmap > Third Priority: ospf tcpm rtgwg isis opsawg > > > Special Requests: > > --------------------------------------------------------- > --Apple-Mail=_387453AB-5F66-4018-9C92-1AE3668FD368 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 iQEVAwUBVPfu2p9ieig10VPpAQKYCgf/eRB28A3aQoYbK558tDCgVqTKmZ/UxDbS aWAc8U9vpjvUN2jXUbYlSp0B6T/fzx+IIGr77mmT/eN19zOowUaWGuzo49/xenbk gwIcCg0wY+pIiB3uNMjKiwiEXn8ENpFFS3Isli/TCW1NVga/Q4w5qmRyDm+rEVlr LZmtj3omQ4psv0aT0KeRHaNB8Sn48ECyb/emkvi/cRMt/+i8tMfR2AX5PKHofNzx /T/AnemLrWI1AeOBVMU0JtaY7tJh+VH4veJA4lCsmrohY6dDr4VEJK6L5C3KjA/3 CnyoU6SFvw7W64Q2FNd/VoLbcJgVPcPVkYQgacVTkXUS1MqurP1cQg== =Ufiw -----END PGP SIGNATURE----- --Apple-Mail=_387453AB-5F66-4018-9C92-1AE3668FD368-- From nobody Fri Mar 6 05:52:26 2015 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 4F3781ACD4D for ; Fri, 6 Mar 2015 05:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 6BZa4vyujEzh for ; Fri, 6 Mar 2015 05:52:23 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E45C1A1DBE for ; Fri, 6 Mar 2015 05:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3520; q=dns/txt; s=iport; t=1425649943; x=1426859543; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jjDJsJDEaaT9c4nlLhTSN49+t7OkwfF0NLpLMSDL7kg=; b=T4WGKOTCzRUZh6AAfg4ojcyfdTVlrwfBjEK+v0gCkhIwTPgTzWvOPmqZ 96zlBqxw/tpFThtbaNXviaq254giAG/90f+JVBFaJTaMBts3A4L5Z+ea+ hZ51PBQl28TeMXsan4yy7WWxu/YuxoSoJCq8hTXeN47xkukMBOi+pylkm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmBgCzsPlU/5xdJa1cgwZSVQUEgwa+aIVuAhyBHU0BAQEBAQF8hBABAQQjETMQEgIBCBoCJgICAjAVBgEGAwIEEwmIJggFtCKaVQEBAQEBAQQBAQEBAQEBG4EhiXaEJVCCaIFDBZAHg2OFaoEaOYJtjy8jgjKBPG+BA0F/AQEB X-IronPort-AV: E=Sophos;i="5.11,352,1422921600"; d="scan'208";a="129556927" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 06 Mar 2015 13:52:22 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t26DqMN2031724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Mar 2015 13:52:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 07:52:22 -0600 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-vyncke-v6ops-happy-eyeballs-cookie-01.txt Thread-Index: AQHQV+OAmfOoS9exuUuMXePFUNM3gp0P7xkA Date: Fri, 6 Mar 2015 13:52:20 +0000 Message-ID: References: <20150306075938.24593.60303.idtracker@ietfa.amsl.com> In-Reply-To: <20150306075938.24593.60303.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.71] Content-Type: text/plain; charset="utf-8" Content-ID: <79E5C700BFA2014CA5C12952D87C7EF6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [v6ops] FW: New Version Notification for draft-vyncke-v6ops-happy-eyeballs-cookie-01.txt 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: Fri, 06 Mar 2015 13:52:25 -0000 QXMgZGlzY3Vzc2VkIGVhcmxpZXIsIGhlcmUgaXMgYSAtMDEgdmVyc2lvbiBhZGRpbmcgbnVtZXJv dXMgY29tbWVudHMgdG8gYmUNCmFjY3VyYXRlIGFuZCBtYWtpbmcgaXQgbW9yZSBnZW5lcmljICho ZW5jZSBjaGFuZ2luZyB0aGUgdGl0bGUgYnV0IG5vdCB0aGUNCmZpbGVuYW1lKS4NCg0KTm90IHN1 cmUgd2hldGhlciBpdCBzaG91bGQgYmUgYSBXRyBkb2N1bWVudCB0aG91Z2guDQoNCkNvbW1lbnRz IGFyZSB3ZWxjb21lIG9mIGNvdXJzZQ0KDQotw6lyaWMNCg0KT24gNi8wMy8xNSAwODo1OSwgImlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCndyb3Rl Og0KDQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZ5bmNrZS12Nm9wcy1oYXBweS1l eWViYWxscy1jb29raWUtMDEudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBFcmljIFZ5bmNrZSBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5O YW1lOgkJZHJhZnQtdnluY2tlLXY2b3BzLWhhcHB5LWV5ZWJhbGxzLWNvb2tpZQ0KPlJldmlzaW9u OgkwMQ0KPlRpdGxlOgkJSFRUUCBTdGF0ZSBNYW5hZ2VtZW50IE1lY2hhbmlzbXMgd2l0aCBNdWx0 aXBsZSBBZGRyZXNzZXMgVXNlcg0KPkFnZW50cw0KPkRvY3VtZW50IGRhdGU6CTIwMTUtMDMtMDYN Cj5Hcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJNw0KPlVSTDogICAgICAg ICAgICANCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12eW5ja2Ut djZvcHMtaGFwcHktZXllYmFsbHMtY29vaw0KPmllLTAxLnR4dA0KPlN0YXR1czogICAgICAgICAN Cj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12eW5ja2UtdjZvcHMtaGFw cHktZXllYmFsbHMtY29va2llLw0KPkh0bWxpemVkOiAgICAgICANCj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC12eW5ja2UtdjZvcHMtaGFwcHktZXllYmFsbHMtY29va2llLTAxDQo+ RGlmZjogICAgICAgICAgIA0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LXZ5bmNrZS12Nm9wcy1oYXBweS1leWViYWxscy1jb29raWUtDQo+MDENCj4NCj5BYnN0cmFjdDoN Cj4gICBIVFRQIHNlcnZlcnMgdXN1YWxseSBzYXZlIHNlc3Npb24gc3RhdGVzIGluIHRoZWlyIHBl cnNpc3RlbnQgc3RvcmFnZQ0KPiAgIGluZGV4ZWQgYnkgc2Vzc2lvbiBjb29raWVzIGdlbmVyYXRl ZCBieSB0aGUgSFRUUCBzZXJ2ZXJzLiAgSXQgaXMgdXANCj4gICB0byB0aGUgSFRUUCB1c2VyLWFn ZW50IHRvIHNlbmQgdGhpcyBzZXNzaW9uIGNvb2tpZSBvbiBlYWNoIEhUVFANCj4gICByZXF1ZXN0 LiAgU29tZSBIVFRQIHNlcnZlcnMgY2hlY2sgd2hldGhlciB0aGUgY29va2llIGlzIGFzc29jaWF0 ZWQNCj4gICB3aXRoIHRoZSBIVFRQIHVzZXItYWdlbnQgYnkgdGhlIG1lYW5zIG9mIHRoZSB1c2Vy LWFnZW50IElQIGFkZHJlc3MuDQo+ICAgRXZlcnl0aGluZyBsaW5raW5nIGEgc3RhdGUgdG8gYW4g SVAgYWRkcmVzcyAoc3VjaCBhcyBPQXV0aCBhY2Nlc3MNCj4gICBjb2RlKSB0byBhbiBJUCBhZGRy ZXNzIGhhcyB0aGUgc2FtZSBpc3N1ZS4NCj4NCj4gICBJZiB0aGUgSGFwcHkgRXllYmFsbCBtZWNo YW5pc20gaXMgdXNlZCB0byBzZWxlY3QgYmV0d2VlbiBJUHY2IGFuZA0KPiAgIElQdjQsIGl0IG1h eSBoYXBwZW4gdGhhdCB3aGlsZSB1c2luZyB0aGUgc2FtZSBIVFRQIHNlcnZlciwgc29tZSBIVFRQ DQo+ICAgcmVxdWVzdHMgYXJlIGRvbmUgb3ZlciBJUHY2IGFuZCB0aGUgb3RoZXJzIG92ZXIgSVB2 NCwgd2hpY2ggbGVhZHMgdG8NCj4gICB0d28gZGlmZmVyZW50IHNldHMgb2Ygc2Vzc2lvbiBzdGF0 ZXMgaW4gdGhlIEhUVFAgc2VydmVyLiAgVGhpcyBoYXMNCj4gICB0aGUgY29uc2VxdWVuY2Ugb2Yg aW5jb25zaXN0ZW5jaWVzIGF0IHRoZSBIVFRQIHNlcnZlci4NCj4NCj4gICBUaGUgb25seSBwdXJw b3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gZG9jdW1lbnQgdGhpcyBpc3N1ZSBpbiBtb3JlDQo+ ICAgZGV0YWlscyB0aGFuIGluIHNlY3Rpb24gOC4yIG9mIFJGQyA2ODgzIGluY2x1ZGluZyBzZWN1 cml0eQ0KPiAgIGNvbnNpZGVyYXRpb25zIGFuZCBtaXRpZ2F0aW9ucy4NCj4NCj4gICBBIHNpbWls YXIgcHJvYmxlbSBhcmlzZXMgd2l0aCB0aGUgdXNlIG9mIG5vbiBSRkMgNjg4OCBjb21wbGlhbnQN Cj4gICBDYXJyaWVyLUdyYWRlIE5BVCAoQ0dOKSBkZXZpY2VzIHVzZWQgdG8gYWNjZXNzIGFuIElQ djQtb25seSBIVFRQDQo+ICAgc2VydmVyIG9yIEhUVFAgdXNlci1hZ2VudCB1c2luZyBtdWx0aS1o b21pbmcuDQo+DQo+ICAgICAgICAgICAgICAgICAgDQo+ICAgICAgICANCj4NCj4NCj5QbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ DQoNCg== From nobody Mon Mar 9 05:20:11 2015 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 33C1B1A8869 for ; Mon, 9 Mar 2015 05:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001] 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 HsQswEmhkwGP for ; Mon, 9 Mar 2015 05:20:05 -0700 (PDT) Received: from smtp03.msg.oleane.net (smtp03.msg.oleane.net [62.161.4.3]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2C11A886A for ; Mon, 9 Mar 2015 05:20:01 -0700 (PDT) Received: from MGosseDellM6800 (LMontsouris-656-1-5-162.w80-12.abo.wanadoo.fr [80.12.94.162]) (authenticated) by smtp03.msg.oleane.net (MSA) with ESMTP id t29CJx9C024706 for ; Mon, 9 Mar 2015 13:19:59 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Mon, 9 Mar 2015 13:19:57 +0100 Message-ID: <000401d05a63$5bd62f50$13828df0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01D05A6B.BD9BA8C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBaYzWVclW4E8jBRFmbZyyeSfbKzg== Content-Language: fr X-Backend: vm-smtp-sophos11v3 X-PMX-Spam: Probability=9% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.9.114818 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: Subject: [v6ops] V6 World Congress Paris 2015 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, 09 Mar 2015 12:20:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0005_01D05A6B.BD9BA8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Facebook, LinkedIn, Microsoft, Akamai, Time Warner, Cloudflare, Comcast: learn about the most interesting IPv6 only deployments. One week left before V6 World 5th Edition. There is still time to register. More info.: http://www.uppersideconferences.com/ipv6/ ------=_NextPart_000_0005_01D05A6B.BD9BA8C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Facebook, LinkedIn, = Microsoft, Akamai, Time Warner, Cloudflare, = Comcast: learn about the most interesting  IPv6 only deployments. =

One week left before V6 World 5th = Edition.

 

There is still time = to register.

 

More info.: http://www.uppersideco= nferences.com/ipv6/

 

 

------=_NextPart_000_0005_01D05A6B.BD9BA8C0-- From nobody Mon Mar 9 09:33:49 2015 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 06EDB1A8745; Mon, 9 Mar 2015 09:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0DqkP7K3OhUA; Mon, 9 Mar 2015 09:33:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AB71A9005; Mon, 9 Mar 2015 09:33:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309163330.30198.34988.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 09:33:30 -0700 Archived-At: Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Protocol Action: 'Deprecating Anycast Prefix for 6to4 Relay Routers' to Best Current Practice (draft-ietf-v6ops-6to4-to-historic-11.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:33:46 -0000 The IESG has approved the following document: - 'Deprecating Anycast Prefix for 6to4 Relay Routers' (draft-ietf-v6ops-6to4-to-historic-11.txt) as Best Current Practice This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ Technical Summary Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 be moved to historic status. Working Group Summary Discussion in the working group was voluminous and intense. Many additional proposals were considered, such as asking operators to shut down 6to4 service on a stated date via filtering or null routing, not doing so, asking vendors to remove code from products, and so on. This draft represents the intersection of those views - rough consensus in the best possible meaning of the phrase. Document Quality The document was reviewed by numerous people in wide reaches of the community including operators, vendors, and researchers. Personnel Fred Baker is the document shepherd. RFC Editor Note minor tweaks to be processed at editing time. As previously suggested: OLD: This document therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It also obsoletes RFC 6732 "6to4 Provider Managed Tunnels". NEW: This document therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", and RFC 6732, "6to4 Provider Managed Tunnels", be made obsolete and moved to historic status. In response to the IANA review: OLD: Instead, IANA is requested to mark the 192.88.99.0/24 prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay Anycast)", pointing to the present document. NEW: Instead, IANA is requested to mark the 192.88.99.0/24 prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay Anycast)", pointing to the present document. The Boolean values for the address block 192.88.99.0/24 will all be removed. From nobody Mon Mar 9 12:02:29 2015 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 6173B1A92DF; Mon, 9 Mar 2015 12:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WaEzXA09I9Tb; Mon, 9 Mar 2015 12:02:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E901AC3E9; Mon, 9 Mar 2015 12:01:36 -0700 (PDT) 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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309190136.7848.15095.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 12:01:36 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:02:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Some Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-06.txt Pages : 17 Date : 2015-03-09 Abstract: This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-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 Mon Mar 9 12:06:06 2015 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 495A31A8988 for ; Mon, 9 Mar 2015 12:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 aVdowwM_Gyo3 for ; Mon, 9 Mar 2015 12:06:01 -0700 (PDT) Received: from mail-08.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9977E1A8937 for ; Mon, 9 Mar 2015 12:06:00 -0700 (PDT) Received: from [24.114.95.123] (helo=[172.20.10.4]) by mail-08.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YV303-00021G-ML; Mon, 09 Mar 2015 15:06:00 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <1184650378.7552509.1424682099969.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 9 Mar 2015 15:05:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <22EBC28F-43DA-4C26-99EB-584E436EFF70@magma.ca> References: <53DB2211-946B-4C0C-AB8D-50398E25CFAA@magma.ca> <1184650378.7552509.1424682099969.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.95.123] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt 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, 09 Mar 2015 19:06:05 -0000 Hi Mark: Thanks very much for your comments! We have adopted some of your = proposals, but not quite everything. We have adopted your proposed re-wording for the third paragraph (with a = few minor re-wordings). You proposed to eliminate all uses of the term "unnumbered interface" = and replace it with "interface with only link-local address". We feel = this is too extreme, but we now alternate between the two forms and make = it very clear that the two terms means the same thing. We have some concerns with your proposed rewording for the first and = second paragraphs. In version -04, we narrowed the scope of the draft = to routing-related design choices. One of the minor changes introduced = at this time was a rename of section 2.1 to "Interfaces" from "Links", = and corresponding changes in the section body: interfaces being a layer = 3 concept, while links are a layer-2 concept. This we don't want to = change the text back to read "links". We also feel that the use of SLAAC or DHCP to assign global addresses to = router interfaces is very uncommon on networks that people actually = design (as opposed to ad-hoc or home networks). Hopefully you are content with what we did. If not, perhaps we can = discuss face-to-face in Dallas. - Philip On 2015-02-23, at 4:01 , Mark ZZZ Smith wrote: > Hi Philip, >=20 >=20 > ----- Original Message ----- > From: Philip Matthews > To: Mark ZZZ Smith > Cc: v6ops list > Sent: Sunday, 22 February 2015, 14:40 > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >=20 >=20 > On 2015-02-19, at 23:13 , Mark ZZZ Smith wrote: >=20 >> Hi, >>=20 >>=20 >> ----- Original Message ----- >> From: Philip Matthews >> To: Mark ZZZ Smith >> Cc: v6ops list >> Sent: Friday, 20 February 2015, 14:09 >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >>=20 >> Mark: >>=20 >> Thanks for your comments. Replies inline. >>=20 >> Philip >>=20 > =20 >> /"Have global and/or unique-local addresses assigned in addition to = link-locals" would probably read better. > DONE >=20 > /There is a loose ')' in there though ;-) >=20 >>=20 >> /One thought about when to use 'addresses' verses 'prefixes'. I and I = think a lot of other people think at the level of assigning a prefix to = a link, with the assumption and implication that all interfaces attached = to the link would normally have addresses from each of the on-link = prefixes. The case where link attached interfaces wouldn't have = addresses from all of the present prefixes would be an exception (e.g., = in IPv4, when the subnet is too small, or in IPv6, perhaps when = migrating a prefix off of a link, or when the prefix has been configured = on a stateful DHCPv6 server, but not all hosts have asked for addresses = from it.) >>=20 >> / "2.1.2. Interfaces with Only Link-Local Addresses?" seems to be = written from with the unstated assumption that all interfaces will have = addresses from all on-link prefixes. As that isn't an IPv6 requirement, = I think it would be best to state that assumption, and that there may be = situations where that is not the case.=20 >>=20 >> / More broadly, it seems that although interfaces are where addresses = are assigned, this whole topic is really about whether to assign certain = types of prefix to a link or not (and therefore implicitly all = link-attached interfaces), rather than to individual interfaces or not. = So I wonder if it might be a bit clearer if the perspective was changed = slightly from addresses assigned to interfaces (implicitly all = interfaces on a link) to prefixes assigned to links, and then stating = the assumption that in most cases all interfaces will get addresses from = all on-link prefixes.=20 >=20 > Interesting comment. However, I confess that I am not seeing how this = section might be rewritten. Note that this section is just trying to = contrast zero vs non-zero numbers of GUAs and/or ULAs, and not discuss = one vs two vs ... GUAs/ULAs. >=20 > / I understand what it is trying to contrast, and I'd describe it as = contrasting whether to have just a link-local prefix on the link, or = whether to add one or more GUA and/or ULA prefixes to the link.=20 >=20 > / If that description is correct, then it is assuming that all = interfaces attached to the link will get addresses from what ever = prefixes are present on the link. Yet the text, by being 'Interface' = oriented', rather than 'link oriented' implies that it is a decision = that would be made on a per-interface rather than a per-link basis. = Technically it can be made on a per-Interface basis, but commonly isn't. >=20 > Perhaps you could give an example or two of rewritten sentences? >=20 > / How about something like this: >=20 > 2.1.2. Link-local prefix only links? >=20 > The Link-local prefix is automatically present on links on which IPv6 = is operating over, as all IPv6 interfaces are required to have a = Link-Local address [RFC4291]. Link-local addresses are or can be used = for IPv6 operation or applications when the source and destination are = on-link [RFC4007][RFC5942][RFC6724] >=20 > To provide on-link nodes with the ability to reach off-link = destinations, or for off-link sources to reach on-link destinations, one = or more GUA and/or ULA prefixes need to be present on the link. Note = that although it is not required, it is common and likely that the = attached nodes' link-attached interfaces will have addresses from all of = the present GUA and/or ULA prefixes, as the nodes will be likely to = automatically participate in the SLAAC and/or stateful DHCPv6 address = configuration protocols. >=20 > There are two advantages of interfaces that only have Link-Local = addresses. The first > advantage is ease of configuration. In a network with a large number > of Link-Local only interfaces, the operator can just enable an IGP on = each > router, without going through the tedious process of assigning and > tracking the addresses for each interface. The second advantage is > security. Since packets with Link-Local destination addresses should > not be routed, it is very difficult to attack the associated > nodes from an off-link device. This implies less effort around > maintaining security ACLs. >=20 > (etc.) >=20 >=20 > Regards, > Mark. >=20 >>=20 >>=20 >>=20 >>>=20 >>> "Proper" support for multiple prefixes on a link is one of IPv6's = enhanced capabilities over IPv4's. People should be encouraged to take = advantage of it if it would be useful to them. >>=20 >> I agree, though it is not often I find an situation where I can take = advantage of this. >>=20 >> / I think the case for ULAs is when link-local reachability is too = small, and global scope reachability is too large, because it reduces = security. For example, addressing internal only servers/services (e.g., = network printers), or network equipment management addresses. >>=20 >>=20 >>=20 >> Regards, >> Mark. >>=20 >>>=20 >>> Regards, >>> Mark. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>> From: Philip Matthews >>> To: v6ops list >>> Cc:=20 >>> Sent: Thursday, 19 February 2015, 8:23 >>> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >>>=20 >>> Hi Everyone: >>>=20 >>> Victor and I just posted this update, which addresses the comments = raised in Honolulu, and generally cleans up the draft. No really big = changes, but lots of little changes. =20 >>>=20 >>> A few highlights: >>> * The wording in the title, abstract and introduction has been = modified to narrow the scope of the document. The document no longer = claims to cover all choices around designing IPv6 network, but just = certain choices that are routing-related. This always been the de-facto = situation, but now the introduction etc reflect this. Some additional = sentences saying "X is not covered here, see doc Y" have also been = added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this = area. >>> * The text around using BGP sessions to link-local addresses has = been updated after some email exchanges with Francis Dupont (co-author = of RFC 2545), who observed that RFC 2545 forbids this (even though most = vendors support it). >>> * The text around security of link-local addresses has been modified = since some routers forward packets containing link-local source = addresses. Thanks to Jen Lincova for pointing this out. >>> * The initial few sentences in a number of sections has been changed = in an attempt to improve the document flow. >>> * The document now has a security considerations section. There is = nothing earth-shaking here; Victor and I elected to just point to some = existing documents that are relevant to the choices discussed in the = document. >>>=20 >>> There were many other small changes to try to improve document = wording and clarity, and I thank a number of my colleagues at = Alcatel-Lucent for their helpful reviews. >>>=20 >>> Overall, Victor and I feel this new version is much improved, and we = hope you guys will too. As always, we welcome further comments. >>>=20 >>> - Philip >>>=20 >>> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>>>=20 >>>> Title : Some Design Choices for IPv6 Networks >>>> Authors : Philip Matthews >>>> Victor Kuarsingh >>>> Filename : draft-ietf-v6ops-design-choices-04.txt >>>> Pages : 17 >>>> Date : 2015-02-18 >>>>=20 >>>> Abstract: >>>> This document presents advice on certain routing-related design >>>> choices that arise when designing IPv6 networks (both dual-stack = and >>>> IPv6-only). The intended audience is someone designing an IPv6 >>>> network who is knowledgeable about best current practices around = IPv4 >>>> network design, and wishes to learn the corresponding practices for >>>> IPv6. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-04= >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 >=20 >>=20 >>=20 >>=20 >>>=20 >>> "Proper" support for multiple prefixes on a link is one of IPv6's = enhanced capabilities over IPv4's. People should be encouraged to take = advantage of it if it would be useful to them. >>=20 >> I agree, though it is not often I find an situation where I can take = advantage of this. >>=20 >> / I think the case for ULAs is when link-local reachability is too = small, and global scope reachability is too large, because it reduces = security. For example, addressing internal only servers/services (e.g., = network printers), or network equipment management addresses. >>=20 >>=20 >>=20 >> Regards, >> Mark. >>=20 >>>=20 >>> Regards, >>> Mark. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>> From: Philip Matthews >>> To: v6ops list >>> Cc:=20 >>> Sent: Thursday, 19 February 2015, 8:23 >>> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >>>=20 >>> Hi Everyone: >>>=20 >>> Victor and I just posted this update, which addresses the comments = raised in Honolulu, and generally cleans up the draft. No really big = changes, but lots of little changes. =20 >>>=20 >>> A few highlights: >>> * The wording in the title, abstract and introduction has been = modified to narrow the scope of the document. The document no longer = claims to cover all choices around designing IPv6 network, but just = certain choices that are routing-related. This always been the de-facto = situation, but now the introduction etc reflect this. Some additional = sentences saying "X is not covered here, see doc Y" have also been = added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this = area. >>> * The text around using BGP sessions to link-local addresses has = been updated after some email exchanges with Francis Dupont (co-author = of RFC 2545), who observed that RFC 2545 forbids this (even though most = vendors support it). >>> * The text around security of link-local addresses has been modified = since some routers forward packets containing link-local source = addresses. Thanks to Jen Lincova for pointing this out. >>> * The initial few sentences in a number of sections has been changed = in an attempt to improve the document flow. >>> * The document now has a security considerations section. There is = nothing earth-shaking here; Victor and I elected to just point to some = existing documents that are relevant to the choices discussed in the = document. >>>=20 >>> There were many other small changes to try to improve document = wording and clarity, and I thank a number of my colleagues at = Alcatel-Lucent for their helpful reviews. >>>=20 >>> Overall, Victor and I feel this new version is much improved, and we = hope you guys will too. As always, we welcome further comments. >>>=20 >>> - Philip >>>=20 >>> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>>>=20 >>>> Title : Some Design Choices for IPv6 Networks >>>> Authors : Philip Matthews >>>> Victor Kuarsingh >>>> Filename : draft-ietf-v6ops-design-choices-04.txt >>>> Pages : 17 >>>> Date : 2015-02-18 >>>>=20 >>>> Abstract: >>>> This document presents advice on certain routing-related design >>>> choices that arise when designing IPv6 networks (both dual-stack = and >>>> IPv6-only). The intended audience is someone designing an IPv6 >>>> network who is knowledgeable about best current practices around = IPv4 >>>> network design, and wishes to learn the corresponding practices for >>>> IPv6. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-04= >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 From nobody Mon Mar 9 12:09:17 2015 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 D64711A90C2 for ; Mon, 9 Mar 2015 12:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Nem2SKfoe7p3 for ; Mon, 9 Mar 2015 12:09:14 -0700 (PDT) Received: from mail-07.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6902A1A90BE for ; Mon, 9 Mar 2015 12:09:14 -0700 (PDT) Received: from [24.114.95.123] (helo=[172.20.10.4]) by mail-07.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YV33B-0003l4-NJ; Mon, 09 Mar 2015 15:09:14 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20150309190136.7848.15095.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2015 15:09:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150309190136.7848.15095.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.95.123] Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-06.txt 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, 09 Mar 2015 19:09:16 -0000 Hi Everyone: This latest version of the draft addresses some comments posted to the = list a couple of weeks ago by Mark Smith. See our separate email = replying to him. Philip and Victor On 2015-03-09, at 15:01 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-06.txt > Pages : 17 > Date : 2015-03-09 >=20 > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around = IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-06 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Mar 9 12:10:12 2015 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 519791A9250; Mon, 9 Mar 2015 12:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pskfoVaWzaqv; Mon, 9 Mar 2015 12:10:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5D31A9175; Mon, 9 Mar 2015 12:10:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309191007.2376.37748.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 12:10:07 -0700 Archived-At: Cc: v6ops@ietf.org, RFC Editor Subject: [v6ops] Document Action: 6to4 Provider Managed Tunnels to Historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:10:09 -0000 The IESG has approved changing the status of the following document: - 6to4 Provider Managed Tunnels (rfc6732) to Historic This document action is documented at: http://datatracker.ietf.org/doc/status-change-rfc-3068-anycast-prefix-for-6to4-to-historic/ A URL of the affected document is: http://datatracker.ietf.org/doc/rfc6732/ Status Change Details: RFC Status Change : RFC 3068 An Anycast Prefix for 6to4 Relay Routers and RFC 6732 Provider managed tunnels to historic RFC 3068 introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." draft-ietf-v6ops-6to4-to-historic-11.txt requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It does so because the mechanism is considered unsuitable for widespread deployment and use in the Internet. further recommendations are made for the operations of existing 6to4 anycast services. draft-ietf-v6ops-6to4-to-historic-11 obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. Personnel Joel Jaeggli is the responsible Area Director. From nobody Mon Mar 9 12:10:26 2015 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 4789A1A90BE; Mon, 9 Mar 2015 12:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v6G49-ZGbSll; Mon, 9 Mar 2015 12:10:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4C1A9176; Mon, 9 Mar 2015 12:10:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309191007.2376.13444.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 12:10:07 -0700 Archived-At: Cc: v6ops@ietf.org, RFC Editor Subject: [v6ops] Protocol Action: An Anycast Prefix for 6to4 Relay Routers to Historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:10:11 -0000 The IESG has approved changing the status of the following document: - An Anycast Prefix for 6to4 Relay Routers (rfc3068) to Historic This protocol action is documented at: http://datatracker.ietf.org/doc/status-change-rfc-3068-anycast-prefix-for-6to4-to-historic/ A URL of the affected document is: http://datatracker.ietf.org/doc/rfc3068/ Status Change Details: RFC Status Change : RFC 3068 An Anycast Prefix for 6to4 Relay Routers and RFC 6732 Provider managed tunnels to historic RFC 3068 introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." draft-ietf-v6ops-6to4-to-historic-11.txt requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It does so because the mechanism is considered unsuitable for widespread deployment and use in the Internet. further recommendations are made for the operations of existing 6to4 anycast services. draft-ietf-v6ops-6to4-to-historic-11 obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. Personnel Joel Jaeggli is the responsible Area Director. From nobody Mon Mar 9 14:01:29 2015 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 AAA771ACD68 for ; Mon, 9 Mar 2015 14:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 f2w4FIBZgS7a for ; Mon, 9 Mar 2015 14:01:26 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 422961ACD52 for ; Mon, 9 Mar 2015 14:01:26 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 9 Mar 2015 16:01:25 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f170.google.com [209.85.213.170] #+LO+TS+TR X-Umn-Classification: local Received: by igal13 with SMTP id l13so24799605iga.5 for ; Mon, 09 Mar 2015 14:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yoL05LaAX9HjygYF4aClMH54Aa3s3yduqd6V8H3jmOQ=; b=UJmhxFZCRGSKcw4LkkPysUbprp1ccaOOzgsyHugpdYcl4PQzqFwaK2ksaIm99Wbnsh YfpQr3ZGTFNqMrsvKY5YvgHsaQM/Nfb2kRSGuimkXw+7A3cJa546wkIQtgQMu3CH6zG6 8QdPfoOrFWEQdw4iTKtklY/lwZj9pphiiwJCg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yoL05LaAX9HjygYF4aClMH54Aa3s3yduqd6V8H3jmOQ=; b=ky+mc6GRkFO+vd36yKG69I/f0P/WPHPqJRTshBQbRirdCq5wvWfKaHIiLMl9+Bz6D9 RfYxN7peBkQEgFZag9M9BLSg20tQSRtIh87saLYVARY91gO91DmQBbYZPLWOQbfpBJs8 NZhOB4T9ZIuxP/BZmgZF+dPMakHERYIsqP7nSip8QV0nB4+KpBEOdxJEHXfL0ZBady9k xWXmSQ+wg0ETlJhXQcZR9OmKZUKt22MGwJYUIEcMsfNL1R2nmaqBHSjFLLMWBqBQUDoL aZI36EIOjJDhejULsR3Q8bcFyzfo+Q9OUvjr8PmnhKPnWydBQfCnfFjUKuL5YD1uRzOA HOJQ== X-Gm-Message-State: ALoCoQlL734kUrR+dD9QU7rlKQOoh7ayZSFqDAMsstQTNKQSZVG2n3sv18S+wIPzfMFKFB9QnWqpIKhRCdPYpyAOulOd30BGo5UKAv3fXJjglUNwn5jcOvYkdYBcP1BdzRGYl1Gbyu4P X-Received: by 10.42.66.208 with SMTP id q16mr30035348ici.11.1425934884775; Mon, 09 Mar 2015 14:01:24 -0700 (PDT) X-Received: by 10.42.66.208 with SMTP id q16mr30035328ici.11.1425934884600; Mon, 09 Mar 2015 14:01:24 -0700 (PDT) Received: from x-128-101-235-196.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:687f:9eae:792d:586e]) by mx.google.com with ESMTPSA id e3sm364158igg.16.2015.03.09.14.01.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 14:01:22 -0700 (PDT) Message-ID: <54FE0A1B.2010009@umn.edu> Date: Mon, 09 Mar 2015 16:01:15 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20150309163330.30198.34988.idtracker@ietfa.amsl.com> In-Reply-To: <20150309163330.30198.34988.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: Re: [v6ops] Protocol Action: 'Deprecating Anycast Prefix for 6to4 Relay Routers' to Best Current Practice (draft-ietf-v6ops-6to4-to-historic-11.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:01:27 -0000 On 3/9/15 11:33 , The IESG wrote: > The IESG has approved the following document: > - 'Deprecating Anycast Prefix for 6to4 Relay Routers' > (draft-ietf-v6ops-6to4-to-historic-11.txt) as Best Current Practice Good News! ... > In response to the IANA review: > > OLD: > > Instead, IANA is requested to mark the 192.88.99.0/24 > prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay > Anycast)", pointing to the present document. > > NEW: > > Instead, IANA is requested to mark the 192.88.99.0/24 > prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay > Anycast)", pointing to the present document. The Boolean values > for the address block 192.88.99.0/24 will all be removed. What is the rationale for removing the Boolean values? Wouldn't the current values apply until the prefix is repurposed or removed by future protocol action? I'm not sure I really care, but I don't understand what is served by removing the current values. I'm not sure what purpose the Boolean values really serve, but the current values seem the most appropriate until the prefix is permanently removed or repurposed. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Mar 9 16:50:27 2015 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 896A41A8BC1 for ; Mon, 9 Mar 2015 16:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] 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 hJwcRR91dMor for ; Mon, 9 Mar 2015 16:50:21 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C141ACE53 for ; Mon, 9 Mar 2015 16:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1425945020; bh=JuJn5RbS/9VkSluID65YUd7UNeC6ZYq/84FLfzoVLOk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Kij/yBqdd/kRbmPKfNGbkVisZJ69Hbib1FMEG09Pq819Blys73H2b1VzL/jkKx7yzFcsrNlEDn2SK8eqKlPDfpMWTmEyKm7TDlwrQzLlkTUxt3y87qIjDlA/oS8urCLrRjdH2gmz1nmu9yOHZMhbwftj0O133zc/jPsUJv9VWanNAk5RSsUZKK/SOZ5uPbKLFKevYFWQtlyomid8TMiV6HTAA9JrEvAi23H2IktEN7p2tW9ifyDvE2c/Jj/Zl3td8HI/O2yTbBIMSGZV/m74yeVQd2NzIkU+1EXiCZA4Vv9JZiERP+cH56iJOx7zP0BwVm6VpIjRnJwFs3ciLyDW2w== Received: from [98.139.212.150] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 23:50:20 -0000 Received: from [98.139.212.214] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 23:50:20 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 23:49:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 534960.15211.bm@omp1023.mail.bf1.yahoo.com X-YMail-OSG: 7U0fAA8VM1n.LU5KnwJdvgoYe_mLIrC50FScIj6tqu_2E.K2Wc_eA_wGX0gu3NW aUiXSXWKahkkZFuq67b7BR9eCjEcmZXgFu.ciOBq0AcU90oKfgGP4tiWryJg1Qwj2pTBf3TkT8Qk UBTti2GAyTsw.4oQO2QAXcyd_nGTGozdDiu8xAA3m4mrA8YiAHfnF1ndGSj.hSSlwuxFiRAQ70f5 mALtNIB3gPWjRC5fvOHYxBjEGXvKBtw87ojirGaNmdOl0bWrWu1w7eprU8hMBXDxkU.suoUEr29e asCOI.jageYmNDqnU8dFzIIHXf1z3tvs4.mkXuT0xHkb0MJWB8hyfGEm5R.tT7H3_iA3VGbu4ycS dh2MviTwBNll7O0.LqVYEK5jvB.gqdzh3d9kmzSAykhJVrjXOYt5kuSeFxc2tiuEdurwEJfulEFt eGudlGYVG1qsFztRvJsIF6DalUj85WaoErSkQUiHoOFRT2atoHmkYWtSfQvLYj3PInqCtfEExOx5 NQoIXJZd2azPKx.hF3Wgel6iFYwvCkyRQlGxpaXBdx9yN6HyuFg-- Received: by 66.196.81.109; Mon, 09 Mar 2015 23:49:52 +0000 Date: Mon, 9 Mar 2015 23:47:58 +0000 (UTC) From: Mark ZZZ Smith To: Philip Matthews Message-ID: <475150044.2076231.1425944878901.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <22EBC28F-43DA-4C26-99EB-584E436EFF70@magma.ca> References: <22EBC28F-43DA-4C26-99EB-584E436EFF70@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:50:24 -0000 Hi Philip, ----- Original Message ----- From: Philip Matthews To: Mark ZZZ Smith Cc: v6ops list Sent: Tuesday, 10 March 2015, 6:05 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt Hi Mark: Thanks very much for your comments! We have adopted some of your proposals, but not quite everything. We have adopted your proposed re-wording for the third paragraph (with a few minor re-wordings). You proposed to eliminate all uses of the term "unnumbered interface" and replace it with "interface with only link-local address". We feel this is too extreme, but we now alternate between the two forms and make it very clear that the two terms means the same thing. / The concern I have with continuing to use an incorrect term, even though it might be fairly commonly used, is that the longer it is used, the longer it can cause confusion or error, and the longer it encourages the use of the inaccurate term. / Somebody who knows very little about IPv6 (which might be a reasonable portion of the audience of your document) would assume an 'unnumbered' link would have no IPv6 addressing present at all on any of the attached interfaces, because that is the case with IPv4. That misunderstanding can have security implications, as unnumbered IPv4 links can't by default support IPv4 applications if hosts are attached to the IPv4 unnumbered link, where as 'unnumbered' IPv6 links can (because they're not actually unnumbered). / Another point of confusion would be that in IPv4, unnumbered links are usually only serial point-to-point links between routers, meaning that hosts can't physically be attached to the link, where as any type of link can be an IPv6 "unnumbered" link, so hosts may be physically attached to the link if the link-layer is multi-access. / These subtle yet significant differences are the ones that, if hidden by incorrect terminology, create opportunities for security or operational problems. In my experience avoiding those issues is far cheaper and easier than cleaning up after they've occurred. / I think in your document it would be better to use the term 'link-local only' throughout the document, and just acknowledge once early in the document that it has been also described as 'unnumbered' as it is somewhat similar to the IPv4 concept of unnumbered link, but certainly isn't the same. We have some concerns with your proposed rewording for the first and second paragraphs. In version -04, we narrowed the scope of the draft to routing-related design choices. / So I think the title needs to reflect that e.g., "Some Design Choices for IPv6 Routing" One of the minor changes introduced at this time was a rename of section 2.1 to "Interfaces" from "Links", and corresponding changes in the section body: interfaces being a layer 3 concept, while links are a layer-2 concept. This we don't want to change the text back to read "links". / I don't agree with "interfaces being a layer 3 concept", and I think if you think a bit more about it you wouldn't either. / My perspective is that documents such as this one should be written to address the issues and topics covered from the most common perspective or point of view the audience is likely to have. People 'assign' prefixes to links when they're planning addressing, even though in practice the prefixes are implicitly assigned to a link via addresses assignment to device interfaces. You can see examples of this perspective throughout RFC5375 and many other documents or books that cover IPv6 addressing, and in my experience it is a common perspective. We also feel that the use of SLAAC or DHCP to assign global addresses to router interfaces is very uncommon on networks that people actually design (as opposed to ad-hoc or home networks). / I'm a bit confused by this. If this is referring to this bit of text I suggested below, "Note that although it is not required, it is common and likely that the attached nodes' link-attached interfaces will have addresses from all of the present GUA and/or ULA prefixes, as the nodes will be likely to automatically participate in the SLAAC and/or stateful DHCPv6 address configuration protocols." I should have written "hosts" rather than "nodes" i.e., "Note that although it is not required, it is common and likely that the attached hosts' link-attached interfaces will have addresses from all of the present GUA and/or ULA prefixes, as the hosts will be likely to automatically participate in the SLAAC and/or stateful DHCPv6 address configuration protocols." Hopefully you are content with what we did. If not, perhaps we can discuss face-to-face in Dallas. / I won't be at the IETF in Dallas unless somebody was willing to sponsor my attendance. Regards, Mark. - Philip On 2015-02-23, at 4:01 , Mark ZZZ Smith wrote: > Hi Philip, > > > ----- Original Message ----- > From: Philip Matthews > To: Mark ZZZ Smith > Cc: v6ops list > Sent: Sunday, 22 February 2015, 14:40 > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt > > > On 2015-02-19, at 23:13 , Mark ZZZ Smith wrote: > >> Hi, >> >> >> ----- Original Message ----- >> From: Philip Matthews >> To: Mark ZZZ Smith >> Cc: v6ops list >> Sent: Friday, 20 February 2015, 14:09 >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt >> >> Mark: >> >> Thanks for your comments. Replies inline. >> >> Philip >> > >> /"Have global and/or unique-local addresses assigned in addition to link-locals" would probably read better. > DONE > > /There is a loose ')' in there though ;-) > >> >> /One thought about when to use 'addresses' verses 'prefixes'. I and I think a lot of other people think at the level of assigning a prefix to a link, with the assumption and implication that all interfaces attached to the link would normally have addresses from each of the on-link prefixes. The case where link attached interfaces wouldn't have addresses from all of the present prefixes would be an exception (e.g., in IPv4, when the subnet is too small, or in IPv6, perhaps when migrating a prefix off of a link, or when the prefix has been configured on a stateful DHCPv6 server, but not all hosts have asked for addresses from it.) >> >> / "2.1.2. Interfaces with Only Link-Local Addresses?" seems to be written from with the unstated assumption that all interfaces will have addresses from all on-link prefixes. As that isn't an IPv6 requirement, I think it would be best to state that assumption, and that there may be situations where that is not the case. >> >> / More broadly, it seems that although interfaces are where addresses are assigned, this whole topic is really about whether to assign certain types of prefix to a link or not (and therefore implicitly all link-attached interfaces), rather than to individual interfaces or not. So I wonder if it might be a bit clearer if the perspective was changed slightly from addresses assigned to interfaces (implicitly all interfaces on a link) to prefixes assigned to links, and then stating the assumption that in most cases all interfaces will get addresses from all on-link prefixes. > > Interesting comment. However, I confess that I am not seeing how this section might be rewritten. Note that this section is just trying to contrast zero vs non-zero numbers of GUAs and/or ULAs, and not discuss one vs two vs ... GUAs/ULAs. > > / I understand what it is trying to contrast, and I'd describe it as contrasting whether to have just a link-local prefix on the link, or whether to add one or more GUA and/or ULA prefixes to the link. > > / If that description is correct, then it is assuming that all interfaces attached to the link will get addresses from what ever prefixes are present on the link. Yet the text, by being 'Interface' oriented', rather than 'link oriented' implies that it is a decision that would be made on a per-interface rather than a per-link basis. Technically it can be made on a per-Interface basis, but commonly isn't. > > Perhaps you could give an example or two of rewritten sentences? > > / How about something like this: > > 2.1.2. Link-local prefix only links? > > The Link-local prefix is automatically present on links on which IPv6 is operating over, as all IPv6 interfaces are required to have a Link-Local address [RFC4291]. Link-local addresses are or can be used for IPv6 operation or applications when the source and destination are on-link [RFC4007][RFC5942][RFC6724] > > To provide on-link nodes with the ability to reach off-link destinations, or for off-link sources to reach on-link destinations, one or more GUA and/or ULA prefixes need to be present on the link. Note that although it is not required, it is common and likely that the attached nodes' link-attached interfaces will have addresses from all of the present GUA and/or ULA prefixes, as the nodes will be likely to automatically participate in the SLAAC and/or stateful DHCPv6 address configuration protocols. > > There are two advantages of interfaces that only have Link-Local addresses. The first > advantage is ease of configuration. In a network with a large number > of Link-Local only interfaces, the operator can just enable an IGP on each > router, without going through the tedious process of assigning and > tracking the addresses for each interface. The second advantage is > security. Since packets with Link-Local destination addresses should > not be routed, it is very difficult to attack the associated > nodes from an off-link device. This implies less effort around > maintaining security ACLs. > > (etc.) > > > Regards, > Mark. > >> >> >> >>> >>> "Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them. >> >> I agree, though it is not often I find an situation where I can take advantage of this. >> >> / I think the case for ULAs is when link-local reachability is too small, and global scope reachability is too large, because it reduces security. For example, addressing internal only servers/services (e.g., network printers), or network equipment management addresses. >> >> >> >> Regards, >> Mark. >> >>> >>> Regards, >>> Mark. >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: Philip Matthews >>> To: v6ops list >>> Cc: >>> Sent: Thursday, 19 February 2015, 8:23 >>> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt >>> >>> Hi Everyone: >>> >>> Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes. >>> >>> A few highlights: >>> * The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this. Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area. >>> * The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it). >>> * The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out. >>> * The initial few sentences in a number of sections has been changed in an attempt to improve the document flow. >>> * The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document. >>> >>> There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews. >>> >>> Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments. >>> >>> - Philip >>> >>> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the IPv6 Operations Working Group of the IETF. >>>> >>>> Title : Some Design Choices for IPv6 Networks >>>> Authors : Philip Matthews >>>> Victor Kuarsingh >>>> Filename : draft-ietf-v6ops-design-choices-04.txt >>>> Pages : 17 >>>> Date : 2015-02-18 >>>> >>>> Abstract: >>>> This document presents advice on certain routing-related design >>>> choices that arise when designing IPv6 networks (both dual-stack and >>>> IPv6-only). The intended audience is someone designing an IPv6 >>>> network who is knowledgeable about best current practices around IPv4 >>>> network design, and wishes to learn the corresponding practices for >>>> IPv6. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04 >>>> >>>> >>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 >> > > > >> >> >> >>> >>> "Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them. >> >> I agree, though it is not often I find an situation where I can take advantage of this. >> >> / I think the case for ULAs is when link-local reachability is too small, and global scope reachability is too large, because it reduces security. For example, addressing internal only servers/services (e.g., network printers), or network equipment management addresses. >> >> >> >> Regards, >> Mark. >> >>> >>> Regards, >>> Mark. >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: Philip Matthews >>> To: v6ops list >>> Cc: >>> Sent: Thursday, 19 February 2015, 8:23 >>> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt >>> >>> Hi Everyone: >>> >>> Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes. >>> >>> A few highlights: >>> * The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this. Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area. >>> * The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it). >>> * The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out. >>> * The initial few sentences in a number of sections has been changed in an attempt to improve the document flow. >>> * The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document. >>> >>> There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews. >>> >>> Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments. >>> >>> - Philip >>> >>> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the IPv6 Operations Working Group of the IETF. >>>> >>>> Title : Some Design Choices for IPv6 Networks >>>> Authors : Philip Matthews >>>> Victor Kuarsingh >>>> Filename : draft-ietf-v6ops-design-choices-04.txt >>>> Pages : 17 >>>> Date : 2015-02-18 >>>> >>>> Abstract: >>>> This document presents advice on certain routing-related design >>>> choices that arise when designing IPv6 networks (both dual-stack and >>>> IPv6-only). The intended audience is someone designing an IPv6 >>>> network who is knowledgeable about best current practices around IPv4 >>>> network design, and wishes to learn the corresponding practices for >>>> IPv6. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04 >>>> >>>> >>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 9 18:08:54 2015 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 B22801A9092 for ; Mon, 9 Mar 2015 18:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 XpQDVDMhWkyQ for ; Mon, 9 Mar 2015 18:08:50 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 13CA51A0231 for ; Mon, 9 Mar 2015 18:08:49 -0700 (PDT) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YV8f8-0000zm-1m; Tue, 10 Mar 2015 02:08:46 +0100 Message-ID: <54FE4416.60601@gont.com.ar> Date: Tue, 10 Mar 2015 02:08:38 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "v6ops@ietf.org" References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> In-Reply-To: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 10 Mar 2015 01:08:52 -0000 Folks, At the IETF meeting in Hawaii we presented draft-gont-v6ops-ipv6-ehs-in-real-world. Folks seemed to be in favor of an I-D providing real-world data about the extent to which packets with EHs are dropped in the Internet, but didn't support having the I-D provide advice on this topic. We have revised the I-D. Lots of things were corrected and/or clarified. And all such text the wg was not in agreement with has now been removed. The new rev is available at: Please do let us now if you have any feedback. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt Date: Sun, 08 Mar 2015 22:36:09 -0700 From: internet-drafts@ietf.org To: Will Liu (Shucheng) , J. Linkova , Shucheng LIU (Will) , Tim Chown , Tim Chown , Fernando Gont , Fernando Gont , J. Linkova A new version of I-D, draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-in-real-world Revision: 02 Title: Observations on IPv6 EH Filtering in the Real World Document date: 2015-03-08 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-in-real-world/ Htmlized: http://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-in-real-world-02 Abstract: This document presents real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the Internet (as measured in August 2014), and where in the network such filtering occurs. 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. This document also explains how the aforementioned results were obtained, such that the corresponding measurements can be reproduced by other members of the community. 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 -- 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 Mon Mar 9 19:28:56 2015 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 891831A0069 for ; Mon, 9 Mar 2015 19:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 ah7lI-pnOgjy for ; Mon, 9 Mar 2015 19:28:49 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::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 4A8DE1A00F6 for ; Mon, 9 Mar 2015 19:28:36 -0700 (PDT) Received: by pdev10 with SMTP id v10so38948672pde.13 for ; Mon, 09 Mar 2015 19:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f5CL+TQtBlNJj7Qt6vhjtukRTS7x5YCWzr4XjHMGMk0=; b=Lr8N5Po/LdWjMjcuvpv5JRShExOSWJvKfxdxsStPEKIQHzbXEoqU9tvR9RbW5hiwNv A4m5t26Gdn+eMlAPJIH/X5oLzPCwJAzTYtRxhSbrxd+J1BAn1+8++Ja+rjU3bmwZlySG WxLbXwUjBzFNhvlUQs0BcHGuxBFSxB5zF8/DAU0ArNOAP/9NQ4IHAzyCJ5izbnW99FRr aH2QON5ywuskBNd74bQuQziX0LHrf5BF6OGlLD0bw8X0aW1wba4eHUCskKzOa4qKFr3E QjO3oM/w+ixM+iJA05WLClTlA3aGkkXtjA30k1Te1D1BNwasQIJ6oOeJN5odk5+pzKdc BJgA== X-Received: by 10.70.0.207 with SMTP id 15mr9683754pdg.56.1425954515424; Mon, 09 Mar 2015 19:28:35 -0700 (PDT) Received: from [10.1.9.163] ([103.23.18.15]) by mx.google.com with ESMTPSA id g11sm21445822pat.24.2015.03.09.19.28.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 19:28:34 -0700 (PDT) Message-ID: <54FE56D3.4050104@gmail.com> Date: Tue, 10 Mar 2015 15:28:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150309163330.30198.34988.idtracker@ietfa.amsl.com> <54FE0A1B.2010009@umn.edu> In-Reply-To: <54FE0A1B.2010009@umn.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Protocol Action: 'Deprecating Anycast Prefix for 6to4 Relay Routers' to Best Current Practice (draft-ietf-v6ops-6to4-to-historic-11.txt) 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, 10 Mar 2015 02:28:55 -0000 On 10/03/2015 10:01, David Farmer wrote: > On 3/9/15 11:33 , The IESG wrote: >> The IESG has approved the following document: >> - 'Deprecating Anycast Prefix for 6to4 Relay Routers' >> (draft-ietf-v6ops-6to4-to-historic-11.txt) as Best Current Practice > > Good News! > > ... >> In response to the IANA review: >> >> OLD: >> >> Instead, IANA is requested to mark the 192.88.99.0/24 >> prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay >> Anycast)", pointing to the present document. >> >> NEW: >> >> Instead, IANA is requested to mark the 192.88.99.0/24 >> prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay >> Anycast)", pointing to the present document. The Boolean values >> for the address block 192.88.99.0/24 will all be removed. > > What is the rationale for removing the Boolean values? Wouldn't the current values apply until the prefix is repurposed or > removed by future protocol action? > > I'm not sure I really care, but I don't understand what is served by removing the current values. I'm not sure what purpose the > Boolean values really serve, but the current values seem the most appropriate until the prefix is permanently removed or > repurposed. Well, IANA wanted this change. I sympathise because it means they never have to revisit this in the future. Brian From nobody Mon Mar 9 22:24:06 2015 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 01A9E1A0111 for ; Mon, 9 Mar 2015 22:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 c6L2b7ggEq_F for ; Mon, 9 Mar 2015 22:24:00 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 6BE231A1AE8 for ; Mon, 9 Mar 2015 22:23:59 -0700 (PDT) Received: (qmail 62239 invoked from network); 10 Mar 2015 05:23:57 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Mar 2015 05:23:57 -0000 Date: Tue, 10 Mar 2015 06:23:57 +0100 (CET) Message-Id: <20150310.062357.74690098.sthaug@nethelp.no> To: markzzzsmith@yahoo.com.au From: sthaug@nethelp.no In-Reply-To: <475150044.2076231.1425944878901.JavaMail.yahoo@mail.yahoo.com> References: <22EBC28F-43DA-4C26-99EB-584E436EFF70@magma.ca> <475150044.2076231.1425944878901.JavaMail.yahoo@mail.yahoo.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, philip_matthews@magma.ca Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt 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, 10 Mar 2015 05:24:05 -0000 > / The concern I have with continuing to use an incorrect term, even though it might be fairly commonly used, is that the longer it is used, the longer it can cause confusion or error, and the longer it encourages the use of the inaccurate term. "Unnumbered interface" is well established in the IPv4 world, and I see no reason to believe that this document will change that fact. > / Another point of confusion would be that in IPv4, unnumbered links are usually only serial point-to-point links between routers, meaning that hosts can't physically be attached to the link, where as any type of link can be an IPv6 "unnumbered" link, so hosts may be physically attached to the link if the link-layer is multi-access. Strongly disagree about the IPv4 part. There is *large* deployment of unnumbered links for end hosts in service provider environments - for instance DHCP scenarios with one large DHCP pool being used for thousands of unnumbered subinterfaces. I work for one such service provider. Steinar Haug, AS 2116. From nobody Mon Mar 9 22:24:13 2015 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 B653C1A1B07 for ; Mon, 9 Mar 2015 22:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 eI7MRbP-_MUM for ; Mon, 9 Mar 2015 22:24:05 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 46C801A0111 for ; Mon, 9 Mar 2015 22:24:05 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 10 Mar 2015 00:24:03 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f179.google.com [209.85.223.179] #+LO+TS+TR X-Umn-Classification: local Received: by iecsf10 with SMTP id sf10so1055760iec.2 for ; Mon, 09 Mar 2015 22:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=wLpfDxA4YzRxDb3P9SgDXJiUOYdmh+vla0bjI/oD/e8=; b=kGQBNfmQUrvV2cfd2pFsm/Oo0vlXN1p/GaDpI9eOkHjnUgYy6yPLA8SrqpQnMMQcDp ujCWPZ6TFr9uXHpYGhVEn3uhH5Z+r62S/WmLToKtPhne34F5beuqCGcqyLgfkBt95ozQ L06R1tZbc/oQt+4fPhZoDo1dnXtD1wWQJYNEQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=wLpfDxA4YzRxDb3P9SgDXJiUOYdmh+vla0bjI/oD/e8=; b=SK+8hfaMEGrIl4eZqmjluZsDYM/UcPZOIY9T+Z5Ii7h/ul6U7epko7b1K7D31+sEAr o/SbyhT1m+Zf+S2kEpVtsjbA6aaajhOgY8zmAH7kR59EPFKZhGnIQ/SBVlQORb6DaH/g FbQuUdWLGpkmt/feUTDx7FpUiHqJqjGPtlnwUfL+8lXBe/w0HWFb2ShOipVSF/uPC8vZ J96yvvhGmH4oBU5a2W51G1oSj/IByAN4MzRu6V7MjF/1ceLDne1tuAAWIsPDym5FeQAT LNNrTTdvVpoeHk/oK6sYD1RxxFF2i+kZeCRJftUV59P9q7eMWi+aJ3wp+wnu0dJAjjsm KUyA== X-Gm-Message-State: ALoCoQlZjE6qA/vxRMg7dn4KkUp/Ku0iYBG58GUXz/cq6aSSahyU0Z5J8A1oy7AmJJZjStMghIi9AXx4b10w42/jJrs7YjUwX2Z056rwSgVI/BnV09nHIIIRSh6phWoje6TFg03WcLrc X-Received: by 10.107.169.146 with SMTP id f18mr23725205ioj.6.1425965043463; Mon, 09 Mar 2015 22:24:03 -0700 (PDT) X-Received: by 10.107.169.146 with SMTP id f18mr23725188ioj.6.1425965043345; Mon, 09 Mar 2015 22:24:03 -0700 (PDT) Received: from [10.0.0.21] (c-75-73-121-154.hsd1.mn.comcast.net. [75.73.121.154]) by mx.google.com with ESMTPSA id n15sm5020854ioe.6.2015.03.09.22.24.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 22:24:00 -0700 (PDT) References: <20150309163330.30198.34988.idtracker@ietfa.amsl.com> <54FE0A1B.2010009@umn.edu> <54FE56D3.4050104@gmail.com> In-Reply-To: <54FE56D3.4050104@gmail.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <66EBE2FE-2BE2-4529-AFE4-B30EADFE7521@umn.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (12B466) From: David Farmer Date: Tue, 10 Mar 2015 00:23:58 -0500 To: Brian E Carpenter Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Protocol Action: 'Deprecating Anycast Prefix for 6to4 Relay Routers' to Best Current Practice (draft-ietf-v6ops-6to4-to-historic-11.txt) 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, 10 Mar 2015 05:24:06 -0000 >> On Mar 9, 2015, at 21:28, Brian E Carpenter = wrote: >>=20 >>> On 10/03/2015 10:01, David Farmer wrote: >>> On 3/9/15 11:33 , The IESG wrote: >>> The IESG has approved the following document: >>> - 'Deprecating Anycast Prefix for 6to4 Relay Routers' >>> (draft-ietf-v6ops-6to4-to-historic-11.txt) as Best Current Practice >>=20 >> Good News! >>=20 >> ... >>> In response to the IANA review: >>>=20 >>> OLD: >>>=20 >>> Instead, IANA is requested to mark the 192.88.99.0/24 >>> prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay >>> Anycast)", pointing to the present document. >>>=20 >>> NEW: >>>=20 >>> Instead, IANA is requested to mark the 192.88.99.0/24 >>> prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay >>> Anycast)", pointing to the present document. The Boolean values >>> for the address block 192.88.99.0/24 will all be removed. >>=20 >> What is the rationale for removing the Boolean values? Wouldn't the curr= ent values apply until the prefix is repurposed or >> removed by future protocol action? >>=20 >> I'm not sure I really care, but I don't understand what is served by remo= ving the current values. I'm not sure what purpose the >> Boolean values really serve, but the current values seem the most appropr= iate until the prefix is permanently removed or >> repurposed. >=20 > Well, IANA wanted this change. I sympathise because it means they never ha= ve > to revisit this in the future. >=20 > Brian Why would IANA have to revisit it? Why couldn't the Boolean values be left f= orever for historic reference or at least until it is reassigned or removed b= y future protocol action, which by definition IANA would have to revisit it a= nyway. Also, the IANA review says; "and added a Termination Date upon approval of t= his draft." Does than mean the termination date in the IPv4 special-purpose= registry will be the publication date of this document? Is that what we wa= nt? That doesn't seem to jive with the general feel of the rest of the reco= mmendations in the document. In my opinion a Termination Date, two, three, o= r five years later would be much more in line with the feel of the rest of t= he document, that is why I brought it up months ago, back around -08. I let= it go thinking there wouldn't be a termination date, I guess my mistake. My suggestion would be, leave the Boolean values as-is forever, or until rea= ssigned, with a termination date some years after publication of this docume= nt, personally I'd pick three years, but anything more that a year out would= be just fine. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Mar 10 04:25:54 2015 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 B75FD1A8AF5 for ; Tue, 10 Mar 2015 04:25: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 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 pRLowSfSZX90 for ; Tue, 10 Mar 2015 04:25:52 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [46.182.8.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 BFCE21A8F40 for ; Tue, 10 Mar 2015 04:25:51 -0700 (PDT) X-Envelope-To: 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.1/8.14.9) with ESMTPSA id t2ABPe2L093309 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Mar 2015 11:25:41 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <54FED4B0.3000501@foobar.org> Date: Tue, 10 Mar 2015 11:25:36 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150309163330.30198.34988.idtracker@ietfa.amsl.com> <54FE0A1B.2010009@umn.edu> <54FE56D3.4050104@gmail.com> <66EBE2FE-2BE2-4529-AFE4-B30EADFE7521@umn.edu> In-Reply-To: <66EBE2FE-2BE2-4529-AFE4-B30EADFE7521@umn.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Protocol Action: 'Deprecating Anycast Prefix for 6to4 Relay Routers' to Best Current Practice (draft-ietf-v6ops-6to4-to-historic-11.txt) 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, 10 Mar 2015 11:25:53 -0000 On 10/03/2015 05:23, David Farmer wrote: > My suggestion would be, leave the Boolean values as-is forever, or until > reassigned, with a termination date some years after publication of this > document, personally I'd pick three years, but anything more that a year > out would be just fine. I'm pretty good with IANA's suggestion here and don't see any value in delaying publication of this draft any further. Nick From nobody Tue Mar 10 07:52:16 2015 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 128661A87C8 for ; Tue, 10 Mar 2015 07:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 zEVijEen5SD5 for ; Tue, 10 Mar 2015 07:52:13 -0700 (PDT) Received: from mail-05.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0DD1A87EB for ; Tue, 10 Mar 2015 07:52:13 -0700 (PDT) Received: from [24.114.105.31] (helo=[172.20.10.4]) by mail-05.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YVLW0-0001M9-Cn; Tue, 10 Mar 2015 10:52:12 -0400 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2015 10:52:10 -0400 Message-Id: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> To: v6ops list Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.105.31] Archived-At: Subject: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 14:52:15 -0000 Just want to get some direct feedback from the WG on the use of the = terms "unnumbered interface" and "unnumbered link" in IPv6. Mark Smith, in some comments on the Design Choices draft , has said that = he prefers the terms "interface with only link-local address" or "link = with only link-local addresses" instead. See the thread with title = "I-D Action: draft-ietf-v6ops-design-choices-04.txt". What does the WG think? Should we use the "unnumbered" terms, or should = we use just the "... with only link-local address" terms? Is it = acceptable to mix the two sets of terms? Philip From nobody Tue Mar 10 07:56:50 2015 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 567D31A88F3 for ; Tue, 10 Mar 2015 07:56: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 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 Tmsu-Gm80ewg for ; Tue, 10 Mar 2015 07:56:44 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [46.182.8.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 9AFD31A87EB for ; Tue, 10 Mar 2015 07:56:44 -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.1/8.14.9) with ESMTPSA id t2AEu3Rp097771 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 14:56:03 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <54FF0602.40007@foobar.org> Date: Tue, 10 Mar 2015 14:56:02 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Fernando Gont , "v6ops@ietf.org" References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> In-Reply-To: <54FE4416.60601@gont.com.ar> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 10 Mar 2015 14:56:48 -0000 On 10/03/2015 01:08, Fernando Gont wrote: > Please do let us now if you have any feedback. Interesting. Where did you take the measurements from? Nick From nobody Tue Mar 10 08:39:56 2015 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 788B51A005A for ; Tue, 10 Mar 2015 08:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 TXmZcbudjGwl for ; Tue, 10 Mar 2015 08:39:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3401A004A for ; Tue, 10 Mar 2015 08:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1115; q=dns/txt; s=iport; t=1426001990; x=1427211590; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=l3JV2pQM1nC+PQXz1tNQBIQgosrgESxkUx7ZEzJq/EQ=; b=JHui/9wJyIA8Q//tlOkZMgQ4UyspgAflKOIw3FDv/JbTJiiA9AV5sCoQ ndyTyXs+hwMfoUnHPNfBY9sEyEZ3ngQ3q6ugBWYPe1X3KLvzPJLjF+v6z MkmaPOJ8a1TvgVy2o04xljeZKVvjgjIy0ZyUwlaBI+q0g6aYckP3X/jn2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQDvD/9U/5RdJa1cgwZSWgTDHAqFcAKBMU0BAQEBAQF8hA8BAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCIgnDcQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLF4Q9OAaDEYEWBZAPnUcjggIcgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,375,1422921600"; d="scan'208";a="402364660" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 10 Mar 2015 15:39:49 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2AFdn5f017292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 15:39:49 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 10:39:45 -0500 From: "Hemant Singh (shemant)" To: Philip Matthews , v6ops list Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQW0JYf2S2+ZRJj0CYzJMkYUm+4p0V2Y2A Date: Tue, 10 Mar 2015 15:39:44 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8916815D20@xmb-rcd-x06.cisco.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 15:39:54 -0000 I would use "unnumbered" which is then one common term with ipv4 and ipv6 u= sed for interfaces on routers from multiple vendors.=20 Thanks, Hemant -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Matthews Sent: Tuesday, March 10, 2015 10:52 AM To: v6ops list Subject: [v6ops] Should we use "unnumbered" in IPv6? Just want to get some direct feedback from the WG on the use of the terms "= unnumbered interface" and "unnumbered link" in IPv6. Mark Smith, in some comments on the Design Choices draft , has said that he= prefers the terms "interface with only link-local address" or "link with o= nly link-local addresses" instead. See the thread with title "I-D Action:= draft-ietf-v6ops-design-choices-04.txt". What does the WG think? Should we use the "unnumbered" terms, or should we= use just the "... with only link-local address" terms? Is it acceptable t= o mix the two sets of terms? Philip _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Mar 10 09:12:48 2015 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 A0CD71A1B8B for ; Tue, 10 Mar 2015 09:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 rLTcOxe_-m6k for ; Tue, 10 Mar 2015 09:12:45 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967681A1B8F for ; Tue, 10 Mar 2015 09:12:36 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 3f71ff45.0.1247038.00-2201.3486840.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 10 Mar 2015 16:12:36 +0000 (UTC) X-MXL-Hash: 54ff17f4717319ca-3f8ddafc42699ba128c063e0e1510154725a3f0a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2AGCYWW012572; Tue, 10 Mar 2015 12:12:34 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2AGCNiZ012423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Mar 2015 12:12:27 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 10 Mar 2015 16:12:09 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.37]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0224.002; Tue, 10 Mar 2015 12:12:09 -0400 From: "STARK, BARBARA H" To: Philip Matthews , v6ops list Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQW0HTW7hAkTqBNEKfP9t3RQj7L50V1FhA Date: Tue, 10 Mar 2015 16:12:09 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F60D74@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.33.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=c+kct2Bl c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=MKhEqXPmjPsA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=emO1SXQWCLwA:10 a=mYPrF8hoA] X-AnalysisOut: [AAA:8 a=XHjs85LWlYBBVwGRymsA:9 a=CjuIK1q_8ugA:10 a=WWkx8g7] X-AnalysisOut: [mLaDGaNnS:21 a=5gJ9zqTZwelhfi4D:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 16:12:46 -0000 > Just want to get some direct feedback from the WG on the use of the terms > "unnumbered interface" and "unnumbered link" in IPv6. >=20 > Mark Smith, in some comments on the Design Choices draft , has said that = he > prefers the terms "interface with only link-local address" or "link with = only > link-local addresses" instead. See the thread with title "I-D Action: d= raft-ietf- > v6ops-design-choices-04.txt". >=20 > What does the WG think? Should we use the "unnumbered" terms, or > should we use just the "... with only link-local address" terms? Is it > acceptable to mix the two sets of terms? My experience with "unnumbered" interfaces is exclusively in the access net= work, specifically on the WAN interface of a CE (customer edge) router. In that context (to provide a point of reference as to the term's use elsew= here in the industry, just FYI), BBF TR-177 (http://www.broadband-forum.org= /technical/download/TR-177.pdf ) defines the following terms: Numbered WAN model: The WAN interface of the RG has its own IPv6 GUA. Unnumbered WAN model: The WAN interface of the RG does not have its own IPv= 6 GUA. Since the CE router (aka RG) has multiple interfaces (and not just the WAN)= , this does not prevent the CE router from having a GUA assigned to one of = its other interfaces (which it takes from its delegated prefix -- see RFC 7= 084, WAA-7). This provides the CE router with a globally ping-able address,= which effectively handles some of the negatives of these interfaces. I'm also familiar with the use of the "unnumbered" term related to CE route= r WAN interfaces intended to handle receiving IPv4 multicast (IPTV) traffic= . 0.0.0.0 is often used for that interface. But since the CE router also ha= s a "normal" WAN interface (the WAN "link" has separate VLANs for multicast= and regular Internet traffic), this doesn't result in any of the described= problems. Out of curiosity: CE routers don't seem to be a primary target of this draf= t, but are they excluded? To get back to the question of whether to use "unnumbered" in this draft: "= Unnumbered" is only used 5 times in the draft. I think that its common use = in the industry makes it ok, but I also think "unnumbered interface" could= be easily replaced with "interface without a link-local address". The firs= t instance ' a. Use only link-local addresses ("unnumbered") ' should stay= to acknowledge the fact that this word is widely used in this context. I h= ave to admit to not completely understanding what an "unnumbered link" is (= in the last instance of "unnumbered"), given that it's possible for a link = to have multiple interfaces (from the draft: "separate interfaces" can exis= t as "two VLANs on the same link"), some of which may be numbered and some = of which may be unnumbered (based on my CE router IPTV experiences). Does "= unnumbered link" mean a link where all of its interfaces are unnumbered (ha= ve no link-local address)? Anyway, I'm ambivalent about making the change. = I think it's fine either way (as long as the first instance of "unnumbered"= stays). Barbara From nobody Tue Mar 10 09:15:27 2015 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 B1CD11A1BA4 for ; Tue, 10 Mar 2015 09:15:25 -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 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 IZGHjbql_5Iz for ; Tue, 10 Mar 2015 09:15:23 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 A931C1A1B8E for ; Tue, 10 Mar 2015 09:15:23 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0162760B46 for ; Tue, 10 Mar 2015 17:15:22 +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 B89A6600DF for ; Tue, 10 Mar 2015 17:15:21 +0100 (CET) Received: (qmail 8565 invoked by uid 1007); 10 Mar 2015 17:15:21 +0100 Date: Tue, 10 Mar 2015 17:15:21 +0100 From: Gert Doering To: Philip Matthews Message-ID: <20150310161521.GL54385@Space.Net> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 16:15:25 -0000 Hi, On Tue, Mar 10, 2015 at 10:52:10AM -0400, Philip Matthews wrote: > Just want to get some direct feedback from the WG on the use of the terms "unnumbered interface" and "unnumbered link" in IPv6. > > Mark Smith, in some comments on the Design Choices draft , has said that he prefers the terms "interface with only link-local address" or "link with only link-local addresses" instead. See the thread with title "I-D Action: draft-ietf-v6ops-design-choices-04.txt". > > What does the WG think? Should we use the "unnumbered" terms, or should we use just the "... with only link-local address" terms? Is it acceptable to mix the two sets of terms? I'm fine with "unnumbered", but then, I have a router background with the config option "ip[v6] unnumbered " being frequently used... and it's less words, so, preferred :-) OTOH I wouldn't mind a footnote on the first use of "unnumbered" explaining that "for the purpose of this document, this identifies an interface or link that only has link-local addresses". 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 Tue Mar 10 09:20:28 2015 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 B84221A1B8D for ; Tue, 10 Mar 2015 09:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 lkKLfQAPLHjz for ; Tue, 10 Mar 2015 09:20:25 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::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 EA1071A1B46 for ; Tue, 10 Mar 2015 09:20:24 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id la4so922363vcb.10 for ; Tue, 10 Mar 2015 09:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gbcncr1zjDeXlBzYOoJKxZwnOxwIeIiwUEI/mS4nmYc=; b=j/WGxw8tKB57F7uctYoSNyDg2VaMcLpie9YO5dFl1YPHsA4PFAxTiDG8AYmMTXO1rj kfZpgwZ+Xbd/+ZyVz+9wl2D1kCBfehzvUhUkqqAY4nPmh1dtGd7nYj/LTHY1z1yV1zkM UYj5hOPFBRrLihIVYNpRQtRvZ5Az1aFEw/9Y/UxGqJkrCN0VRRYyc97dhRFpiIDX/gWW 8BvEYo5aa3CfK70Lu5Z3B62vTmA4ueol3wpXHn0TYzm1Q/6m61Y3CPypwZfOAuyHcJNY 5JEJRD/CoUgcgYS6lsnIKPcOrxvZYA3o1p+zKiab+CrXb38pWx4kIyk49GJReIjYnAHO l/eA== X-Received: by 10.52.99.226 with SMTP id et2mr5368101vdb.14.1426004424108; Tue, 10 Mar 2015 09:20:24 -0700 (PDT) Received: from [192.168.1.11] ([186.188.89.177]) by mx.google.com with ESMTPSA id jr8sm162533vdb.25.2015.03.10.09.20.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 09:20:22 -0700 (PDT) Message-ID: <54FF19C1.2030303@gmail.com> Date: Tue, 10 Mar 2015 11:50:17 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 16:20:26 -0000 Hello, I feel comfortable with the term unnumbered. It's easier to read. Of course in the document should be expressed that such interfaces/links have only-link-local addresses. Alejandro, El 3/10/2015 a las 10:22 AM, Philip Matthews escribió: > Just want to get some direct feedback from the WG on the use of the terms "unnumbered interface" and "unnumbered link" in IPv6. > > Mark Smith, in some comments on the Design Choices draft , has said that he prefers the terms "interface with only link-local address" or "link with only link-local addresses" instead. See the thread with title "I-D Action: draft-ietf-v6ops-design-choices-04.txt". > > What does the WG think? Should we use the "unnumbered" terms, or should we use just the "... with only link-local address" terms? Is it acceptable to mix the two sets of terms? > > Philip > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Mar 10 09:25:00 2015 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 34EE11A1BE9 for ; Tue, 10 Mar 2015 09:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cUVdcGUDxNCJ for ; Tue, 10 Mar 2015 09:24:57 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 831471A1DBC for ; Tue, 10 Mar 2015 09:24:52 -0700 (PDT) Received: (qmail 92431 invoked from network); 10 Mar 2015 16:24:50 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Mar 2015 16:24:50 -0000 Date: Tue, 10 Mar 2015 17:24:50 +0100 (CET) Message-Id: <20150310.172450.74663157.sthaug@nethelp.no> To: shemant@cisco.com From: sthaug@nethelp.no In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8916815D20@xmb-rcd-x06.cisco.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <75B6FA9F576969419E42BECB86CB1B8916815D20@xmb-rcd-x06.cisco.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, philip_matthews@magma.ca Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 16:24:59 -0000 > I would use "unnumbered" which is then one common term with ipv4 and ipv6 used for interfaces on routers from multiple vendors. Agreed. Steinar Haug, AS 2116 From nobody Tue Mar 10 11:31:24 2015 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 E8F711A87A7 for ; Tue, 10 Mar 2015 11:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 RSVeMgtKKuVB for ; Tue, 10 Mar 2015 11:31:21 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1911A87A8 for ; Tue, 10 Mar 2015 11:31:21 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 10 Mar 2015 13:31:20 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f176.google.com [209.85.213.176] #+LO+TS+TR X-Umn-Classification: local Received: by igbhl2 with SMTP id hl2so6139032igb.5 for ; Tue, 10 Mar 2015 11:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aC6LAER/X2TMgnuY8X/fZARwkrBFyRIQrTkF42WXwqA=; b=UXnl96NWjBTg/t+pwIYlR3flcKPDhMlCriQqtTBiCP1Rgh86lL5YPaLebQPv4ha/Rc YinxUvyiJwCukdorrh8xXh9wD3AhJEgAmUOfxGWleVbmEn4sBAdK8DpUOxsxIXP3m9K4 46ZQNLVT2vKKQU4sgt2weRfXlpO8f4n4ep7lM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=aC6LAER/X2TMgnuY8X/fZARwkrBFyRIQrTkF42WXwqA=; b=IStNXKTcExxcltxgK1ZKfv9FYEqfubmOhDFJRf5Br961C9lilQ0k/E5PFpCEKwtXQD Z2XD1I74HWlCw7iu84GbZbMS3gLYX3ozw48MweWv8wqU8AgxIh/F3wfzcSxkZTqM6Fyl X+SX2EcT4AaRg7VIz84eMWi6DWzeSCDoZSA1Ia9J+hsla/kStpcivdaaS6PvN0WgcSBu c3p0hOvqcnTFYmakICQgdnAYV54XBSiLkSiJ40gE2gYUU8+N+09rCr5tuCILjVB9UDry JcKrCYcuf5uN4LDYrIv3pRZAQmOBgzPorkrWmaJWh1c5sDHWcWomk4Z/6HDYOtPvTH5X Enww== X-Gm-Message-State: ALoCoQlWah1IYjERJzxzPjBxW6N7zRbuxEEZNsDv0x07PxoSc/SgmTzuOIOzET4v+DSfX2Xg2de/G2OMh30ez6MjbIn8yyJAkkciduMzzVXOutBQuq8nutorqMLXlr9axKww51qZBS9/ X-Received: by 10.107.8.215 with SMTP id h84mr34519703ioi.89.1426012279865; Tue, 10 Mar 2015 11:31:19 -0700 (PDT) X-Received: by 10.107.8.215 with SMTP id h84mr34519681ioi.89.1426012279638; Tue, 10 Mar 2015 11:31:19 -0700 (PDT) Received: from x-160-94-7-154.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:a8e4:8907:918a:4a19]) by mx.google.com with ESMTPSA id k9sm926784ige.6.2015.03.10.11.31.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 11:31:17 -0700 (PDT) Message-ID: <54FF3871.2060103@umn.edu> Date: Tue, 10 Mar 2015 13:31:13 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nick Hilliard , v6ops@ietf.org References: <20150309163330.30198.34988.idtracker@ietfa.amsl.com> <54FE0A1B.2010009@umn.edu> <54FE56D3.4050104@gmail.com> <66EBE2FE-2BE2-4529-AFE4-B30EADFE7521@umn.edu> <54FED4B0.3000501@foobar.org> In-Reply-To: <54FED4B0.3000501@foobar.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Protocol Action: 'Deprecating Anycast Prefix for 6to4 Relay Routers' to Best Current Practice (draft-ietf-v6ops-6to4-to-historic-11.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:31:23 -0000 On 3/10/15 06:25 , Nick Hilliard wrote: > On 10/03/2015 05:23, David Farmer wrote: >> My suggestion would be, leave the Boolean values as-is forever, or until >> reassigned, with a termination date some years after publication of this >> document, personally I'd pick three years, but anything more that a year >> out would be just fine. > > I'm pretty good with IANA's suggestion here and don't see any value in > delaying publication of this draft any further. > > Nick I certainly don't want to hold things up, I've said my piece and will leave it at that. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Mar 10 12:41:55 2015 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 0B30E1A8891 for ; Tue, 10 Mar 2015 12:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 plJvStVzch1p for ; Tue, 10 Mar 2015 12:41:51 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934651A886F for ; Tue, 10 Mar 2015 12:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2268; q=dns/txt; s=iport; t=1426016512; x=1427226112; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5c9BQdbUUUK0a1iQZqcnal9g4fzpRSLWoTEsnhO8sb8=; b=ALflDH8EtOI0DqlAE4mnQ0fshbaHJX63NCuhFn1NM8NMFCGQqXQjzBPo Qwl6ovBEtM3N4cBbsj9BfTiDFOPbX+xtMN1GMn0BjPnJ71IauItDTOnoJ 9kjbBCTZ76BK5mi9pIOHTGcAo5mp9SHr4VpO2485/eVaE7srdViR05uA+ 0=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQB5SP9U/5hdJa1cgwaBLASDBsYSAoE3TQEBAQEBAXyEDwEBAQMBI1YFCwIBCBgqAgIyJQIEDgUOiBkIqWWbbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLF4RuB4JoL4EWBZAPgWWBLoZAk3QjggIcgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,376,1422921600"; d="asc'?scan'208";a="130718081" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 10 Mar 2015 19:41:52 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2AJfos5023832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 19:41:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 14:41:50 -0500 From: "Fred Baker (fred)" To: Philip Matthews Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQW2pApqLwHxeG906iXGvBD/f1zw== Date: Tue, 10 Mar 2015 19:41:49 +0000 Message-ID: References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.61.251] Content-Type: multipart/signed; boundary="Apple-Mail=_14054861-B5C3-45F3-8FBE-322CEFF48C3E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 19:41:53 -0000 --Apple-Mail=_14054861-B5C3-45F3-8FBE-322CEFF48C3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 10, 2015, at 7:52 AM, Philip Matthews = wrote: >=20 > Just want to get some direct feedback from the WG on the use of the = terms "unnumbered interface" and "unnumbered link" in IPv6. >=20 > Mark Smith, in some comments on the Design Choices draft , has said = that he prefers the terms "interface with only link-local address" or = "link with only link-local addresses" instead. See the thread with = title "I-D Action: draft-ietf-v6ops-design-choices-04.txt". >=20 > What does the WG think? Should we use the "unnumbered" terms, or = should we use just the "... with only link-local address" terms? Is it = acceptable to mix the two sets of terms? =46rom my perspective, Mark is correct. IPv4 actually has unnumbered links - links with no address. On such = links, when one sends a packet, one uses the address found on a = different interface, and the only system that can send to you on the = unnumbered link using the borrowed address is one that is sending to the = *interface* as opposed to the *address* - a neighboring router. In IPv6, one actually does have an address on every link (if only the = link-local address), and as a result never =E2=80=9Cborrows=E2=80=9D an = address from another interface. --Apple-Mail=_14054861-B5C3-45F3-8FBE-322CEFF48C3E 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 iQEVAwUBVP9I/J9ieig10VPpAQIztgf/QObiDhl4NmXfCYN3mQWk8JzyCJav5uK4 mJ3xBaofuy1H1tcQbsGbObBZc31O54oBYTU9MZdxuTKHSPadk4E0OrorwIYzLcOu 2I+etsSwcNVuMoOGocbc3E456SHStUESUXVtif3xW/iPv43pwTyekzop6uxwlQSq 03YbzPIUNC+bZFaYZOL/Ih18h3Z3vrnpXF3Elu3CtPwGPNv3aJXowhwRaBNiVYdv LB1EWvi1pmKHDjquvspTyk3+9WZC4qZWyyZxTfuU54XXGKzH1G1XBFLtDqus6cPq LOLBNVIZt1aNh3jah/oMemCNg9qlikQ40PC8qtbAfbrd2tBzWBLaPw== =TBK+ -----END PGP SIGNATURE----- --Apple-Mail=_14054861-B5C3-45F3-8FBE-322CEFF48C3E-- From nobody Tue Mar 10 13:29:35 2015 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 647921A8954 for ; Tue, 10 Mar 2015 13:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 NKZEgSVMCClY for ; Tue, 10 Mar 2015 13:29:33 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 862271A895B for ; Tue, 10 Mar 2015 13:29:32 -0700 (PDT) Received: by padet14 with SMTP id et14so5145161pad.0 for ; Tue, 10 Mar 2015 13:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BLdhpCDUlX6lT07hdICLyHk0uXvlqDbnO6hYgSZIR9Y=; b=veZhkaslD2dn8qGm3q3qxcupY9I2QzQM8nvNl884U7zZRc5/Y73pjGqAcjCpZQ64bR yVI0CGeLQnRAzpvIvSwUUjUZRJaieVzkUM5vacrB9fsxzBQJRGfKZNRg3CtlSsz0wkxQ 877IWTe3+LKjk56Qz8Hj4RU8uusMwOIv1tL2oArDK1TZffTqyNlwXIAij3tnmWfCGsy3 RkWtuxb07wBAkvCoYYtSVzw4jZAeije0ToEi7utz470PEOPD8WZ7ch5L/uaqGxgv/iQn He36Bpf6zqsnJqqW1zpRmL6Oz3+zX90qmjJRxvRppFx2BB+kkUsXIOGb3BKwfJkc8su9 0fMw== X-Received: by 10.66.218.10 with SMTP id pc10mr69578478pac.116.1426019372239; Tue, 10 Mar 2015 13:29:32 -0700 (PDT) Received: from [10.1.9.163] ([103.23.18.15]) by mx.google.com with ESMTPSA id w1sm2468624pdp.25.2015.03.10.13.29.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 13:29:31 -0700 (PDT) Message-ID: <54FF5427.9070100@gmail.com> Date: Wed, 11 Mar 2015 09:29:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Philip Matthews References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 20:29:34 -0000 On 11/03/2015 08:41, Fred Baker (fred) wrote: >=20 >> On Mar 10, 2015, at 7:52 AM, Philip Matthews wrote: >> >> Just want to get some direct feedback from the WG on the use of the te= rms "unnumbered interface" and "unnumbered link" in IPv6. >> >> Mark Smith, in some comments on the Design Choices draft , has said th= at he prefers the terms "interface with only link-local address" or "link= with only link-local addresses" instead. See the thread with title "I-= D Action: draft-ietf-v6ops-design-choices-04.txt". >> >> What does the WG think? Should we use the "unnumbered" terms, or shou= ld we use just the "... with only link-local address" terms? Is it accep= table to mix the two sets of terms? >=20 > >=20 > From my perspective, Mark is correct. >=20 > IPv4 actually has unnumbered links - links with no address. On such lin= ks, when one sends a packet, one uses the address found on a different in= terface, and the only system that can send to you on the unnumbered link = using the borrowed address is one that is sending to the *interface* as o= pposed to the *address* - a neighboring router. >=20 > In IPv6, one actually does have an address on every link (if only the l= ink-local address), and as a result never =E2=80=9Cborrows=E2=80=9D an ad= dress from another interface. Well, hang on. There is the infamous case of traceroutes including link-l= ocal addresses, and the correct fix is to borrow another address from the box to provide a global address. But I agree that the terminology is slippery (as is the term "loopback in= terface"). Brian From nobody Tue Mar 10 14:15:36 2015 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 DF68C1A8A1C for ; Tue, 10 Mar 2015 14:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 IYd8pP0X9taf for ; Tue, 10 Mar 2015 14:15:33 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3091A8A1B for ; Tue, 10 Mar 2015 14:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1704; q=dns/txt; s=iport; t=1426022133; x=1427231733; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cTpU7agHGX/07bHS5yyqouftaDJzBpdFvtraa3qnaJo=; b=bHlumuKXnDzPlG7pZVZF085HaFTTyYd8lF1lzgesZ5xJ1ggUJaVH+Vac 9RcaWDq7+FD2NJhOKXHLjswNAAa+DSqt1cUCSgCOsTcE+Bc8hIxfcW8+X ulccKiVaG50Nh0umQjSszc4u1igZZVy+wMvxiq4rLrm1bJDmzUvx2TZgT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D4BAAUXv9U/4wNJK1cgwZSXoMGvjqBPQqFcAIcgRQ4FAEBAQEBAQF8hBABAQQBAQEgETobAgEIGgImAgICJQsVEAIEARKILw2qM5lmAQEBAQEBAQEBAQEBAQEBAQEBARUEgSGJcYQ7GCKCaIFDBY92iUWTVSOCAhyBUG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208";a="130643310" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 10 Mar 2015 21:15:32 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALFWlZ021271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:15:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:15:32 -0500 From: "Eric Vyncke (evyncke)" To: Philip Matthews , v6ops list Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQW0I1uQYBaAv2dE6BA2cKOMS2n50WnLyA Date: Tue, 10 Mar 2015 21:15:31 +0000 Message-ID: References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.68] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 21:15:35 -0000 UGhpbGlwDQoNCkluIHRoZSBsZWdhY3kgd29ybGQgb2YgSVB2NCwgdW5udW1iZXJlZCBhY3R1YWxs eSBtZWFucyB1c2luZyBhIGdsb2JhbCBJUHY0DQphZGRyZXNzICdzdG9sZW4nIGZyb20gYW5vdGhl ciBpbnRlcmZhY2UuDQoNCkluIHRoZSBjdXJyZW50IHdvcmxkIG9mIElQdjYsIGV2ZXJ5IGludGVy ZmFjZSBoYXMgYXQgbGVhc3QgYSBsaW5rLWxvY2FsDQphZGRyZXNzIHdoaWNoIGNhbiBiZSB1c2Vk IGZvciBJR1AgYW5kIG90aGVyIHB1cnBvc2VzIChzZWUgUkZDIDc0MDQpIHdoaWNoDQppcyBOT1Qg ZXF1aXZhbGVudCAoSU1ITykgdG8gJ3VubnVtYmVyZWQgaW50ZXJmYWNlJw0KDQpTbywgSSBhbSBh ZnJhaWQgdGhhdCB5b3Ugc2hvdWxkIHVzZSBhbm90aGVyIHdvcmtpbmcgKGFsYmVpdCBjdW1iZXJz b21lKQ0KDQotw6lyaWMNCg0KT24gMTAvMDMvMTUgMTU6NTIsICJQaGlsaXAgTWF0dGhld3MiIDxw aGlsaXBfbWF0dGhld3NAbWFnbWEuY2E+IHdyb3RlOg0KDQo+SnVzdCB3YW50IHRvIGdldCBzb21l IGRpcmVjdCBmZWVkYmFjayBmcm9tIHRoZSBXRyBvbiB0aGUgdXNlIG9mIHRoZSB0ZXJtcw0KPiJ1 bm51bWJlcmVkIGludGVyZmFjZSIgYW5kICJ1bm51bWJlcmVkIGxpbmsiIGluIElQdjYuDQo+DQo+ TWFyayBTbWl0aCwgaW4gc29tZSBjb21tZW50cyBvbiB0aGUgRGVzaWduIENob2ljZXMgZHJhZnQg LCBoYXMgc2FpZCB0aGF0DQo+aGUgcHJlZmVycyB0aGUgdGVybXMgImludGVyZmFjZSB3aXRoIG9u bHkgbGluay1sb2NhbCBhZGRyZXNzIiBvciAibGluaw0KPndpdGggb25seSBsaW5rLWxvY2FsIGFk ZHJlc3NlcyIgaW5zdGVhZC4gICBTZWUgdGhlIHRocmVhZCB3aXRoIHRpdGxlICJJLUQNCj5BY3Rp b246IGRyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMtMDQudHh0Ii4NCj4NCj5XaGF0IGRv ZXMgdGhlIFdHIHRoaW5rPyAgU2hvdWxkIHdlIHVzZSB0aGUgInVubnVtYmVyZWQiIHRlcm1zLCBv ciBzaG91bGQNCj53ZSB1c2UganVzdCB0aGUgIi4uLiB3aXRoIG9ubHkgbGluay1sb2NhbCBhZGRy ZXNzIiB0ZXJtcz8gIElzIGl0DQo+YWNjZXB0YWJsZSB0byBtaXggdGhlIHR3byBzZXRzIG9mIHRl cm1zPw0KPg0KPlBoaWxpcA0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBsaXN0DQo+djZvcHNAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg== From nobody Tue Mar 10 14:53:55 2015 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 17B591A8F41 for ; Tue, 10 Mar 2015 14:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Of5ZTIEIGLwZ for ; Tue, 10 Mar 2015 14:53:52 -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 929AC1A8F3D for ; Tue, 10 Mar 2015 14:53:52 -0700 (PDT) Received: from mb-aye.local ([172.56.16.29]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t2ALrl3E035802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Mar 2015 21:53:48 GMT (envelope-from joelja@bogus.com) Message-ID: <54FF67E6.6070202@bogus.com> Date: Tue, 10 Mar 2015 14:53:42 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" , Philip Matthews , v6ops list References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lp6MAtUcKnX5XP7J82aNLm8hvjkGrrOJ6" Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 10 Mar 2015 21:53:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lp6MAtUcKnX5XP7J82aNLm8hvjkGrrOJ6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable given that we have the link local only draft floating around it seems like we have discussed this some in the v6 context. there are certain things you need or should use a globally signficant ip for (responding to traceroute for example). and some thing link local is more than sufficient for (forming an adjacency) On 3/10/15 2:15 PM, Eric Vyncke (evyncke) wrote: > Philip >=20 > In the legacy world of IPv4, unnumbered actually means using a global I= Pv4 > address 'stolen' from another interface. >=20 > In the current world of IPv6, every interface has at least a link-local= > address which can be used for IGP and other purposes (see RFC 7404) whi= ch > is NOT equivalent (IMHO) to 'unnumbered interface' >=20 > So, I am afraid that you should use another working (albeit cumbersome)= >=20 > -=C3=A9ric >=20 > On 10/03/15 15:52, "Philip Matthews" wrote: >=20 >> Just want to get some direct feedback from the WG on the use of the te= rms >> "unnumbered interface" and "unnumbered link" in IPv6. >> >> Mark Smith, in some comments on the Design Choices draft , has said th= at >> he prefers the terms "interface with only link-local address" or "link= >> with only link-local addresses" instead. See the thread with title "= I-D >> Action: draft-ietf-v6ops-design-choices-04.txt". >> >> What does the WG think? Should we use the "unnumbered" terms, or shou= ld >> we use just the "... with only link-local address" terms? Is it >> acceptable to mix the two sets of terms? >> >> Philip >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --lp6MAtUcKnX5XP7J82aNLm8hvjkGrrOJ6 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlT/Z+YACgkQ8AA1q7Z/VrItywCfVpYWZsqnvH0wyNXzdaiyAnr1 oyoAnjec1naNOJE5taP8bYFtL9c+RLtD =MoRs -----END PGP SIGNATURE----- --lp6MAtUcKnX5XP7J82aNLm8hvjkGrrOJ6-- From nobody Tue Mar 10 17:15:58 2015 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 942B11A884C for ; Tue, 10 Mar 2015 17:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] 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 l6e05RAfyLIq for ; Tue, 10 Mar 2015 17:15:55 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03351A8830 for ; Tue, 10 Mar 2015 17:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1426032953; bh=WSK8PNAF5KwHHI54I8D6doncAyjLzsT2MUEx7USRjUU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=FUzXm/qrv1OYSApumWg42falJU66kcJAcDnh+Bh9l0QBzriNos+Mx47qiE6W13KBD4Y06vqmoI6GiuEFrnkYhSh7oOGyE9eUOTJpntidpUUdjE7nqLSk0i4qzd9vOuKYM+19GdOD1UGJeWmPMASQbN+8yltdbqjKYX27J56xqO++BxwkEH+fqDI2y3zBY9/u0DjS86DbvEIvR76OLwAaAMsDJo9KSnaQaBbqtgOh91eVS2bfoVK7OSlr6NgqZ28cOnS7nHdJXzKs/oo6ijWH2yD2XfaPs7YG8O75oX5kfzM6iXQhIxAcsP+CDckbrXxGFAcKDvb9wWyApo+ZdQta9w== Received: from [98.139.215.143] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2015 00:15:53 -0000 Received: from [98.139.212.231] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2015 00:15:53 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 11 Mar 2015 00:15:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 606193.6891.bm@omp1040.mail.bf1.yahoo.com X-YMail-OSG: kdrSz08VM1nVpAhJGUZu.2Ti1cDk3QPD7VpYFL9jsfDCNS8fVIFK2e62iTxIVrf xckts0HrkdDimwALaDOJz761KXfyB_7cEQZYW8L1EN.YvpvQ2NcxSfm_ihrhHKCimwBblYbafaLn sntY2nCMxPIANc5ZpZ7fQwnU2Dv4zS5MXmmrt39rYaPF.o2cs7iiVsskSjqqELM.8p1v2xXl6jrF iMgM.lAClYh57lJrZvDSwlm5Sc9CYjbOo5z5dDhqDGTIVcEB2Cf1_pIqgKutewMllZoMelOeuALj IVUB5nhBNMX1O9enAeaCfBXGptNqhKHy8ZZPbp6_58J1MtfwK0jgxgPG7EehNrKb40Oewo9j384U lkp6TWp5o0HY0TSsNylabr8I0K0tuc7jsTc0An6ku7KgoZe3R2muq0jVfLQgUuzJ3NPC2VjcUvu8 zQbTpbbYBFxYDxZ8xNHFTPMSTswDc4XXHY8U9sAnFMnNNxWFL3At3dQk_F531N7T72KrFgyKRQnt .B4tqPHr5021HnVzuKzhak8Jg_eQQw76bfwvJkXGKaXLksCjt4w-- Received: by 66.196.80.118; Wed, 11 Mar 2015 00:15:53 +0000 Date: Wed, 11 Mar 2015 00:15:52 +0000 (UTC) From: Mark ZZZ Smith To: Philip Matthews , v6ops list Message-ID: <272079633.3209850.1426032952692.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:15:56 -0000 People probably haven't seen the text I wrote regarding why I don't think "unnumbered" should be used, so here it is. Also, people in this thread putting "unnumbered" in quotes also indicates that it is an inaccurate term. If term was a good and accurate one to use, then it wouldn't need quotes. / The concern I have with continuing to use an incorrect term, even though it might be fairly commonly used, is that the longer it is used, the longer it can cause confusion or error, and the longer it encourages the use of the inaccurate term. / Somebody who knows very little about IPv6 (which might be a reasonable portion of the audience of your document) would assume an 'unnumbered' link would have no IPv6 addressing present at all on any of the attached interfaces, because that is the case with IPv4. That misunderstanding can have security implications, as unnumbered IPv4 links can't by default support IPv4 applications if hosts are attached to the IPv4 unnumbered link, where as 'unnumbered' IPv6 links can (because they're not actually unnumbered). / Another point of confusion would be that in IPv4, unnumbered links are usually only serial point-to-point links between routers, meaning that hosts can't physically be attached to the link, where as any type of link can be an IPv6 "unnumbered" link, so hosts may be physically attached to the link if the link-layer is multi-access. / These subtle yet significant differences are the ones that, if hidden by incorrect terminology, create opportunities for security or operational problems. In my experience avoiding those issues is far cheaper and easier than cleaning up after they've occurred. / I think in your document it would be better to use the term 'link-local only' throughout the document, and just acknowledge once early in the document that it has been also described as 'unnumbered' as it is somewhat similar to the IPv4 concept of unnumbered link, but certainly isn't the same. ----- Original Message ----- From: Philip Matthews To: v6ops list Cc: Victor Kuarsingh ; Mark ZZZ Smith Sent: Wednesday, 11 March 2015, 1:52 Subject: Should we use "unnumbered" in IPv6? Just want to get some direct feedback from the WG on the use of the terms "unnumbered interface" and "unnumbered link" in IPv6. Mark Smith, in some comments on the Design Choices draft , has said that he prefers the terms "interface with only link-local address" or "link with only link-local addresses" instead. See the thread with title "I-D Action: draft-ietf-v6ops-design-choices-04.txt". What does the WG think? Should we use the "unnumbered" terms, or should we use just the "... with only link-local address" terms? Is it acceptable to mix the two sets of terms? Philip From nobody Tue Mar 10 17:23:00 2015 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 D1E221A884F for ; Tue, 10 Mar 2015 17:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] 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 8yyBtDeH9axd for ; Tue, 10 Mar 2015 17:22:59 -0700 (PDT) Received: from nm33-vm2.bullet.mail.bf1.yahoo.com (nm33-vm2.bullet.mail.bf1.yahoo.com [72.30.239.202]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CBB1A8734 for ; Tue, 10 Mar 2015 17:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1426033378; bh=fjjEDNboAyf6hzPlsew6LKpc8/YnXbKRde+66r2vsqc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=KFfkVlmLnuqNixK+ykWW/8IngUhqEvfyGQ9+4opjQiHS3pLLZeIfwoC9hk8va90msVCPMqUTWW2KnSLW4z1oldh1C15olkncpXkxXfCkrFo5AW1FNz5fJiSxxJwhyhXSHLPz/lFcEU+COitMVTczAkfLcoSdOM6xVR9vHaa/70YqsAuuPpQlk5yEmS/JjTE7l8gJdWv0+Pqo07UWTmgO4Lbgw9bp65GnGnDvnYncfjhLp6ZP3JkzFzE60UfGjPTixujVv7GlPkrQ7nv3KVIeEiE043SvXgDwFORq9E9urI17oe8KOGRYSS0+PkqXIMw6ljgkJrHAhtZPiw/5QNNueg== Received: from [98.139.212.149] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2015 00:22:58 -0000 Received: from [98.139.212.248] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2015 00:22:58 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 11 Mar 2015 00:22:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 989994.42800.bm@omp1057.mail.bf1.yahoo.com X-YMail-OSG: 6VU.Cd0VM1lxcC_uwVVHgsxrhS1XY68pRIPCQ38JB8HIjxwuFDL..p5jqH7lbQ8 fw0imTlx8ccWlAXHsRe0TIgWwEzIVsjwPZ3K1HvVYBnl_25Ur1YXBhRAgaAEQUbPu_Qj8wXnxfqO sQTQHjDhdKEcZzwRxn3WBvQ0X21cyPjaxa4acFV9tlwrp9YmOOqOs2EKh013g62LLQVJAE7jwtn5 Eeew_pTvHZnrLJ53QGO_olihDekz_M6LmHE.K3nFZg6cyqTAN3IL3k_4Ff0YEW4t9fHQrGWqYRpD Xh2IE0FWheaFejswPgDN2paMwkuucsmBdJ.V_kFiCt4IddUp8h_YgC9xB4bPxcQ6iG0dSS3Pk6Wa DtXl51Lj9S40D7WTINutGvK5eicXnMsNaCkivb71BnqB2PpaQQvaT.aJwW8YgUBGD.RaHDnATfKH 43becJCGaLN505vrtJZ8oBvqgYobV5oDTAGQPY2UZt4eS6oXbW7NfiO9ItBDXUqBttw.v1w.Z1if h5F3ETNNLjSq6HJiZPqeb4TdDd1yD6sFZ8AVAVDG9yrH.OK.buA-- Received: by 76.13.26.108; Wed, 11 Mar 2015 00:22:57 +0000 Date: Wed, 11 Mar 2015 00:22:56 +0000 (UTC) From: Mark ZZZ Smith To: Philip Matthews , v6ops list Message-ID: <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:23:00 -0000 I'll also point out that I completely understand why it is occurred. It is easier for people to learn things based on things that are similar to what they know, and link-local only IPv6 links are conceptually quite similar to IPv4 unnumbered links. Of course there are also differences, and when something is different, we give it a different name to distinguish it (or a qualifier, however "link-local numbered, unnumbered links" is pretty clumsy (!)) ----- Original Message ----- From: Philip Matthews To: v6ops list Cc: Victor Kuarsingh ; Mark ZZZ Smith Sent: Wednesday, 11 March 2015, 1:52 Subject: Should we use "unnumbered" in IPv6? Just want to get some direct feedback from the WG on the use of the terms "unnumbered interface" and "unnumbered link" in IPv6. Mark Smith, in some comments on the Design Choices draft , has said that he prefers the terms "interface with only link-local address" or "link with only link-local addresses" instead. See the thread with title "I-D Action: draft-ietf-v6ops-design-choices-04.txt". What does the WG think? Should we use the "unnumbered" terms, or should we use just the "... with only link-local address" terms? Is it acceptable to mix the two sets of terms? Philip From nobody Tue Mar 10 17:50:29 2015 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 B10151A9140; Tue, 10 Mar 2015 17:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 bk4VhHmyByxu; Tue, 10 Mar 2015 17:50:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id F32301A9118; Tue, 10 Mar 2015 17:50:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CD51F180463; Tue, 10 Mar 2015 17:49:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150311004933.CD51F180463@rfc-editor.org> Date: Tue, 10 Mar 2015 17:49:33 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7445 on Analysis of Failure Cases in IPv6 Roaming Scenarios 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, 11 Mar 2015 00:50:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7445 Title: Analysis of Failure Cases in IPv6 Roaming Scenarios Author: G. Chen, H. Deng, D. Michaud, J. Korhonen, M. Boucadair Status: Informational Stream: IETF Date: March 2015 Mailbox: phdgang@gmail.com, denghui@chinamobile.com, dave.michaud@rci.rogers.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com Pages: 19 Characters: 44466 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-roaming-analysis-07.txt URL: https://www.rfc-editor.org/info/rfc7445 This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Mar 10 20:44:03 2015 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 D6D311A00F9 for ; Tue, 10 Mar 2015 20:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 ftMN1RVmZmUs for ; Tue, 10 Mar 2015 20:43:58 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::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 B033A1A00DC for ; Tue, 10 Mar 2015 20:43:58 -0700 (PDT) Received: by pdbnh10 with SMTP id nh10so7617120pdb.4 for ; Tue, 10 Mar 2015 20:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cxaW82/n/x2V3qA5dSEWRxbJV30geQo3S+oRNXIUf4k=; b=IhesajzWb8zTNKjLgiTNSRzK/p5CSCHdMU6Pm478TIursLn0KG4DnD0+Nlu3WZl6UE eAhr+N8kr1LMP93j8o8C4/F5hsNKzxkIHFtEyWMh7vx7HSsYkNdng2twJDTZl/dgMiId im1FrIW0jwOWi7uXTw0FlreEsBasTi7ezqz17XAX6hG9G3fKDXjYH6uQfEP56yJzNJOy ysJ2yXw0x5HhPt85pTXENfpa3IcgjIicevJfAhlLTfqYUeuLz48MGK+smeh8uCS+olvd iPbS6KgaxHOVNx4VDz2M7e5brTxP5z/ZVOwfDx4wVLjdh24Dwol00CFH20Eb/++V/7bH +HJA== X-Received: by 10.70.18.68 with SMTP id u4mr38978277pdd.38.1426045438328; Tue, 10 Mar 2015 20:43:58 -0700 (PDT) Received: from [10.1.9.163] ([103.23.18.15]) by mx.google.com with ESMTPSA id ji6sm3385336pac.30.2015.03.10.20.43.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 20:43:57 -0700 (PDT) Message-ID: <54FFB9F8.9000408@gmail.com> Date: Wed, 11 Mar 2015 16:43:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: IPv6 Operations References: <20150309053609.23108.98801.idtracker@ietfa.amsl.com> In-Reply-To: <20150309053609.23108.98801.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-in-real-world-02.txt 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, 11 Mar 2015 03:44:03 -0000 Hi, I just noticed that the draft does not state the contents of the DO8 and HBH8 headers used. Are they just PadN? Anyway, to fully understand the experiment, it should be stated. Regards Brian From nobody Wed Mar 11 00:43:10 2015 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 B550C1AC3F8 for ; Wed, 11 Mar 2015 00:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IVvIx-LtD6UD for ; Wed, 11 Mar 2015 00:43:03 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id C33B31AC3B2 for ; Wed, 11 Mar 2015 00:43:02 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 6F81413F4333; Wed, 11 Mar 2015 01:43:02 -0600 (MDT) X-Spam-ASN: Received: from [192.168.0.5] (c-24-143-80-128.customer.broadstripe.net [24.143.80.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 64B9113F42DF for ; Wed, 11 Mar 2015 01:43:01 -0600 (MDT) Message-ID: <54FFF1FE.7070900@iridiumlinux.org> Date: Wed, 11 Mar 2015 00:42:54 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060702030700010608080809" Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 11 Mar 2015 07:43:08 -0000 This is a cryptographically signed message in MIME format. --------------ms060702030700010608080809 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable There is a bunch of stuff in IPv6 that is different from IPv4 operations. It is a different protocol, after all. Lots of paradigms are different, most especially that of addressing. Even though I gather there is substantial support for calling those links "unnumbered" on the basis of familiarity, Mark is completely right in saying that this is the kind of thing that causes confusion and oversight later on, and would create something unintuitive to future network engineers in a world where IPv6 is dominant. The difference whereby no IPv4 address is borrowed (and instead a link-local address is used) is sufficient to make this a very different configuration. I put forth the term "locally-numbered" as a succinct and apropos alternative. --Falcon Darkstar Momot --Shadytel On 10/03/2015 17:22, Mark ZZZ Smith wrote: > I'll also point out that I completely understand why it is occurred. It= is easier for people to learn things based on things that are similar to= what they know, and link-local only IPv6 links are conceptually quite si= milar to IPv4 unnumbered links.=20 > > Of course there are also differences, and when something is different, = we give it a different name to distinguish it (or a qualifier, however "l= ink-local numbered, unnumbered links" is pretty clumsy (!)) > > > > > > > > > ----- Original Message ----- > From: Philip Matthews > To: v6ops list > Cc: Victor Kuarsingh ; Mark ZZZ Smith > Sent: Wednesday, 11 March 2015, 1:52 > Subject: Should we use "unnumbered" in IPv6? > > Just want to get some direct feedback from the WG on the use of the ter= ms "unnumbered interface" and "unnumbered link" in IPv6. > > Mark Smith, in some comments on the Design Choices draft , has said tha= t he prefers the terms "interface with only link-local address" or "link = with only link-local addresses" instead. See the thread with title "I-D= Action: draft-ietf-v6ops-design-choices-04.txt". > > What does the WG think? Should we use the "unnumbered" terms, or shoul= d we use just the "... with only link-local address" terms? Is it accept= able to mix the two sets of terms? > > Philip > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------ms060702030700010608080809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUjCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFMDCCBBigAwIBAgIRAN3sgt3ll/yQeOZPRId2L3IwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw NjEwMDAwMDAwWhcNMTUwNjEwMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhdmYWxjb25AaXJp ZGl1bWxpbnV4Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANFEuUdfP+wv X950Km0FMhQMuSGDWruO3Wy6Vxf4kgEcGqDl73zZzQ7vohYUEtUc3kyluw9qwk42FGqHSs5Y pW5CDWr85Ov167Z3DwjCHJ2cA9qtTCD0GwjW9MkYRDQpWs87pq9Ur51G0/mkiG4y4Xkif4Dl 28R2YM3QIvs1XL6bobjmcyt30eZrArkgNuBBmcAybuo0pqFlBaKud8HcgrOR91keU7mAqJIz MVnV+jBeFbX5Rs7RXAtJBM1n3u48w8v3V/2E034DBa0vjhyafpPDKv9LQ4LyJysBZ9uIArCk 7HJqzGO2kT/6cXFbwCphHY5C3IMPx0FdMboi2isoDsUCAwEAAaOCAecwggHjMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTmkI6vq81eszHm8NLf/xOfFPDl ozAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1Ud HwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEF BQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMA0GCSqGSIb3DQEB BQUAA4IBAQABMQFyXEQDcedRrbgAbhuMFztPeTMz+XuM/tybABL8aCzxyB3b7tiJ1kY5jMA1 2O7bydcen9XGfXI2RZM2btU2zoOSYqdh9SoLX1pSIL2P48b7PV7SYK/iruplh8S/s9+/ziav 2f1q2LT3aN4brT+QBDHLz0+/g6sYNg6nnNbHBGT3uTX4mSS9iP5IohKmKmHGCKFXXiWmcRCU 1CynAd9fmQroFXRpJYtbRbR1nEpUfJ2NGffKO7qLkA+X2H9ORvBQvuBa20P5Q4sjehTX87d+ zdbtA4lxOsA5/MSoeZ+LKlx1hXmY+i/qmjlZO42FpMBKGQYW9ioJ8vSiiSHjarAuMYIEHDCC BBgCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDd 7ILd5Zf8kHjmT0SHdi9yMAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxMTA3NDI1NFowIwYJKoZIhvcNAQkEMRYEFIa5CmYY ffitDYOszzTq9pAPwOPRMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAN3sgt3ll/yQeOZPRId2L3IwgbwGCyqGSIb3 DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcG A1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEA3eyC3eWX/JB45k9Eh3YvcjANBgkqhkiG9w0BAQEFAASCAQBElbejJFdIGmOgkaROKv4k vnlc7awv4FzH0j/Fkk2v6dz7zB3hvmptZvRLDBSGHtXVvLrcZWRYdlCvitqInNVJ1wfcMi3/ 5vcbByEHvCBBE262wBwHrTeZClqsQ42ePtC1Lk5Wh8WQdA6NXDrolsYGkgAzf4vnA70k+OC4 FsQA8NriGmZRyo19kpkabXUOSBvp0f2oCzuDfmWc+ljAENwL1gHA7OEWCNEKfKtto343GyhH NgI8nS2xh2ub8pXYZq3TVJGTBOlrkjk0qMwygbsTS6l+YDjIZ/eSrm+a0eblu47n0PZNWmv2 wyz3DTL1V35oFjPtg4+tn/5SkLi1n4BQAAAAAAAA --------------ms060702030700010608080809-- From nobody Wed Mar 11 00:51:54 2015 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 13AD71AC3FB for ; Wed, 11 Mar 2015 00:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7NU3BN0m12nK for ; Wed, 11 Mar 2015 00:51:52 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::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 A60A21AC3F9 for ; Wed, 11 Mar 2015 00:51:52 -0700 (PDT) Received: by qcwb13 with SMTP id b13so8205142qcw.9 for ; Wed, 11 Mar 2015 00:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7pPQPQb17KovDAS3yICKwNgRF5WyiiOO3Ovu1GCz7OA=; b=Ng7ssHppb1sXW/2zKVBRzEpMjcnaKd3ypi1mYZSBKMSaWTuCkr0Q3k3ahhiiFkLTEr nFXEaZtOpjGJUUItFsC76gV3RZhJSy908PkfvGSY822l8QKs0dIlRpq46E1w7EVd8UR5 jzqEJfC7kQce361sfz+sUW2mHYECRB+4mGpgjntOFthoDexHJ7emouiOvEYbFBhyFUKC fvnatvS99sJfl4ZvTLciPas3FGqrfNGAHYqVkk5uWVdhbVAg2yb4XwcOJUP9/7F7dM9g YNIo2M68jVWqoFoOiemsZaK3fGOZTvRG+sTmiZuNZ0oz1dYcCQpJBwxvn4KgrjfH8HHR nz5Q== 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-type; bh=7pPQPQb17KovDAS3yICKwNgRF5WyiiOO3Ovu1GCz7OA=; b=X0YtpcrHyTW0N7nwUV8hdnA/FUTvD5l0PvMsyw2Dq5QFmtjdplwdB8/hJMWV1+4eA+ Cb7A/XFAPR6bQJU9NJWAlVGnMt+cMU1bG+LrpAWoqz27+CUINmXD60zH7+QAQ5eFbpsZ vHVat0Mj91Os/dtAEdzCIMnqK7NqjLtI3wbNf7t/HLupd6jUECcVD9wI4Fi6bJa6HlCe l6kBYJB8xF8eI2n53sBjWm5Wreed/HCesUCr90/BWTbEzVzVEloXcjk/pclMiVDiOq1s 5/VICg5GKwpqoh1vCOb+1j893gGu0hn7SNNVTMp6nM1AI4Mek5jxuMIxlQ4tz1wSK6qH aLwQ== X-Gm-Message-State: ALoCoQlDBkXGjX0i/z+h2JNfiF9hAGC6wZzH5qLS7Zz+kLtWAlan1PN7VE/ymMaNY87nzHFFLRcq X-Received: by 10.55.19.74 with SMTP id d71mr71151038qkh.92.1426060311974; Wed, 11 Mar 2015 00:51:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.72 with HTTP; Wed, 11 Mar 2015 00:51:31 -0700 (PDT) In-Reply-To: <54FFF1FE.7070900@iridiumlinux.org> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> From: Erik Kline Date: Wed, 11 Mar 2015 16:51:31 +0900 Message-ID: To: Falcon Darkstar Momot Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 11 Mar 2015 07:51:54 -0000 > I put forth the term "locally-numbered" as a succinct and apropos > alternative. I was thinking about that as well, but dropped it on the assumption that if the context were mistaken in conversation to be IPv4 (or we wanted a common term for both) that locally-numbered might be interpreted as "has RFC1918 addresses". (Sorry, I really don't want to take us down the road of the "hextet" discussion. :-) From nobody Wed Mar 11 00:59:41 2015 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 A3F661AC3B2 for ; Wed, 11 Mar 2015 00:59:39 -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 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 ZVPiRtIK4VnC for ; Wed, 11 Mar 2015 00:59:38 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA1F1A8AF9 for ; Wed, 11 Mar 2015 00:59:38 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2B7t1ca024617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 00:55:01 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2B7t1ca024617 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426060501; bh=nUff5kuRMUh2AOD2SJdgrxd8Iqs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=McJKbOjGHbbsIknUB/02aHQK9i/zIayazjtSZi8orhRE7RxZBMLUsV+ldSKROrWc+ NG/q7jW8puZ2xFz1271flQGzAyRUSAX1nmyj+BfkQZV4sajCl12urwIhxp6o3dErrH P1MP8c4Btkq6h9zB0P354H6cImquKet21gaelmCM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Owen DeLong In-Reply-To: <54FFF1FE.7070900@iridiumlinux.org> Date: Wed, 11 Mar 2015 00:55:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> To: Falcon Darkstar Momot X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 11 Mar 2015 00:55:01 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 11 Mar 2015 07:59:39 -0000 I see no benefit and many drawbacks to link-local numbered and = unnumbered interfaces. Among them: Link Local numbered interfaces are unlikely to be unambiguous when they = appear in traceroutes. They are virtually guaranteed not to makes sense or provide useful = information outside of your administrative domain. Unnumbered interfaces provide information only on which router received = a packet, but not which interface. This can often be confusing, = misleading, or outright useless when troubleshooting. In IPv4, address scarcity might, in some circumstances create sufficient = incentive to use such things. In IPv6, there is no address scarcity, so I can=92t see any upside = whatsoever to either of these constructs. Owen > On Mar 11, 2015, at 00:42 , Falcon Darkstar Momot = wrote: >=20 > There is a bunch of stuff in IPv6 that is different from IPv4 > operations. It is a different protocol, after all. Lots of paradigms > are different, most especially that of addressing. Even though I = gather > there is substantial support for calling those links "unnumbered" on = the > basis of familiarity, Mark is completely right in saying that this is > the kind of thing that causes confusion and oversight later on, and > would create something unintuitive to future network engineers in a > world where IPv6 is dominant. The difference whereby no IPv4 address = is > borrowed (and instead a link-local address is used) is sufficient to > make this a very different configuration. >=20 > I put forth the term "locally-numbered" as a succinct and apropos > alternative. >=20 > --Falcon Darkstar Momot > --Shadytel >=20 > On 10/03/2015 17:22, Mark ZZZ Smith wrote: >> I'll also point out that I completely understand why it is occurred. = It is easier for people to learn things based on things that are similar = to what they know, and link-local only IPv6 links are conceptually quite = similar to IPv4 unnumbered links.=20 >>=20 >> Of course there are also differences, and when something is = different, we give it a different name to distinguish it (or a = qualifier, however "link-local numbered, unnumbered links" is pretty = clumsy (!)) >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> ----- Original Message ----- >> From: Philip Matthews >> To: v6ops list >> Cc: Victor Kuarsingh ; Mark ZZZ Smith = >> Sent: Wednesday, 11 March 2015, 1:52 >> Subject: Should we use "unnumbered" in IPv6? >>=20 >> Just want to get some direct feedback from the WG on the use of the = terms "unnumbered interface" and "unnumbered link" in IPv6. >>=20 >> Mark Smith, in some comments on the Design Choices draft , has said = that he prefers the terms "interface with only link-local address" or = "link with only link-local addresses" instead. See the thread with = title "I-D Action: draft-ietf-v6ops-design-choices-04.txt". >>=20 >> What does the WG think? Should we use the "unnumbered" terms, or = should we use just the "... with only link-local address" terms? Is it = acceptable to mix the two sets of terms? >>=20 >> Philip >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Mar 11 01:48:12 2015 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 057D11A86F7 for ; Wed, 11 Mar 2015 01:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Hi2kuswydDEE for ; Wed, 11 Mar 2015 01:48:09 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id EBC891AC41F for ; Wed, 11 Mar 2015 01:48:03 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 315FA13F4333; Wed, 11 Mar 2015 02:47:33 -0600 (MDT) X-Spam-ASN: Received: from [192.168.0.5] (c-24-143-80-128.customer.broadstripe.net [24.143.80.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 8657813F42DF for ; Wed, 11 Mar 2015 02:47:31 -0600 (MDT) Message-ID: <5500011C.10208@iridiumlinux.org> Date: Wed, 11 Mar 2015 01:47:24 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: "v6ops@ietf.org" References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060101050702000207010201" Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 11 Mar 2015 08:48:10 -0000 This is a cryptographically signed message in MIME format. --------------ms060101050702000207010201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/03/2015 00:51, Erik Kline wrote: >> I put forth the term "locally-numbered" as a succinct and apropos >> alternative. > I was thinking about that as well, but dropped it on the assumption > that if the context were mistaken in conversation to be IPv4 (or we > wanted a common term for both) that locally-numbered might be > interpreted as "has RFC1918 addresses". > > (Sorry, I really don't want to take us down the road of the "hextet" > discussion. :-) Potentially, but I believe the common terminology there is "privately numbered" or just "private" (which is its own horror with respect to the security confusion it creates, especially in conjunction with the nat-is-a-firewall mentality, but I digress). Incidentally, it is common to use RFC1918 addresses in IPv4 routers, leading to the abomination of RFC1918 addresses returned in traceroutes. You just can't win with private-use space. --Falcon Darkstar Momot --Shadytel --------------ms060101050702000207010201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUjCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFMDCCBBigAwIBAgIRAN3sgt3ll/yQeOZPRId2L3IwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw NjEwMDAwMDAwWhcNMTUwNjEwMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhdmYWxjb25AaXJp ZGl1bWxpbnV4Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANFEuUdfP+wv X950Km0FMhQMuSGDWruO3Wy6Vxf4kgEcGqDl73zZzQ7vohYUEtUc3kyluw9qwk42FGqHSs5Y pW5CDWr85Ov167Z3DwjCHJ2cA9qtTCD0GwjW9MkYRDQpWs87pq9Ur51G0/mkiG4y4Xkif4Dl 28R2YM3QIvs1XL6bobjmcyt30eZrArkgNuBBmcAybuo0pqFlBaKud8HcgrOR91keU7mAqJIz MVnV+jBeFbX5Rs7RXAtJBM1n3u48w8v3V/2E034DBa0vjhyafpPDKv9LQ4LyJysBZ9uIArCk 7HJqzGO2kT/6cXFbwCphHY5C3IMPx0FdMboi2isoDsUCAwEAAaOCAecwggHjMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTmkI6vq81eszHm8NLf/xOfFPDl ozAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1Ud HwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEF BQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMA0GCSqGSIb3DQEB BQUAA4IBAQABMQFyXEQDcedRrbgAbhuMFztPeTMz+XuM/tybABL8aCzxyB3b7tiJ1kY5jMA1 2O7bydcen9XGfXI2RZM2btU2zoOSYqdh9SoLX1pSIL2P48b7PV7SYK/iruplh8S/s9+/ziav 2f1q2LT3aN4brT+QBDHLz0+/g6sYNg6nnNbHBGT3uTX4mSS9iP5IohKmKmHGCKFXXiWmcRCU 1CynAd9fmQroFXRpJYtbRbR1nEpUfJ2NGffKO7qLkA+X2H9ORvBQvuBa20P5Q4sjehTX87d+ zdbtA4lxOsA5/MSoeZ+LKlx1hXmY+i/qmjlZO42FpMBKGQYW9ioJ8vSiiSHjarAuMYIEHDCC BBgCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDd 7ILd5Zf8kHjmT0SHdi9yMAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxMTA4NDcyNFowIwYJKoZIhvcNAQkEMRYEFNytHQrn lscOUyaILtp55zVM7DArMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAN3sgt3ll/yQeOZPRId2L3IwgbwGCyqGSIb3 DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcG A1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEA3eyC3eWX/JB45k9Eh3YvcjANBgkqhkiG9w0BAQEFAASCAQAHHHfNWWsQu58+yqBlIEdI z1ucpXx0rY4X1id12iPcQ5ChBhkFFRwYMd+L1EyJNglanEVxkTaoNrsoxHKcfyW5jI1XLLpk CnwM+9XoaxRDOB+VOyYEpbjnyUFQwNxfdMgmdqf0rkD/V1X2FD0jbtoxArWmYdV7EI41PMLn 4wQfXZ6sshh8wd9okqIHMK+wqdpOy7wO2X0dttB3wU7GobJVF66WAZKKDZOGyVfSwn9llg4F btr0KVqycWAgIFoWkUYfXnds8U/DOmFM3q1wBpoH1ORkYINaXO1sjGOE67Jvkq+u0sCxhIcg bWCR273K+nudCSir6Q404WTUKcWYS5uyAAAAAAAA --------------ms060101050702000207010201-- From nobody Wed Mar 11 03:14:24 2015 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 5DEFE1ACD2B for ; Wed, 11 Mar 2015 03:14:23 -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 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 4KvAbl5E1DYF for ; Wed, 11 Mar 2015 03:14:21 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 95F391ACD2A for ; Wed, 11 Mar 2015 03:14:20 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4ADE46010D for ; Wed, 11 Mar 2015 11:14:19 +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 0FB0C60288 for ; Wed, 11 Mar 2015 11:14:19 +0100 (CET) Received: (qmail 77183 invoked by uid 1007); 11 Mar 2015 11:14:19 +0100 Date: Wed, 11 Mar 2015 11:14:19 +0100 From: Gert Doering To: Erik Kline Message-ID: <20150311101418.GQ54385@Space.Net> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 11 Mar 2015 10:14:23 -0000 Hi, On Wed, Mar 11, 2015 at 04:51:31PM +0900, Erik Kline wrote: > (Sorry, I really don't want to take us down the road of the "hextet" > discussion. :-) We're already on the way... expecting a long linguistic treaty next. 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 Wed Mar 11 03:18:13 2015 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 829881AD364 for ; Wed, 11 Mar 2015 03:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lcYa4k7eNZxQ for ; Wed, 11 Mar 2015 03:18:01 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7C71ACD69 for ; Wed, 11 Mar 2015 03:17:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3AA85A3; Wed, 11 Mar 2015 11:17:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1426069046; bh=/Dy0RurXCPUvHypDdQuf5cw6kBz/Y6V2zFWOAqtdad8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Rw9RMnKnPZWgweJ0aW0K3IrubofQbmIZk+YHurNAApccapiNPsVWTFZe9wPXXiGUC CFop1AuJefJbEOld3zMIXy2aBmanKQf9jQFg2G3/Wz7TDBr4Mbw4gKjmIeGaUiqmrJ m2tTyJLPQDuHPMh9qlkZ/sujPep3vb73ttXd4HrA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2E622A2; Wed, 11 Mar 2015 11:17:26 +0100 (CET) Date: Wed, 11 Mar 2015 11:17:26 +0100 (CET) From: Mikael Abrahamsson To: Philip Matthews In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> Message-ID: References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 11 Mar 2015 10:18:04 -0000 On Tue, 10 Mar 2015, Philip Matthews wrote: > Just want to get some direct feedback from the WG on the use of the terms "unnumbered interface" and "unnumbered link" in IPv6. > > Mark Smith, in some comments on the Design Choices draft , has said that he prefers the terms "interface with only link-local address" or "link with only link-local addresses" instead. See the thread with title "I-D Action: draft-ietf-v6ops-design-choices-04.txt". > > What does the WG think? Should we use the "unnumbered" terms, or should we use just the "... with only link-local address" terms? Is it acceptable to mix the two sets of terms? I do not like "unnumbered" at all. Cisco for instance has "interface unnumbered loopback0". This doesn't mean the interface doesn't have a number, it means it'll use the loopback0 IPv4 address. So I would much more prefer to say "link local only" interface or something to that effect. That would avoid confusion. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Mar 11 04:03:27 2015 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 7401D1A90A6 for ; Wed, 11 Mar 2015 04:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 xdxOEDLz01TQ for ; Wed, 11 Mar 2015 04:03:23 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [46.182.8.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 7A62C1A874A for ; Wed, 11 Mar 2015 04:03:23 -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.1/8.14.9) with ESMTPSA id t2BB38Iw031319 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2015 11:03:09 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <550020EC.1080907@foobar.org> Date: Wed, 11 Mar 2015 11:03:08 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gert Doering References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> <20150311101418.GQ54385@Space.Net> In-Reply-To: <20150311101418.GQ54385@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 11 Mar 2015 11:03:25 -0000 On 11/03/2015 10:14, Gert Doering wrote: > On Wed, Mar 11, 2015 at 04:51:31PM +0900, Erik Kline wrote: >> (Sorry, I really don't want to take us down the road of the "hextet" >> discussion. :-) > > We're already on the way... expecting a long linguistic treaty next. As we've only had 23 emails so far on this topic, I'm going to chip in my 2 eurocents: namely, whatever is chosen, I politely suggest that we put some html color tags in the draft to let posterity know how important this topic is, and how seriously it was considered by the WG. Also, the tags should be red (#ff0000) to attract the appropriate level of attention. We all understand it would be a mistake to let this issue be quietly resolved without serious discussion, so it's only reasonable to make future RFC readers aware of our heroic efforts to do what's best for them. Nick From nobody Wed Mar 11 12:44:12 2015 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 10F921A1B8B for ; Wed, 11 Mar 2015 12:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 vlLbRKWiFMTL for ; Wed, 11 Mar 2015 12:44:09 -0700 (PDT) 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 B0A3F1A86E9 for ; Wed, 11 Mar 2015 12:44:05 -0700 (PDT) Received: by pabli10 with SMTP id li10so13944826pab.2 for ; Wed, 11 Mar 2015 12:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lD5KSJ391bRWF+0U5D2mfOYlrJOqHOa65vzLgewPsEg=; b=ffPwSbemIzMA9Iw2JBV8zEtOpPVGMk9LWfnPDLS4ZZdBF1DtFALIvNHspxzsSWeibF 9HIOkgIOsQEUdi19VEw1sgjftmZ7XDCqJhFa7fhctuj0a4eYVHEUp4mMiZX0waUNQUGl gCVJ5+4EJdQsx4xRFJbtqCthFgsX4iFpE32EGWSNOPd4JZINuQFdjE2e4nsZGhBkwRPI wVWL3JFhxD96saJtlYxv/r4G8w/wPG4N9GV40/2g+0yEC5Ba+zAcRlXxRoeSZt8CfmoB lNnT//J7u/NbHejXNuiSyEf+zVheO6JP+OVaDrI95lzsIHws3D7biSjLJHygc7dhD29s CQLw== X-Received: by 10.66.221.135 with SMTP id qe7mr80046509pac.97.1426103045307; Wed, 11 Mar 2015 12:44:05 -0700 (PDT) Received: from [10.1.9.163] ([103.23.18.15]) by mx.google.com with ESMTPSA id a4sm7308430pdf.57.2015.03.11.12.44.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 12:44:03 -0700 (PDT) Message-ID: <55009B03.3040500@gmail.com> Date: Thu, 12 Mar 2015 08:44:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Owen DeLong , Falcon Darkstar Momot References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> In-Reply-To: <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 11 Mar 2015 19:44:11 -0000 Owen, On 11/03/2015 20:55, Owen DeLong wrote: > I see no benefit and many drawbacks to link-local numbered and unnumber= ed interfaces. >=20 > Among them: >=20 > Link Local numbered interfaces are unlikely to be unambiguous when they= appear in traceroutes. > They are virtually guaranteed not to makes sense or provide useful info= rmation outside of your administrative domain. >=20 > Unnumbered interfaces provide information only on which router received= a packet, but not which interface. This can often be confusing, misleadi= ng, or outright useless when troubleshooting. >=20 > In IPv4, address scarcity might, in some circumstances create sufficien= t incentive to use such things. >=20 > In IPv6, there is no address scarcity, so I can=E2=80=99t see any upsid= e whatsoever to either of these constructs. Link-local addresses are a vital part of bootstrapping an IPv6 node, especially in an unmanaged and unconfigured network; they will figure largely in bootstrapping autonomic networks in particular. They are viewed by some as also having an important security property: they simply don't work off-link. draft-behringer-anima-autonomic-control-= plane takes this view, for example. Unnumbered, in the literal sense, doesn't exist in IPv6, which is why we are having this terminological discussion in the first place. Brian From nobody Wed Mar 11 13:49:28 2015 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 87A281A871B for ; Wed, 11 Mar 2015 13:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 f0jGveJ_3br2 for ; Wed, 11 Mar 2015 13:49:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E9A1A870E for ; Wed, 11 Mar 2015 13:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1073; q=dns/txt; s=iport; t=1426106966; x=1427316566; h=from:to:subject:date:message-id:mime-version; bh=uUa8UtCiZrQmuylYs17AaARppCZG4ACjcrdaK8/iuzY=; b=L0C0jdbAChQHW/6YaJRx9iAJqgZPSdC2Zy11XZU7D4KCg+qKFHFv+hUA ++WKQXUNnrfC6kD8Iz+Uu9nkk59syJvfqVSsDu9m1Ry7dOatYmR7dnd4I SV/jOuquYoAwchRGh709Yh0KTaw29enfm0ehbNzaCS4p3EB6Y/9cWU4Ua g=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D8DwAbqQBV/5xdJa1cgwZSGkEDvWqFf4VtAYFATAEBAQEBAX2EFoELAYEAJwQcBYghDZ5NqnwBH5MmgRYFkByBZoEuhkmTeSODboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,383,1422921600"; d="asc'?scan'208";a="402828760" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 11 Mar 2015 20:49:25 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2BKnOiD021996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Mar 2015 20:49:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 11 Mar 2015 15:49:24 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: Agenda for IETF 92 Thread-Index: AQHQXDzbsJfKw7WS7E6jjrr78mbRmg== Date: Wed, 11 Mar 2015 20:49:24 +0000 Message-ID: <4970669C-15B4-440D-929C-80BB7B3B1037@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.134.133] Content-Type: multipart/signed; boundary="Apple-Mail=_3408D349-BF22-4035-A082-C47D504933E2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Agenda for IETF 92 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, 11 Mar 2015 20:49:26 -0000 --Apple-Mail=_3408D349-BF22-4035-A082-C47D504933E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have posted a proposed agenda at = http://www.ietf.org/proceedings/92/agenda/agenda-92-v6ops. --Apple-Mail=_3408D349-BF22-4035-A082-C47D504933E2 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 iQEVAwUBVQCpl59ieig10VPpAQLemgf+JtovP0TccyVwu8nkZ0UmfHKPQAuefEtq tc5UZHWy0hEtyRhg9/buGmsyob2yW6kBQ8Mw9S4uBtJYKqAYGfM9NkFTZNffSXB1 qYxwc+tSzJvSMVCClLo+3BaIMMDFKPGEto5IGOywF3ONQXS/DVd2XgxsQnkZwkyu wUvz7Ov3JSlzoHdTon6LcN3RnnGQ5aE3iMQWGuOnQ/og5mTXNdoK7M8NKkG5/qet OJeEyggo2T/QLhgyB4A5vaO13tKK0Y+04iPrseOuV76mBQYEV25qELDLHEstg86Y HOBxpG8TeslSc+1iEsv76e8ZJkfHQJXPfasBi4YKSeVjnHvAN1DrpQ== =sall -----END PGP SIGNATURE----- --Apple-Mail=_3408D349-BF22-4035-A082-C47D504933E2-- From nobody Wed Mar 11 19:14:56 2015 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 ACBEC1A89B1 for ; Wed, 11 Mar 2015 19:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 01uK2N-XL7l5 for ; Wed, 11 Mar 2015 19:14:53 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id F021A1A89AB for ; Wed, 11 Mar 2015 19:14:52 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2C2E1BZ013317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 19:14:02 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2C2E1BZ013317 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426126442; bh=taBtPZYGMCupNY/CiMU3Iopk0zQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=floOKtQhFatSstY1gfEQCaOPj0/4LxychYBH7ageYcZ7qUPAc+gu60icYyzFYqHCV UXfGheCUgGNKKiwJwOEUWUBdErq8/mSiQQa566ADj3zKGtRhKfdF4F2m4d5kpv3rMI Vh2CYVn47swSQfbK6ab1jab1++m/oXVElO1G1Tnk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Owen DeLong In-Reply-To: <55009B03.3040500@gmail.com> Date: Wed, 11 Mar 2015 19:14:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> <55009B03.3040500@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 11 Mar 2015 19:14:02 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 02:14:54 -0000 > On Mar 11, 2015, at 12:44 , Brian E Carpenter = wrote: >=20 > Owen, >=20 > On 11/03/2015 20:55, Owen DeLong wrote: >> I see no benefit and many drawbacks to link-local numbered and = unnumbered interfaces. >>=20 >> Among them: >>=20 >> Link Local numbered interfaces are unlikely to be unambiguous when = they appear in traceroutes. >> They are virtually guaranteed not to makes sense or provide useful = information outside of your administrative domain. >>=20 >> Unnumbered interfaces provide information only on which router = received a packet, but not which interface. This can often be confusing, = misleading, or outright useless when troubleshooting. >>=20 >> In IPv4, address scarcity might, in some circumstances create = sufficient incentive to use such things. >>=20 >> In IPv6, there is no address scarcity, so I can=E2=80=99t see any = upside whatsoever to either of these constructs. >=20 > Link-local addresses are a vital part of bootstrapping an IPv6 node, > especially in an unmanaged and unconfigured network; they will figure > largely in bootstrapping autonomic networks in particular. I=E2=80=99m not saying interfaces shouldn=E2=80=99t have a link local = address. (jeez.) I=E2=80=99m saying that not puting a real address on a link that shows = up in traceroutes is a bad idea. > They are viewed by some as also having an important security property: > they simply don't work off-link. = draft-behringer-anima-autonomic-control-plane > takes this view, for example. Blah blah blah. > Unnumbered, in the literal sense, doesn't exist in IPv6, which is why > we are having this terminological discussion in the first place. It doesn=E2=80=99t exist in IPv4 in the literal sense, either. As others = have pointed out, what is called an unnumbered interface in IPv4 is an interface that shares numbering with = a loopback or other interface which is an utter hack that yielded more confusion than useful = results in the early efforts to reduce IPv4 address consumption. So, if you have something you don=E2=80=99t want to communicate off link = AT ALL, then by all means, go ahead and use link-local only numbering to your hearts content. Otherwise, please put a real GUA on the interface to reduce the number = of problems you inflict on others when they have to troubleshoot something that = involves/transits/originates from/etc. your network. Owen From nobody Thu Mar 12 05:31:09 2015 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 52BFC1A0013 for ; Thu, 12 Mar 2015 05:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 cIqqUskagx7v for ; Thu, 12 Mar 2015 05:31:06 -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 EA6781A0086 for ; Thu, 12 Mar 2015 05:31:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2CCV3f8024289 for ; Thu, 12 Mar 2015 13:31:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7A43F204F56 for ; Thu, 12 Mar 2015 13:31:27 +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 73CE22010E9 for ; Thu, 12 Mar 2015 13:31:27 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2CCV2HS016637 for ; Thu, 12 Mar 2015 13:31:03 +0100 Message-ID: <55018706.5040009@gmail.com> Date: Thu, 12 Mar 2015 13:31:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> In-Reply-To: <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 12:31:08 -0000 Le 12/03/2015 03:14, Owen DeLong a écrit : > >> On Mar 11, 2015, at 12:44 , Brian E Carpenter >> wrote: >> >> Owen, >> >> On 11/03/2015 20:55, Owen DeLong wrote: >>> I see no benefit and many drawbacks to link-local numbered and >>> unnumbered interfaces. >>> >>> Among them: >>> >>> Link Local numbered interfaces are unlikely to be unambiguous >>> when they appear in traceroutes. They are virtually guaranteed >>> not to makes sense or provide useful information outside of your >>> administrative domain. >>> >>> Unnumbered interfaces provide information only on which router >>> received a packet, but not which interface. This can often be >>> confusing, misleading, or outright useless when troubleshooting. >>> >>> In IPv4, address scarcity might, in some circumstances create >>> sufficient incentive to use such things. >>> >>> In IPv6, there is no address scarcity, so I can’t see any upside >>> whatsoever to either of these constructs. >> >> Link-local addresses are a vital part of bootstrapping an IPv6 >> node, especially in an unmanaged and unconfigured network; they >> will figure largely in bootstrapping autonomic networks in >> particular. > > I’m not saying interfaces shouldn’t have a link local address. > (jeez.) > > I’m saying that not puting a real address on a link that shows up in > traceroutes is a bad idea. Yes and no. YEs, we want traceroute to report an address of a hop, rather than a three-star string "* * *". But traceroute should be able to report link-local addresses, and ULAs, as well. If it doesnt then it's a problem of that traceroute program. If an enduser needs rather globally-scoped and unique (rathern than LL and ULA) addresses in traceroute outputs then one should ask her why? Be them globally-scoped and unique they dont tell anything useful to a human user of traceroute. They surely dont tell _where_ these addresses are (like in 'what country'). An address present in a traceroute output tells many things _if_ that end user has an mental association of the address set out-of-band (like "all addresses starting 2a02 belong to the operator I trust"). But these out-of-band associations have no requirement whatsoever on the scope of the address, or its uniqueness across Internet, or prefix-middle-suffix position of the trusted incantation. One could very well have fe80:X:1 displayed by traceroute, and know out-of-band that when X is in the address then the operator is trusted. (e.g. X==face:b00c). Besides, traceroute output is hugely more meaningful when it does not display addresses but FQDNs. These FQDNs have nothing to do with address scope either. Alex > >> They are viewed by some as also having an important security >> property: they simply don't work off-link. >> draft-behringer-anima-autonomic-control-plane takes this view, for >> example. > > Blah blah blah. > >> Unnumbered, in the literal sense, doesn't exist in IPv6, which is >> why we are having this terminological discussion in the first >> place. > > It doesn’t exist in IPv4 in the literal sense, either. As others > have pointed out, what is called an unnumbered interface in IPv4 is > an interface that shares numbering with a loopback or other > interface which is an utter hack that yielded more confusion than > useful results in the early efforts to reduce IPv4 address > consumption. > > So, if you have something you don’t want to communicate off link AT > ALL, then by all means, go ahead and use link-local only numbering > to your hearts content. > > Otherwise, please put a real GUA on the interface to reduce the > number of problems you inflict on others when they have to > troubleshoot something that involves/transits/originates from/etc. > your network. > > Owen > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 12 05:39:32 2015 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 2C7DF1A0099 for ; Thu, 12 Mar 2015 05:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 g2-DMlAOB-YO for ; Thu, 12 Mar 2015 05:39:29 -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 52DCD1A0013 for ; Thu, 12 Mar 2015 05:39:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2CCdRlb027046 for ; Thu, 12 Mar 2015 13:39:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BBB1A2053C3 for ; Thu, 12 Mar 2015 13:39:51 +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 B3911205259 for ; Thu, 12 Mar 2015 13:39:51 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2CCdR68009738 for ; Thu, 12 Mar 2015 13:39:27 +0100 Message-ID: <550188FF.2070008@gmail.com> Date: Thu, 12 Mar 2015 13:39:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <54FF67E6.6070202@bogus.com> In-Reply-To: <54FF67E6.6070202@bogus.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 12:39:31 -0000 Le 10/03/2015 22:53, joel jaeggli a écrit : > given that we have the link local only draft floating around it seems > like we have discussed this some in the v6 context. > > there are certain things you need or should use a globally signficant ip > for (responding to traceroute for example). Is there a traceroute program that works with ll addresses? Alex and some thing link local is > more than sufficient for (forming an adjacency) > > On 3/10/15 2:15 PM, Eric Vyncke (evyncke) wrote: >> Philip >> >> In the legacy world of IPv4, unnumbered actually means using a global IPv4 >> address 'stolen' from another interface. >> >> In the current world of IPv6, every interface has at least a link-local >> address which can be used for IGP and other purposes (see RFC 7404) which >> is NOT equivalent (IMHO) to 'unnumbered interface' >> >> So, I am afraid that you should use another working (albeit cumbersome) >> >> -éric >> >> On 10/03/15 15:52, "Philip Matthews" wrote: >> >>> Just want to get some direct feedback from the WG on the use of the terms >>> "unnumbered interface" and "unnumbered link" in IPv6. >>> >>> Mark Smith, in some comments on the Design Choices draft , has said that >>> he prefers the terms "interface with only link-local address" or "link >>> with only link-local addresses" instead. See the thread with title "I-D >>> Action: draft-ietf-v6ops-design-choices-04.txt". >>> >>> What does the WG think? Should we use the "unnumbered" terms, or should >>> we use just the "... with only link-local address" terms? Is it >>> acceptable to mix the two sets of terms? >>> >>> Philip >>> >>> >>> _______________________________________________ >>> 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 Thu Mar 12 05:41:39 2015 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 D86B31A0099 for ; Thu, 12 Mar 2015 05:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YmR0zvwDycjs for ; Thu, 12 Mar 2015 05:41:36 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 56E3D1A00B7 for ; Thu, 12 Mar 2015 05:41:35 -0700 (PDT) Received: (qmail 55233 invoked from network); 12 Mar 2015 12:41:33 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Mar 2015 12:41:33 -0000 Date: Thu, 12 Mar 2015 13:41:33 +0100 (CET) Message-Id: <20150312.134133.74704744.sthaug@nethelp.no> To: alexandru.petrescu@gmail.com From: sthaug@nethelp.no In-Reply-To: <55018706.5040009@gmail.com> References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 12:41:38 -0000 > YEs, we want traceroute to report an address of a hop, rather than a > three-star string "* * *". > > But traceroute should be able to report link-local addresses, and ULAs, > as well. If it doesnt then it's a problem of that traceroute program. Of course traceroute can report them. They are just not very helpful. > If an enduser needs rather globally-scoped and unique (rathern than LL > and ULA) addresses in traceroute outputs then one should ask her why? > Be them globally-scoped and unique they dont tell anything useful to a > human user of traceroute. They surely dont tell _where_ these addresses > are (like in 'what country'). Getting globally-scoped and unique addresses in the answer is a very important part of what I use traceroute for. I strongly disagree with the claim that "they dont tell anything useful to a human user of traceroute". In most cases it is the PTR lookups for these addresses that actually have the most interesting information - but not always. The IP addresses themselves are also interesting, and can be used for further rounds of traceroute, for instance. They can also be looked up through the various RIRs etc. > Besides, traceroute output is hugely more meaningful when it does not > display addresses but FQDNs. These FQDNs have nothing to do with > address scope either. Surely they do. I cannot get a meaningful PTR lookup for a link-local address. I *can* in many cases get a meaningful PTR lookup for a globally-scoped address. Steinar Haug, AS 2116 From nobody Thu Mar 12 05:48:44 2015 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 A6A4E1A00E7 for ; Thu, 12 Mar 2015 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 8-_bO8RuXCPu for ; Thu, 12 Mar 2015 05:48:40 -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 33F951A00CC for ; Thu, 12 Mar 2015 05:48:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2CCmcQZ029913 for ; Thu, 12 Mar 2015 13:48:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 686FD200E4A for ; Thu, 12 Mar 2015 13:49:02 +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 6091B200C94 for ; Thu, 12 Mar 2015 13:49:02 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2CCmal7016902 for ; Thu, 12 Mar 2015 13:48:38 +0100 Message-ID: <55018B24.1030306@gmail.com> Date: Thu, 12 Mar 2015 13:48:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> In-Reply-To: <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 12:48:42 -0000 Le 11/03/2015 08:55, Owen DeLong a écrit : > I see no benefit and many drawbacks to link-local numbered and > unnumbered interfaces. > > Among them: > > Link Local numbered interfaces are unlikely to be unambiguous when > they appear in traceroutes. Addresses in traceroutes are always ambiguous. It is a fallacy to think these addresses in traceroutes tell anything. In the early era of IPv4 deployment, when could enumerate by hand the deployed address spaces, maybe a traceroute could mean somehting to these all-knowing persons... > They are virtually guaranteed not to makes sense or provide useful > information outside of your administrative domain. No, they may make sense. It depends who and how sets these LL addresses on interfaces. One could very well put fe80:enteprise-name-coded-in-hexa::1 in each interface, or have that in DNS, and a LL-reporting traceroute program. > Unnumbered interfaces provide information only on which router > received a packet, but not which interface. I agree. A traceroute output won't tell on which interface, or whether incoming or outgoing. > This can often be confusing, misleading, or outright useless when > troubleshooting. To me this is just a bit misleading. > In IPv4, address scarcity might, in some circumstances create > sufficient incentive to use such things. > > In IPv6, there is no address scarcity, so I can’t see any upside > whatsoever to either of these constructs. Depends who you talk to. Recently I talked to people who think scarcity is there in IPv6 as well. Somebody who got assigned a /56 for herself will have a hard time to delegate further a /64, be it a single and unique /64. Alex > > Owen > >> On Mar 11, 2015, at 00:42 , Falcon Darkstar Momot >> wrote: >> >> There is a bunch of stuff in IPv6 that is different from IPv4 >> operations. It is a different protocol, after all. Lots of >> paradigms are different, most especially that of addressing. Even >> though I gather there is substantial support for calling those >> links "unnumbered" on the basis of familiarity, Mark is completely >> right in saying that this is the kind of thing that causes >> confusion and oversight later on, and would create something >> unintuitive to future network engineers in a world where IPv6 is >> dominant. The difference whereby no IPv4 address is borrowed (and >> instead a link-local address is used) is sufficient to make this a >> very different configuration. >> >> I put forth the term "locally-numbered" as a succinct and apropos >> alternative. >> >> --Falcon Darkstar Momot --Shadytel >> >> On 10/03/2015 17:22, Mark ZZZ Smith wrote: >>> I'll also point out that I completely understand why it is >>> occurred. It is easier for people to learn things based on >>> things that are similar to what they know, and link-local only >>> IPv6 links are conceptually quite similar to IPv4 unnumbered >>> links. >>> >>> Of course there are also differences, and when something is >>> different, we give it a different name to distinguish it (or a >>> qualifier, however "link-local numbered, unnumbered links" is >>> pretty clumsy (!)) >>> >>> >>> >>> >>> >>> >>> >>> >>> ----- Original Message ----- From: Philip Matthews >>> To: v6ops list Cc: >>> Victor Kuarsingh ; Mark ZZZ Smith >>> Sent: Wednesday, 11 March 2015, 1:52 >>> Subject: Should we use "unnumbered" in IPv6? >>> >>> Just want to get some direct feedback from the WG on the use of >>> the terms "unnumbered interface" and "unnumbered link" in IPv6. >>> >>> Mark Smith, in some comments on the Design Choices draft , has >>> said that he prefers the terms "interface with only link-local >>> address" or "link with only link-local addresses" instead. See >>> the thread with title "I-D Action: >>> draft-ietf-v6ops-design-choices-04.txt". >>> >>> What does the WG think? Should we use the "unnumbered" terms, >>> or should we use just the "... with only link-local address" >>> terms? Is it acceptable to mix the two sets of terms? >>> >>> Philip >>> >>> _______________________________________________ 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 Thu Mar 12 05:49:44 2015 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 472871A00CC for ; Thu, 12 Mar 2015 05:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 WYJyD3kDr612 for ; Thu, 12 Mar 2015 05:49:40 -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 76BB31A00CF for ; Thu, 12 Mar 2015 05:49:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2CCncDr015545 for ; Thu, 12 Mar 2015 13:49:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 77F7A205259 for ; Thu, 12 Mar 2015 13:50:02 +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 64343200E4A for ; Thu, 12 Mar 2015 13:50:02 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2CCnbg2017664 for ; Thu, 12 Mar 2015 13:49:38 +0100 Message-ID: <55018B61.7060904@gmail.com> Date: Thu, 12 Mar 2015 13:49:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 12:49:43 -0000 Le 11/03/2015 11:17, Mikael Abrahamsson a écrit : > On Tue, 10 Mar 2015, Philip Matthews wrote: > >> Just want to get some direct feedback from the WG on the use of the >> terms "unnumbered interface" and "unnumbered link" in IPv6. >> >> Mark Smith, in some comments on the Design Choices draft , has said >> that he prefers the terms "interface with only link-local address" or >> "link with only link-local addresses" instead. See the thread with >> title "I-D Action: draft-ietf-v6ops-design-choices-04.txt". >> >> What does the WG think? Should we use the "unnumbered" terms, or >> should we use just the "... with only link-local address" terms? Is >> it acceptable to mix the two sets of terms? > > I do not like "unnumbered" at all. I agree I dont like it either. It's as if there were no numbers there. Alex > Cisco for instance has "interface unnumbered loopback0". This doesn't > mean the interface doesn't have a number, it means it'll use the > loopback0 IPv4 address. > > So I would much more prefer to say "link local only" interface or > something to that effect. That would avoid confusion. > From nobody Thu Mar 12 05:55:12 2015 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 432911A00E0 for ; Thu, 12 Mar 2015 05:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 x58AkN3058cn for ; Thu, 12 Mar 2015 05:55:09 -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 713401A00D0 for ; Thu, 12 Mar 2015 05:55:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2CCt7qN017490; Thu, 12 Mar 2015 13:55:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 819C9200C33; Thu, 12 Mar 2015 13:55:31 +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 72F97205415; Thu, 12 Mar 2015 13:55:31 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2CCt6Ix011104; Thu, 12 Mar 2015 13:55:07 +0100 Message-ID: <55018CAA.7010104@gmail.com> Date: Thu, 12 Mar 2015 13:55:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sthaug@nethelp.no References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> In-Reply-To: <20150312.134133.74704744.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 12:55:11 -0000 Le 12/03/2015 13:41, sthaug@nethelp.no a écrit : >> YEs, we want traceroute to report an address of a hop, rather than a >> three-star string "* * *". >> >> But traceroute should be able to report link-local addresses, and ULAs, >> as well. If it doesnt then it's a problem of that traceroute program. > > Of course traceroute can report them. They are just not very helpful. > >> If an enduser needs rather globally-scoped and unique (rathern than LL >> and ULA) addresses in traceroute outputs then one should ask her why? >> Be them globally-scoped and unique they dont tell anything useful to a >> human user of traceroute. They surely dont tell _where_ these addresses >> are (like in 'what country'). > > Getting globally-scoped and unique addresses in the answer is a very > important part of what I use traceroute for. I strongly disagree with > the claim that "they dont tell anything useful to a human user of > traceroute". In most cases it is the PTR lookups for these addresses > that actually have the most interesting information - but not always. > The IP addresses themselves are also interesting, and can be used for > further rounds of traceroute, for instance. They can also be looked up > through the various RIRs etc. I think none of these can-do things can not be done with link-local addresses. You can have reverse DNS lookups for LL addresses, you can have LL addresses in the RIR allocation databases (maybe as comments), etc. >> Besides, traceroute output is hugely more meaningful when it does not >> display addresses but FQDNs. These FQDNs have nothing to do with >> address scope either. > > Surely they do. I cannot get a meaningful PTR lookup for a link-local > address. I *can* in many cases get a meaningful PTR lookup for a > globally-scoped address. But a LL address can be in the DNS also. It has not been put there in some particular case, but nothing stops it to be there. Alex > > Steinar Haug, AS 2116 > > From nobody Thu Mar 12 05:59:01 2015 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 EAB401A0113 for ; Thu, 12 Mar 2015 05:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 K0AwmEyMcVM8 for ; Thu, 12 Mar 2015 05:58:56 -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 447471A00D0 for ; Thu, 12 Mar 2015 05:58:55 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id AEE1C60A09 for ; Thu, 12 Mar 2015 13:58:53 +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 715EE60054 for ; Thu, 12 Mar 2015 13:58:53 +0100 (CET) Received: (qmail 5192 invoked by uid 1007); 12 Mar 2015 13:58:53 +0100 Date: Thu, 12 Mar 2015 13:58:53 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150312125853.GC54385@Space.Net> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <54FF67E6.6070202@bogus.com> <550188FF.2070008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550188FF.2070008@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] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 12:58:58 -0000 Hi, On Thu, Mar 12, 2015 at 01:39:27PM +0100, Alexandru Petrescu wrote: > Is there a traceroute program that works with ll addresses? This questions says a lot more than any possible answer could. 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 Thu Mar 12 06:00:58 2015 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 946471A00FB for ; Thu, 12 Mar 2015 06:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 cAqL_pvBsV-I for ; Thu, 12 Mar 2015 06:00:55 -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 9B9221A00F7 for ; Thu, 12 Mar 2015 06:00:55 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0CB466291A for ; Thu, 12 Mar 2015 14:00:54 +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 0F56D600DF for ; Thu, 12 Mar 2015 14:00:53 +0100 (CET) Received: (qmail 5390 invoked by uid 1007); 12 Mar 2015 14:00:53 +0100 Date: Thu, 12 Mar 2015 14:00:53 +0100 From: Gert Doering To: sthaug@nethelp.no Message-ID: <20150312130052.GD54385@Space.Net> References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150312.134133.74704744.sthaug@nethelp.no> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 13:00:57 -0000 Hi, On Thu, Mar 12, 2015 at 01:41:33PM +0100, sthaug@nethelp.no wrote: > > But traceroute should be able to report link-local addresses, and ULAs, > > as well. If it doesnt then it's a problem of that traceroute program. > Of course traceroute can report them. They are just not very helpful. While *traceroute* would be able to report anything, no router worth its money should ever send a packet with a LLA source off a link. So you should never see any packets that traceroute could report about. That is, sort of, what the "local" in "local-scoped" is about, no? 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 Thu Mar 12 06:05:05 2015 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 7DE531A00E4 for ; Thu, 12 Mar 2015 06:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 qPmwQoP5CBaS for ; Thu, 12 Mar 2015 06:04:59 -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 1BCF71A00E0 for ; Thu, 12 Mar 2015 06:04:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2CD4vl6003390; Thu, 12 Mar 2015 14:04:57 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 38431205279; Thu, 12 Mar 2015 14:05:21 +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 2276120106D; Thu, 12 Mar 2015 14:05:21 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2CD3sX9021708; Thu, 12 Mar 2015 14:04:56 +0100 Message-ID: <55018EBA.7080200@gmail.com> Date: Thu, 12 Mar 2015 14:03:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gert Doering References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <54FF67E6.6070202@bogus.com> <550188FF.2070008@gmail.com> <20150312125853.GC54385@Space.Net> In-Reply-To: <20150312125853.GC54385@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 13:05:03 -0000 Le 12/03/2015 13:58, Gert Doering a écrit : > Hi, > > On Thu, Mar 12, 2015 at 01:39:27PM +0100, Alexandru Petrescu wrote: >> Is there a traceroute program that works with ll addresses? > > This questions says a lot more than any possible answer could. What does it say? Alex > > Gert Doering > -- NetMaster > From nobody Thu Mar 12 06:06:48 2015 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 C64091A00D0 for ; Thu, 12 Mar 2015 06:06:45 -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 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 H7BaS_dq3YEa for ; Thu, 12 Mar 2015 06:06:39 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F29B1A00E4 for ; Thu, 12 Mar 2015 06:06:39 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id AB7FF632D; Thu, 12 Mar 2015 06:06:37 -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=4OZR7efVNLRx63APcaFvjUioi30=; b= AKzbYFJF5p/j+dp8Idlae+ixyvjpVIHnMKx0ipayLVuM4X0HC8qTdT0QkgAoWy0B NIuFkS0ZrU+4NE6lTDRZMWbNMOn9mXU+/YMPaL2joPo50AtBj9fnhYRKSZM4TC8s VkwNt3crCYrSpO4Har7UQMWYHUJBUW6IKW1hHZBmkEc= 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=qsdHi+mjFIg7vsxUVHG5DKh+NH wWsyHhRo2DbaYC3KvxUTpqrl7VzPbSAbvPDqaoHFPADVLgVIWdJps/3YHmcslQkt wpCokHx8+iNQgNDvhjAKOIpEmke2RU7SdHEWFBfe1SKaqQd/K8x+MTaCeEHg/SX4 wggiYipHEvUhzfkRw= Received: from gomlefisk.localdomain (unknown [195.159.234.46]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 4FB106315; Thu, 12 Mar 2015 06:06:37 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 3B2E640A95AB; Thu, 12 Mar 2015 14:06:37 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5D68B0A3-D2BE-4EED-A76F-E5A75AD689A6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <54FE4416.60601@gont.com.ar> Date: Thu, 12 Mar 2015 14:06:36 +0100 Message-Id: <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.2087) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 13:06:46 -0000 --Apple-Mail=_5D68B0A3-D2BE-4EED-A76F-E5A75AD689A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think you can equate =E2=80=98real world=E2=80=99 with = =E2=80=98public servers=E2=80=99. to me it seems the draft documents what should be expected. public = servers doesn=E2=80=99t accept packets that aren=E2=80=99t part of the = service they offer. what is it you find unexpected in the behaviour you have found? I=E2=80=99m concerned about this draft. I think it will be used to = justify claims that fragmentation, extension headers or new transport = protocols cannot be deployed, but as far as I can see it does no such = thing. if you wanted to see how extension headers are treated end to end in the = Internet, then measure that. cheers, Ole > On 10 Mar 2015, at 2:08 , Fernando Gont wrote: >=20 > Folks, >=20 > At the IETF meeting in Hawaii we presented > draft-gont-v6ops-ipv6-ehs-in-real-world. Folks seemed to be in favor = of > an I-D providing real-world data about the extent to which packets = with > EHs are dropped in the Internet, but didn't support having the I-D > provide advice on this topic. >=20 > We have revised the I-D. Lots of things were corrected and/or = clarified. > And all such text the wg was not in agreement with has now been = removed. >=20 > The new rev is available at: > = >=20 > Please do let us now if you have any feedback. >=20 > Thanks! >=20 > Best regards, > Fernando >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt > Date: Sun, 08 Mar 2015 22:36:09 -0700 > From: internet-drafts@ietf.org > To: Will Liu (Shucheng) , J. Linkova > , Shucheng LIU (Will) , Tim > Chown , Tim Chown , Fernando > Gont , Fernando Gont , = J. > Linkova >=20 >=20 > A new version of I-D, draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. >=20 > Name: draft-gont-v6ops-ipv6-ehs-in-real-world > Revision: 02 > Title: Observations on IPv6 EH Filtering in the Real = World > Document date: 2015-03-08 > Group: Individual Submission > Pages: 15 > URL: > = http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-worl= d-02.txt > Status: > = https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-in-real-world/ > Htmlized: > http://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-02 > Diff: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-in-real-world= -02 >=20 > Abstract: > This document presents real-world data regarding the extent to which > packets with IPv6 extension headers are filtered in the Internet (as > measured in August 2014), and where in the network such filtering > occurs. 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. This document also explains how the > aforementioned results were obtained, such that the corresponding > measurements can be reproduced by other members of the community. >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_5D68B0A3-D2BE-4EED-A76F-E5A75AD689A6 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 iQEcBAEBCgAGBQJVAY9cAAoJEFuJXizso86geLUH/A0Rfz5i23AJIECcFlILwHwO MzOF6NPBaoMzm3cJAwC5JGlS9HmrEUABowDTRBzPpKpTKL6AfRVdRYZz+Hk/1Crk GSk6qP02QM3oWuutu4WiTvHUOMDN/fM0GVpe2Nuj03TygZ/eXjT3678YT3v/XiG5 ujhnGbVnoJ/XkwvNeP7zFWl6n2RYPt4q81l8Chnmk2J8GzYWnKjM9AqFeTcvZI4a w2aNKubXzlNWF4r7a9phExH1VC6WjEv4oxQv4NxOcBI91SjZk27iCmOEDXBzh2md Q5eXiveg717JmZLkxkEjPwT/A9TrecMXEmT9cu18RlwOtdsH/c3ATu7EEdOSGEo= =mWT9 -----END PGP SIGNATURE----- --Apple-Mail=_5D68B0A3-D2BE-4EED-A76F-E5A75AD689A6-- From nobody Thu Mar 12 06:06:49 2015 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 1D0CA1A00E4 for ; Thu, 12 Mar 2015 06:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4WOhxej64HrI for ; Thu, 12 Mar 2015 06:06:39 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 95ED51A00C5 for ; Thu, 12 Mar 2015 06:06:38 -0700 (PDT) Received: (qmail 57309 invoked from network); 12 Mar 2015 13:06:37 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Mar 2015 13:06:37 -0000 Date: Thu, 12 Mar 2015 14:06:37 +0100 (CET) Message-Id: <20150312.140637.41684583.sthaug@nethelp.no> To: gert@space.net From: sthaug@nethelp.no In-Reply-To: <20150312130052.GD54385@Space.Net> References: <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 13:06:46 -0000 > > > But traceroute should be able to report link-local addresses, and ULAs, > > > as well. If it doesnt then it's a problem of that traceroute program. > > Of course traceroute can report them. They are just not very helpful. > > While *traceroute* would be able to report anything, no router worth its > money should ever send a packet with a LLA source off a link. So you > should never see any packets that traceroute could report about. Agreed. I'm just commenting on the claim that link-local addresses would be good for traceroute - a claim I strongly disagree with. Steinar Haug, AS 2116 From nobody Thu Mar 12 06:11:18 2015 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 33F051A00E4 for ; Thu, 12 Mar 2015 06:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 l3hC16GV56Sn for ; Thu, 12 Mar 2015 06:11:13 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 7A18C1A00E1 for ; Thu, 12 Mar 2015 06:11:12 -0700 (PDT) Received: (qmail 57532 invoked from network); 12 Mar 2015 13:11:11 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Mar 2015 13:11:11 -0000 Date: Thu, 12 Mar 2015 14:11:11 +0100 (CET) Message-Id: <20150312.141111.71137842.sthaug@nethelp.no> To: alexandru.petrescu@gmail.com From: sthaug@nethelp.no In-Reply-To: <55018B24.1030306@gmail.com> References: <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> <55018B24.1030306@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 13:11:17 -0000 > > Link Local numbered interfaces are unlikely to be unambiguous when > > they appear in traceroutes. > > Addresses in traceroutes are always ambiguous. > > It is a fallacy to think these addresses in traceroutes tell anything. You are of course free to believe that. Meanwhile, I plan to continue using traceroute as a useful tool, keeping in mind the valuable advice from Richard Steenbergen's Nanog presentation at https://www.nanog.org/sites/default/files/tuesday_steenbergen_troublshootingtraceroute_62.49.pdf Steinar Haug, AS 2116 From nobody Thu Mar 12 06:15:01 2015 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 C712E1A0105 for ; Thu, 12 Mar 2015 06:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 hj3V7-voxp8F for ; Thu, 12 Mar 2015 06:14:57 -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 C1AE01A00F7 for ; Thu, 12 Mar 2015 06:14:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2CDEs9c001484; Thu, 12 Mar 2015 14:14:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7F64C20536D; Thu, 12 Mar 2015 14:15:18 +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 67407200C3B; Thu, 12 Mar 2015 14:15:18 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2CDErBR007219; Thu, 12 Mar 2015 14:14:54 +0100 Message-ID: <5501914D.8060604@gmail.com> Date: Thu, 12 Mar 2015 14:14:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gert Doering , sthaug@nethelp.no References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> In-Reply-To: <20150312130052.GD54385@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 13:14:59 -0000 Le 12/03/2015 14:00, Gert Doering a écrit : > Hi, > > On Thu, Mar 12, 2015 at 01:41:33PM +0100, sthaug@nethelp.no wrote: >>> But traceroute should be able to report link-local addresses, and >>> ULAs, as well. If it doesnt then it's a problem of that >>> traceroute program. >> Of course traceroute can report them. They are just not very >> helpful. > > While *traceroute* would be able to report anything, no router worth > its money should ever send a packet with a LLA source off a link. Well, a router should not _forward_ such a packet, but it could always issue one, why not? Apps with beaconing semantics, or video stream (no need of reply), may use this. > So you should never see any packets that traceroute could report > about. Traceroute is a diagnostic program. I think you have no RFC that specifies how traceroute acts. You can write a 'traceroute' program that reports LL addresses, I dont see a problem in that. > That is, sort of, what the "local" in "local-scoped" is about, no? It's local for locally-scoped protocols. But I can very well have a web page telling me all the addresses of a very distant router (many IP hops away), including its link-local addresses. LL addresses can be present in payloads w/o problem. LL addresses can be present in IPv6 Routing Header. With this at hand a 'traceroute' program can report LL addresses. Alex > > Gert Doering -- NetMaster > From nobody Thu Mar 12 06:22:47 2015 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 588C91A00E0 for ; Thu, 12 Mar 2015 06:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 OCm2dzBNeg-N for ; Thu, 12 Mar 2015 06:22:44 -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 700821A00CF for ; Thu, 12 Mar 2015 06:22:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2CDMg9M030995; Thu, 12 Mar 2015 14:22:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 626F020543A; Thu, 12 Mar 2015 14:23:06 +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 4D49120106D; Thu, 12 Mar 2015 14:23:06 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2CDMfav015156; Thu, 12 Mar 2015 14:22:42 +0100 Message-ID: <55019321.5040607@gmail.com> Date: Thu, 12 Mar 2015 14:22:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sthaug@nethelp.no References: <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> <55018B24.1030306@gmail.com> <20150312.141111.71137842.sthaug@nethelp.no> In-Reply-To: <20150312.141111.71137842.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 13:22:46 -0000 Le 12/03/2015 14:11, sthaug@nethelp.no a écrit : >>> Link Local numbered interfaces are unlikely to be unambiguous >>> when they appear in traceroutes. >> >> Addresses in traceroutes are always ambiguous. >> >> It is a fallacy to think these addresses in traceroutes tell >> anything. > > You are of course free to believe that. Meanwhile, I plan to continue > using traceroute as a useful tool, I agree, Traceroute is a hugely useful tool. But its existence should not mean LL-only links should not exist. It's as if we said that yahoo (the address) should not exist because firefox (the tool) homes into a google page: firefox could home into a yahoo page as well. LL addresses could have as much semantics in them as globally-scoped addresses. > keeping in mind the valuable advice from Richard Steenbergen's Nanog > presentation at > > https://www.nanog.org/sites/default/files/tuesday_steenbergen_troublshootingtraceroute_62.49.pdf Thanks for the pointer. YEs, this is precisely the kind of out-of-band info that is useful to a traceroute user. Alex > > Steinar Haug, AS 2116 > > From nobody Thu Mar 12 07:02:04 2015 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 BC5EF1A01EA for ; Thu, 12 Mar 2015 07:02:02 -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 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 vdxEdULmKyoA for ; Thu, 12 Mar 2015 07:02:00 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [46.182.8.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 9EAA61A0111 for ; Thu, 12 Mar 2015 07:02:00 -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.1/8.14.9) with ESMTPSA id t2CE0iof069315 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 14:00:45 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <55019C0C.2050102@foobar.org> Date: Thu, 12 Mar 2015 14:00:44 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan , Fernando Gont References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> In-Reply-To: <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 14:02:02 -0000 On 12/03/2015 13:06, Ole Troan wrote: > to me it seems the draft documents what should be expected. public > servers doesn’t accept packets that aren’t part of the service they > offer. i suspect the points being made here are that: 1. within the terms of the methodology used, results are observed. 2. if end points on the v6 internet attempt to connects to these systems where the packets are configured to use EHs, those connections may fail as a direct result of using EHs. 3. this appears to be a problem at both the core and edge of the ipv6 internet These are important issues and need to be addressed. Although it needs a good deal more work, I'd like to see v6ops adopting this ID. Nick From nobody Thu Mar 12 07:09:56 2015 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 D754C1A044D for ; Thu, 12 Mar 2015 07:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 e336hFdjRBqB for ; Thu, 12 Mar 2015 07:09:54 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E251A01D5 for ; Thu, 12 Mar 2015 07:09:53 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CE9RuA027438; Thu, 12 Mar 2015 14:09:27 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t2CE9RuA027438 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1426169369; bh=9moQT15Y2RQX3aynbOo1+/IdeKY=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=smh8DDOp1vUBjzPitpXYj8rTZZ1ONX8M5CcG09BaZgTcAtFHM3XmdVeEpJbNPrZ9h TnYeTD0H3nhcpuvfx39iJ5nt3jvqA5YF8kH5kwAMxrKulLE8jKMQbOf3bBWOzbN+uh RrLZ1HkS6oYbp4VsNoq1OWUcpg1CH3nDaS+V2CrA= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id r2BE9R119470864090 ret-id none; Thu, 12 Mar 2015 14:09:29 +0000 Received: from [IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371] ([IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CE9MC4031609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 14:09:23 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Chown In-Reply-To: <55019C0C.2050102@foobar.org> Date: Thu, 12 Mar 2015 14:09:23 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.2070.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r2BE9R119470864000; tid=r2BE9R119470864090; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t2CE9RuA027438 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 14:09:56 -0000 Hi, > On 12 Mar 2015, at 14:00, Nick Hilliard wrote: >=20 > On 12/03/2015 13:06, Ole Troan wrote: >> to me it seems the draft documents what should be expected. public >> servers doesn=92t accept packets that aren=92t part of the service = they >> offer. >=20 > i suspect the points being made here are that: >=20 > 1. within the terms of the methodology used, results are observed. >=20 > 2. if end points on the v6 internet attempt to connects to these = systems > where the packets are configured to use EHs, those connections may = fail as > a direct result of using EHs. >=20 > 3. this appears to be a problem at both the core and edge of the ipv6 = internet >=20 > These are important issues and need to be addressed. >=20 > Although it needs a good deal more work, I'd like to see v6ops = adopting > this ID. The point is that this draft captures and distills the results of a = number of different measurements taken by different groups. These have = been presented at IEPG over recent IETFs, by at least Fernando, Jen, and = myself. The results are of concern, but there is an implied call for further = measurements and analysis. I agree that Fernando=92s original assertions = in the draft were too strong too early, but there is an important issue = here. I also don=92t think the results can be discounted on the basis = that Ole makes. Remember the principles that Brian=92s RFC requires - = these are not (yet) being implemented. How specific servers handle = various EHs (with nothing on the path) can be demonstrated by running = the tests between clients and servers on the same link. Tim= From nobody Thu Mar 12 08:24:23 2015 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 DFA421A6FF5 for ; Thu, 12 Mar 2015 08:24:22 -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 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 5GE-W_MDXNFV for ; Thu, 12 Mar 2015 08:24:21 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BCF1A7018 for ; Thu, 12 Mar 2015 08:24:21 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 94CC262A8; Thu, 12 Mar 2015 08:24:19 -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=508FFNEt5yrkid5KWeVac11KBLY=; b= ZvJsl+jSnkDy2Y8Ry9RssKMiPQwoJqFasZiaA8g0OlBW6XQf9JZqsXYR9ifE6YjM yaK3jN01MwyMX3jH4z+peYSsrcFqCZhusL/c8Rt2VwnGQmvTN/5jVVC7Xv4AkM8K kvY1vkhHvy/EV5eAzc4qsvBHlZQqZo/iRNm96Eggs1w= 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=jLR4Jy8566Y+HPmxwE5ag0MPnZ 6bN/ta9UHf0j3utaH4clugiQF2ewQMb9OjenZuPu3PL5KwxrAcUo3fHQREsFVGSW uQzIZs9DzYdj6Ft7kYF2xS+4Z0SrsWLoflamjio155wHsvHQi6SlBF0iiUFQWRuq I0KWaqSj2C6ycfX+M= Received: from gomlefisk.localdomain (unknown [195.159.234.46]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id DFDEF616C; Thu, 12 Mar 2015 08:24:18 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id A45B440AA551; Thu, 12 Mar 2015 16:24:17 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_22AE99AD-A8F0-4189-A84A-6B6DB2493153"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <55019C0C.2050102@foobar.org> Date: Thu, 12 Mar 2015 16:24:16 +0100 Message-Id: <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.2087) Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 15:24:23 -0000 --Apple-Mail=_22AE99AD-A8F0-4189-A84A-6B6DB2493153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Nick, >> to me it seems the draft documents what should be expected. public >> servers doesn=92t accept packets that aren=92t part of the service = they >> offer. >=20 > i suspect the points being made here are that: >=20 > 1. within the terms of the methodology used, results are observed. right. the methodology seems to detect a site/system filtering policy. = for an analogy, try to run those measurements against any of my hosts = inside the Cisco corporate network. you=92ll find that all UDP gets = filtered. can you or should you draw any general conclusions from that? = I think not. >=20 > 2. if end points on the v6 internet attempt to connects to these = systems > where the packets are configured to use EHs, those connections may = fail as > a direct result of using EHs. sure, is that a problem? >=20 > 3. this appears to be a problem at both the core and edge of the ipv6 = internet I can=92t find anything in the draft showing that the core of the = Internet is applying this filtering policy. >=20 > These are important issues and need to be addressed. >=20 > Although it needs a good deal more work, I'd like to see v6ops = adopting > this ID. I also think it is important to measure IPv6 EH behaviour in the = Internet. I=92m concerned about the methodology used here, and I think = the text way overstates the problem. (there might be a problem of = course, but then a better methodology should be used). cheers, Ole --Apple-Mail=_22AE99AD-A8F0-4189-A84A-6B6DB2493153 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 iQEcBAEBCgAGBQJVAa+hAAoJEFuJXizso86gByYIAJFGloF84GnT2h0RZZztJv34 RSBfkp5Af5W9dn7TM1ljReC9qTahKxb5uN0Rh1q8scqgSUs5/SqslJ+aZMRPOGco JvQSAF5UUpvg0R6JDmxAjvvSO60Wc4jJsnRgFDBVhAWdxWgorpDRbmNAnUp8pONI 6Z4v3Jh0vtyfk+toUxpPxPVXmDvivur4aEM5R3zeD03+m/AoxmZpCbZxPzmhpq0f jZtx55c6bbCbhD+0bL0o8kzzrygkG8op/tT5dxXJ284mOA7g6uKc+C5Eg1I03S0d XGJmrE6SDh7ADZNFgLfpYpSS9blAF7HZRTPnMzz1yDVEJPGtaQnUDVg9EL2Cakk= =Mn3h -----END PGP SIGNATURE----- --Apple-Mail=_22AE99AD-A8F0-4189-A84A-6B6DB2493153-- From nobody Thu Mar 12 10:45:18 2015 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 919DF1A8F3C for ; Thu, 12 Mar 2015 10:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZLAOWSRCdVOS for ; Thu, 12 Mar 2015 10:45:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 95E261A8AEF for ; Thu, 12 Mar 2015 10:45:10 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2CHeTGZ007636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Mar 2015 10:40:29 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2CHeTGZ007636 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426182029; bh=d1XuzhWEEJneMRJBoFa20+F85vU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=wfjxn5b/TELW/3jSupcZcDcJAwwmU0G8649xufalHInbaOh+h2hiof4vV/QPhhKVn AgjvYI8A/nXFmGETqAH0pk/ow1sEExwXvci1orR9rN8lNSx2KwaI3zVXx9xGh74F3b 19q/Pe9m4QF0mzRLeqw8RZvadN2S/kbcSM8H7jJY= Content-Type: multipart/alternative; boundary="Apple-Mail=_BA5D92DB-267D-4AEB-9184-C32D84684369" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Owen DeLong In-Reply-To: <55018706.5040009@gmail.com> Date: Thu, 12 Mar 2015 10:40:28 -0700 Message-Id: <8A27F909-4176-4F63-830F-D422B17C16AD@delong.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 12 Mar 2015 10:40:29 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 17:45:15 -0000 --Apple-Mail=_BA5D92DB-267D-4AEB-9184-C32D84684369 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [snip] >>=20 >> I=E2=80=99m not saying interfaces shouldn=E2=80=99t have a link local = address. >> (jeez.) >>=20 >> I=E2=80=99m saying that not puting a real address on a link that = shows up in >> traceroutes is a bad idea. >=20 > Yes and no. >=20 > YEs, we want traceroute to report an address of a hop, rather than a > three-star string "* * *=E2=80=9D. No=E2=80=A6 We want traceroute to report an address of a hop that has a = valid binding in ip6.arpa that tells people something meaningful about the hop, and, = ideally, the interface of arrival at said hop. > But traceroute should be able to report link-local addresses, and = ULAs, > as well. If it doesnt then it's a problem of that traceroute program. See above. Merely reporting an address that is utterly and completely = meaningless outside of the zone of administrative control (ULA) or outside of the = local link (LL) is less than helpful. > If an enduser needs rather globally-scoped and unique (rathern than LL > and ULA) addresses in traceroute outputs then one should ask her why? > Be them globally-scoped and unique they dont tell anything useful to a > human user of traceroute. They surely dont tell _where_ these = addresses > are (like in 'what country=E2=80=99). Well, the address being GUA alone is not the complete solution, but it = is certainly a necessary component. Obviously, the next step is to provide a useful = mapping in ip6.arpa as well. For example: owen.delong.com:owen /home4/owen (29) % traceroute6 www.facebook.com traceroute to www.facebook.com (2a03:2880:10:cf07:face:b00c:0:1), 30 = hops max, 80 byte packets 1 2620:0:930:0:2e6b:f5ff:fe03:a80 (2620:0:930:0:2e6b:f5ff:fe03:a80) = 1.788 ms 1.777 ms 1.787 ms 2 owen-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1f03:9c::1) 12.973 = ms 19.452 ms 20.374 ms 3 ge4-22.core2.fmt1.he.net (2001:470:0:1f::1) 28.750 ms 29.679 ms = 29.739 ms 4 ge5-15.core1.fmt2.he.net (2001:470:0:1bc::1) 20.313 ms 20.331 ms = 20.337 ms 5 10ge1-1.core1.sjc2.he.net (2001:470:0:31::2) 20.332 ms * * 6 * facebook.gige-g5-9.core1.sjc2.he.net (2001:470:0:14a::2) 18.399 = ms 18.371 ms 7 ae1.bb03.sjc1.tfbnw.net (2620:0:1cff:dead:beef::c5a) 18.370 ms = 24.237 ms 14.423 ms 8 ae24.bb04.prn2.tfbnw.net (2620:0:1cff:dead:beef::c32) 33.334 ms = 32.289 ms 33.340 ms 9 ae4.dr05.prn1.tfbnw.net (2620:0:1cff:dead:beef::68d) 39.411 ms = ae13.dr05.prn1.tfbnw.net (2620:0:1cff:dead:beef::69d) 39.557 ms = ae4.dr02.prn1.tfbnw.net (2620:0:1cff:dead:beef::69b) 38.365 ms 10 po1019.csw12a.prn1.tfbnw.net (2620:0:1cff:dead:beef::1769) 48.094 = ms po1021.csw12d.prn1.tfbnw.net (2620:0:1cff:dead:beef::1785) 39.399 ms = po1019.csw12b.prn1.tfbnw.net (2620:0:1cff:dead:beef::1775) 39.348 ms 11 * * * 12 edge-star6-shv-12-prn1.facebook.com = (2a03:2880:10:cf07:face:b00c:0:1) 37.765 ms 38.419 ms 36.471 ms Hop 1 doesn=E2=80=99t provide useful information, but it=E2=80=99s the = SLAAC address of the interior side of a local router, so it=E2=80=99s = only going to be seen on outbound traceroutes from my small site. The other hops do provide useful ip6.arpa mappings (with the obvious = exception of hop 11 which doesn=E2=80=99t respond at all, probably a = load balancer at FB). I can tell from the information provided by the various operators that = my packet is delivered to an HE tunnelserver in their Fremont 1 = datacenter, then forwarded to a core router in that same datacenter, = over to their Fremont 2 datacenter, etc. I can even tell that on the core router in Fremont 1, my packet arrived = on gigabit ethernet interface card 4 port 22. I can also see interface = information on the remaining hops as well. The vast majority of providers put this information into ip6.arpa to = make their lives easier when it comes to troubleshooting, but it also = happens to make life easier for external users as well. > An address present in a traceroute output tells many things _if_ that > end user has an mental association of the address set out-of-band = (like > "all addresses starting 2a02 belong to the operator I trust"). But > these out-of-band associations have no requirement whatsoever on the > scope of the address, or its uniqueness across Internet, or > prefix-middle-suffix position of the trusted incantation. One could > very well have fe80:X:1 displayed by traceroute, and know out-of-band > that when X is in the address then the operator is trusted. (e.g. > X=3D=3Dface:b00c). Actually, they do. If I build a mental association of =E2=80=9Call addresses starting with = fd0c:face:b00c::=E2=80=9D belong to Face Book, not only am I an idiot for trusting some sort of = association between ULA and a particular organization, but I=E2=80=99m also quite likely to = be wrong some significant portion of the time. > Besides, traceroute output is hugely more meaningful when it does not > display addresses but FQDNs. These FQDNs have nothing to do with > address scope either. Yes, they do. You can=E2=80=99t (legitimately) create externally visible = ip6.arpa records for addresses that are not GUA scoped. If you think that you can, please = share whatever you are smoking. Owen >=20 > Alex >=20 >=20 >>=20 >>> They are viewed by some as also having an important security >>> property: they simply don't work off-link. >>> draft-behringer-anima-autonomic-control-plane takes this view, for >>> example. >>=20 >> Blah blah blah. >>=20 >>> Unnumbered, in the literal sense, doesn't exist in IPv6, which is >>> why we are having this terminological discussion in the first >>> place. >>=20 >> It doesn=E2=80=99t exist in IPv4 in the literal sense, either. As = others >> have pointed out, what is called an unnumbered interface in IPv4 is >> an interface that shares numbering with a loopback or other >> interface which is an utter hack that yielded more confusion than >> useful results in the early efforts to reduce IPv4 address >> consumption. >>=20 >> So, if you have something you don=E2=80=99t want to communicate off = link AT >> ALL, then by all means, go ahead and use link-local only numbering >> to your hearts content. >>=20 >> Otherwise, please put a real GUA on the interface to reduce the >> number of problems you inflict on others when they have to >> troubleshoot something that involves/transits/originates from/etc. >> your network. >>=20 >> Owen >>=20 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org = https://www.ietf.org/mailman/listinfo/v6ops = >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_BA5D92DB-267D-4AEB-9184-C32D84684369 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [snip]


I=E2=80=99= m not saying interfaces shouldn=E2=80=99t have a link local address.
(jeez.)

I=E2=80=99m saying that = not puting a real address on a link that shows up in
traceroutes is a bad idea.

Yes and no.

YEs, we want traceroute to report an address of = a hop, rather than a
three-star string "* * = *=E2=80=9D.

No=E2=80=A6 We = want traceroute to report an address of a hop that has a valid = binding
in ip6.arpa that tells people something meaningful = about the hop, and, ideally,
the interface of arrival at said = hop.

But traceroute should be = able to report link-local addresses, and ULAs,
as well.  If it doesnt then it's a problem = of that traceroute program.

See above. = Merely reporting an address that is utterly and completely = meaningless
outside of the zone of administrative control = (ULA) or outside of the local link (LL)
is less than = helpful.

If an enduser needs = rather globally-scoped and unique (rathern than LL
and ULA) addresses in traceroute outputs then = one should ask her why?
Be them globally-scoped = and unique they dont tell anything useful to a
human user of traceroute.  They surely dont = tell _where_ these addresses
are (like in 'what = country=E2=80=99).

Well, the = address being GUA alone is not the complete solution, but it is = certainly
a necessary component. Obviously, the next step is = to provide a useful mapping
in ip6.arpa as well.

For example:

owen.delong.com:owen /home4/owen (29) % traceroute6 www.facebook.com
traceroute = to www.facebook.com = (2a03:2880:10:cf07:face:b00c:0:1), 30 hops max, 80 byte = packets
 1  2620:0:930:0:2e6b:f5ff:fe03:a80 = (2620:0:930:0:2e6b:f5ff:fe03:a80)  1.788 ms  1.777 ms  = 1.787 ms
 2  owen-2.tunnel.tserv2.fmt.ipv6.he.net = (2001:470:1f03:9c::1)  12.973 ms  19.452 ms  20.374 = ms
 3  ge4-22.core2.fmt1.he.net (2001:470:0:1f::1)  28.750 = ms  29.679 ms  29.739 ms
 4  ge5-15.core1.fmt2.he.net (2001:470:0:1bc::1)  20.313 = ms  20.331 ms  20.337 ms
 5  10ge1-1.core1.sjc2.he.net (2001:470:0:31::2)  20.332 = ms * *
 6  * facebook.gige-g5-9.core1.sjc2.he.net (2001:470:0:14a::2)  18.399 = ms  18.371 ms
 7  ae1.bb03.sjc1.tfbnw.net = (2620:0:1cff:dead:beef::c5a)  18.370 ms  24.237 ms  = 14.423 ms
 8  ae24.bb04.prn2.tfbnw.net = (2620:0:1cff:dead:beef::c32)  33.334 ms  32.289 ms  = 33.340 ms
 9  ae4.dr05.prn1.tfbnw.net = (2620:0:1cff:dead:beef::68d)  39.411 ms ae13.dr05.prn1.tfbnw.net = (2620:0:1cff:dead:beef::69d)  39.557 ms ae4.dr02.prn1.tfbnw.net = (2620:0:1cff:dead:beef::69b)  38.365 ms
10  po1019.csw12a.prn1.tfbnw.net = (2620:0:1cff:dead:beef::1769)  48.094 ms po1021.csw12d.prn1.tfbnw.net = (2620:0:1cff:dead:beef::1785)  39.399 ms po1019.csw12b.prn1.tfbnw.net = (2620:0:1cff:dead:beef::1775)  39.348 ms
11  * * *
12  edge-star6-shv-12-prn1.facebook.com = (2a03:2880:10:cf07:face:b00c:0:1)  37.765 ms  38.419 ms  = 36.471 ms


Hop 1 doesn=E2=80=99t provide useful = information, but it=E2=80=99s the SLAAC address of the interior side of = a local router, so it=E2=80=99s only going to be seen on outbound = traceroutes from my small site.

The other hops do provide useful = ip6.arpa mappings (with the obvious exception of hop 11 which doesn=E2=80=99= t respond at all, probably a load balancer at FB).

I can tell from the = information provided by the various operators that my packet is = delivered to an HE tunnelserver in their Fremont 1 datacenter, then = forwarded to a core router in that same datacenter, over to their = Fremont 2 datacenter, etc.

I can even tell that on the core router in Fremont 1, my = packet arrived on gigabit ethernet interface card 4 port 22. I can also = see interface information on the remaining hops as well.

The vast majority of = providers put this information into ip6.arpa to make their lives easier = when it comes to troubleshooting, but it also happens to make life = easier for external users as well.

An address present in a = traceroute output tells many things _if_ that
end user has an mental association of the = address set out-of-band (like
"all addresses starting = 2a02 belong to the operator I trust").  But
these out-of-band associations have no = requirement whatsoever on the
scope of the address, or = its uniqueness across Internet, or
prefix-middle-suffix position of the trusted = incantation.  One could
very well have fe80:X:1 = displayed by traceroute, and know out-of-band
that when X is in the address then the operator = is trusted. (e.g.
X=3D=3Dface:b00c).

Actually, they = do.

If I build a mental association = of =E2=80=9Call addresses starting with fd0c:face:b00c::=E2=80=9D = belong
to Face Book, not only am I an idiot for trusting some = sort of association between
ULA and a particular organization, = but I=E2=80=99m also quite likely to be wrong some = significant
portion of the time.

Besides, traceroute output is hugely more = meaningful when it does not
display addresses but = FQDNs.  These FQDNs have nothing to do with
address scope either.

Yes, they do. = You can=E2=80=99t (legitimately) create externally visible ip6.arpa = records
for addresses that are not GUA scoped. If you think = that you can, please share
whatever you are = smoking.

Owen


Alex



They = are viewed by some as also having an important security
property: they simply don't work off-link.
draft-behringer-anima-autonomic-control-plane takes this = view, for
example.

Blah blah blah.

Unnumbered, in the literal sense, doesn't exist = in IPv6, which is
why we are having this terminological = discussion in the first
place.

It doesn=E2=80=99t exist in IPv4 = in the literal sense, either. As others
have pointed out, = what is called an unnumbered interface in IPv4 is
an = interface that shares numbering with a loopback or other
interface which is an utter hack that yielded more confusion = than
useful results in the early efforts to reduce IPv4 = address
consumption.

So, if = you have something you don=E2=80=99t want to communicate off link AT
ALL, then by all means, go ahead and use link-local only = numbering
to your hearts content.

Otherwise, please put a real GUA on the interface to reduce = the
number of problems you inflict on others when they = have to
troubleshoot something that = involves/transits/originates from/etc.
your network.

Owen

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



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

= --Apple-Mail=_BA5D92DB-267D-4AEB-9184-C32D84684369-- From nobody Thu Mar 12 10:49:57 2015 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 C7EB71A001C for ; Thu, 12 Mar 2015 10:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 TBwknSVMzh5H for ; Thu, 12 Mar 2015 10:49:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3A57D1A0040 for ; Thu, 12 Mar 2015 10:49:55 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2CHkU6M008133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Mar 2015 10:46:30 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2CHkU6M008133 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426182390; bh=+laLZlMvcCudr3Xvp5eedfQ+i+U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=BYtt3SZYbNFewgki0qG2d/2KvSnbvZ+IeUaTL4A8OF30OoqrjN0rjcSPuPQBzrDAH IM2eElwgoNuADks6mGRm4Bq/KgFh0M9I07hBJzp8sFjXpGCMj9fpIgGds7MmK6znr2 ZLLhg3OzrLhxgQ0IFcMjcOXHkt+/nme9JcwZPpD4= Content-Type: multipart/alternative; boundary="Apple-Mail=_1C11FF2F-78D2-4268-9286-B3F265DDC76C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Owen DeLong In-Reply-To: <55018CAA.7010104@gmail.com> Date: Thu, 12 Mar 2015 10:46:29 -0700 Message-Id: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <55018CAA.7010104@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 12 Mar 2015 10:46:30 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 17:49:56 -0000 --Apple-Mail=_1C11FF2F-78D2-4268-9286-B3F265DDC76C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Mar 12, 2015, at 05:55 , Alexandru Petrescu = wrote: >=20 > Le 12/03/2015 13:41, sthaug@nethelp.no a = =E9crit : >>> YEs, we want traceroute to report an address of a hop, rather than a >>> three-star string "* * *". >>>=20 >>> But traceroute should be able to report link-local addresses, and = ULAs, >>> as well. If it doesnt then it's a problem of that traceroute = program. >>=20 >> Of course traceroute can report them. They are just not very helpful. >>=20 >>> If an enduser needs rather globally-scoped and unique (rathern than = LL >>> and ULA) addresses in traceroute outputs then one should ask her = why? >>> Be them globally-scoped and unique they dont tell anything useful to = a >>> human user of traceroute. They surely dont tell _where_ these = addresses >>> are (like in 'what country'). >>=20 >> Getting globally-scoped and unique addresses in the answer is a very >> important part of what I use traceroute for. I strongly disagree with >> the claim that "they dont tell anything useful to a human user of >> traceroute". In most cases it is the PTR lookups for these addresses >> that actually have the most interesting information - but not always. >> The IP addresses themselves are also interesting, and can be used for >> further rounds of traceroute, for instance. They can also be looked = up >> through the various RIRs etc. >=20 > I think none of these can-do things can not be done with link-local = addresses. >=20 > You can have reverse DNS lookups for LL addresses, you can have LL = addresses in the RIR allocation databases (maybe as comments), etc. I personally guarantee you that no RIR whois server is going to respond = usefully to a query for an address starting in fe80:: any time soon. I can also guarantee you that attempts to get any portion of = 0.8.e.f.ip6.arpa delegated to your nameserver by any of the RIRs are = also not likely to succeed. Given that, how, exactly, do you propose that your above statements can = possible be true? >=20 >>> Besides, traceroute output is hugely more meaningful when it does = not >>> display addresses but FQDNs. These FQDNs have nothing to do with >>> address scope either. >>=20 >> Surely they do. I cannot get a meaningful PTR lookup for a link-local >> address. I *can* in many cases get a meaningful PTR lookup for a >> globally-scoped address. >=20 > But a LL address can be in the DNS also. It has not been put there in = some particular case, but nothing stops it to be there. Not in a useful way it cannot. Sure, you can create an 0.8.e.f.ip6.arpa = zone within your DNS server and answer queries that arrive there, but = anyone outside of your administrative control is unlikely to ask your = server for that information. The RIRs are not going to delegate NS for = any portion of 0.8.e.f.ip6.arpa, and I expect neither will IANA or IETF. We=92re talking about a global internet here, not some isolated LAN = segment. If it=92s an isolated LAN segment do whatever you want, the = IETF doesn=92t care. You don=92t need an RFC. RFCs and the IETF process = are for developing standards for cooperating networks participating in a = global internet. If you aren=92t one of those, then you can follow or = not follow them as you wish on your non-connected network. Owen --Apple-Mail=_1C11FF2F-78D2-4268-9286-B3F265DDC76C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Mar 12, 2015, at 05:55 , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

Le 12/03/2015 13:41, sthaug@nethelp.no a =E9crit :
YEs, we want traceroute to report an address of a hop, = rather than a
three-star string "* * *".

But traceroute should be able to report link-local addresses, = and ULAs,
as well.  If it doesnt then it's a problem = of that traceroute program.

Of = course traceroute can report them. They are just not very helpful.

If an = enduser needs rather globally-scoped and unique (rathern than LL
and ULA) addresses in traceroute outputs then one should ask = her why?
Be them globally-scoped and unique they dont tell = anything useful to a
human user of traceroute.  They = surely dont tell _where_ these addresses
are (like in = 'what country').

Getting = globally-scoped and unique addresses in the answer is a very
important part of what I use traceroute for. I strongly = disagree with
the claim that "they dont tell anything = useful to a human user of
traceroute". In most cases it is = the PTR lookups for these addresses
that actually have the = most interesting information - but not always.
The IP = addresses themselves are also interesting, and can be used for
further rounds of traceroute, for instance. They can also be = looked up
through the various RIRs etc.

I think none of these = can-do things can not be done with link-local addresses.

You can have reverse DNS lookups for LL = addresses, you can have LL addresses in the RIR allocation databases = (maybe as comments), etc.

I = personally guarantee you that no RIR whois server is going to respond = usefully to a query for an address starting in fe80:: any time = soon.

I can also guarantee you that = attempts to get any portion of 0.8.e.f.ip6.arpa delegated to your = nameserver by any of the RIRs are also not likely to = succeed.

Given that, how, exactly, = do you propose that your above statements can possible be = true?


Besides, = traceroute output is hugely more meaningful when it does not
display addresses but FQDNs.  These FQDNs have nothing = to do with
address scope either.

Surely they do. I cannot get a = meaningful PTR lookup for a link-local
address. I *can* in = many cases get a meaningful PTR lookup for a
globally-scoped= address.

But a LL address can be in = the DNS also.  It has not been put there in some particular case, = but nothing stops it to be there.

Not in a useful way it cannot. Sure, you can create an = 0.8.e.f.ip6.arpa zone within your DNS server and answer queries that = arrive there, but anyone outside of your administrative control is = unlikely to ask your server for that information. The RIRs are not going = to delegate NS for any portion of 0.8.e.f.ip6.arpa, and I expect neither = will IANA or IETF.

We=92re talking = about a global internet here, not some isolated LAN segment. If it=92s = an isolated LAN segment do whatever you want, the IETF doesn=92t care. = You don=92t need an RFC. RFCs and the IETF process are for developing = standards for cooperating networks participating in a global internet. = If you aren=92t one of those, then you can follow or not follow them as = you wish on your non-connected network.

Owen


= --Apple-Mail=_1C11FF2F-78D2-4268-9286-B3F265DDC76C-- From nobody Thu Mar 12 10:55:05 2015 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 F3A321A014D for ; Thu, 12 Mar 2015 10:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 SqeJkm44djFd for ; Thu, 12 Mar 2015 10:55:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 809561A0275 for ; Thu, 12 Mar 2015 10:55:01 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2CHqEfX008505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Mar 2015 10:52:14 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2CHqEfX008505 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426182734; bh=ZWreD3ZE1hPt5VOEcqvK/06cUUo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CuQ/IzvZF4+4/YqN7KWYl8+xj4z208jTQktMRL+cc33vXMKDh7Wo3NXHfrnm/UlRj iYqLqiFGUCyILL1iUPBIEmW+MRPEiab+83P41yT1NkMpGUxp3drBK97smmyyBHak7R QxQc6wxt1mGcuIlFwBQlxus4npUr0+QEmWLyvZDk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Owen DeLong In-Reply-To: <5501914D.8060604@gmail.com> Date: Thu, 12 Mar 2015 10:52:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 12 Mar 2015 10:52:14 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 17:55:03 -0000 > On Mar 12, 2015, at 06:14 , Alexandru Petrescu = wrote: >=20 > Le 12/03/2015 14:00, Gert Doering a =E9crit : >> Hi, >>=20 >> On Thu, Mar 12, 2015 at 01:41:33PM +0100, sthaug@nethelp.no wrote: >>>> But traceroute should be able to report link-local addresses, and >>>> ULAs, as well. If it doesnt then it's a problem of that >>>> traceroute program. >>> Of course traceroute can report them. They are just not very >>> helpful. >>=20 >> While *traceroute* would be able to report anything, no router worth >> its money should ever send a packet with a LLA source off a link. >=20 > Well, a router should not _forward_ such a packet, but it could always > issue one, why not? >=20 > Apps with beaconing semantics, or video stream (no need of reply), may = use this. >=20 >> So you should never see any packets that traceroute could report >> about. >=20 > Traceroute is a diagnostic program. I think you have no RFC that = specifies how traceroute acts. >=20 > You can write a 'traceroute' program that reports LL addresses, I dont = see a problem in that. Here=92s the problem=85 Traceroute depends on receiving ICMP HOP_COUNT_EXCEEDED messages with = the hop address embedded in the SRC field of the ICMP datagram. If you are running traceroute on a machine that is not adjacent to the = hop responding with said message from a LL source address, then you will = never see the packet because NONE of the routers between it and you = should forward said packet to a different interface from the one it = arrived on. So, traceroute may report whatever it receives, but it CANNOT receive a = packet with a LL Source address from a non-adjacent router unless all of = the routers in between violate the RFCs regarding forwarding of LL = packets. >> That is, sort of, what the "local" in "local-scoped" is about, no? >=20 > It's local for locally-scoped protocols. But I can very well have a = web page telling me all the addresses of a very distant router (many IP = hops away), including its link-local addresses. Sure, but you=92ll never get the LL address in your traceroute to look = up, so I think the web page is moot. > LL addresses can be present in payloads w/o problem. Yes, but traceroute doesn=92t use the payload. > LL addresses can be present in IPv6 Routing Header. Yes, but I=92m not sure how that applies here, nor am I sure it is = useful for them to appear there. > With this at hand a 'traceroute' program can report LL addresses. Not the way traceroute programs currently work. I think you would be = hard pressed to create a traceroute program that could do so without = modifying code on virtually every deployed IPv6 router as well. Owen >=20 > Alex >=20 >>=20 >> Gert Doering -- NetMaster >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Mar 12 12:25:54 2015 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 EC8AC1A1F1D for ; Thu, 12 Mar 2015 12:25:52 -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_HELO_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 RptSEihfLlYT for ; Thu, 12 Mar 2015 12:25:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B5C1A1F73 for ; Thu, 12 Mar 2015 12:25:39 -0700 (PDT) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) with Microsoft SMTP Server (TLS) id 15.1.99.14; Thu, 12 Mar 2015 19:25:24 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0099.004; Thu, 12 Mar 2015 19:25:23 +0000 From: "Metzler, Dan J" To: Owen DeLong , Alexandru Petrescu Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQW0H0aXH7g/48ckavSwrGIzcwY50WbIYAgAB67QCAAANiAIAAxhuAgABs9ICAAKxlAIAAAvCAgAAFZ4CAAAPpgIAATX4AgAAVk0A= Date: Thu, 12 Mar 2015 19:25:23 +0000 Message-ID: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:0:e50:1001:d4b0:f5e:a801:38ec] authentication-results: delong.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(479174004)(24454002)(377454003)(51704005)(92566002)(90282001)(2656002)(19580395003)(19580405001)(2900100001)(2950100001)(86362001)(87936001)(74316001)(77156002)(54356999)(76176999)(93886004)(89122001)(106116001)(102836002)(15975445007)(77096005)(40100003)(46102003)(62966003)(75432002)(33656002)(50986999)(88552001)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001009); SRVR:CO2PR04MB587; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB587; x-forefront-prvs: 05134F8B4F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 19:25:23.2211 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB587 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 12 Mar 2015 19:25:53 -0000 I don't understand this discussion. I thought the topic was a terminology= discussion about whether to use the term "un-numbered" when referring to a= n interface that only has a link-local address. Traceroute should work with link-local addresses, but only when you target = a link-local address. (It won't go off link, so either that address is a neighbor or it is not re= achable, and traceroute probably reflects that already.) Same thing with ULA. If you actually use the ULA in the traceroute command= or it's in the route, then I would think it already shows up. If not, you aren't going to see it. To me, the term "un-numbered" doesn't make much sense because the interface= has a link-local address. - Dan > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Owen DeLong > Sent: Thursday, March 12, 2015 12:52 PM > To: Alexandru Petrescu > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >=20 >=20 > > On Mar 12, 2015, at 06:14 , Alexandru Petrescu > wrote: > > > > Le 12/03/2015 14:00, Gert Doering a =E9crit : > >> Hi, > >> > >> On Thu, Mar 12, 2015 at 01:41:33PM +0100, sthaug@nethelp.no wrote: > >>>> But traceroute should be able to report link-local addresses, and > >>>> ULAs, as well. If it doesnt then it's a problem of that traceroute > >>>> program. > >>> Of course traceroute can report them. They are just not very > >>> helpful. > >> > >> While *traceroute* would be able to report anything, no router worth > >> its money should ever send a packet with a LLA source off a link. > > > > Well, a router should not _forward_ such a packet, but it could always > > issue one, why not? > > > > Apps with beaconing semantics, or video stream (no need of reply), may = use > this. > > > >> So you should never see any packets that traceroute could report > >> about. > > > > Traceroute is a diagnostic program. I think you have no RFC that speci= fies > how traceroute acts. > > > > You can write a 'traceroute' program that reports LL addresses, I dont = see a > problem in that. >=20 > Here's the problem. >=20 > Traceroute depends on receiving ICMP HOP_COUNT_EXCEEDED messages with > the hop address embedded in the SRC field of the ICMP datagram. >=20 > If you are running traceroute on a machine that is not adjacent to the ho= p > responding with said message from a LL source address, then you will neve= r > see the packet because NONE of the routers between it and you should > forward said packet to a different interface from the one it arrived on. >=20 > So, traceroute may report whatever it receives, but it CANNOT receive a > packet with a LL Source address from a non-adjacent router unless all of = the > routers in between violate the RFCs regarding forwarding of LL packets. >=20 > >> That is, sort of, what the "local" in "local-scoped" is about, no? > > > > It's local for locally-scoped protocols. But I can very well have a we= b page > telling me all the addresses of a very distant router (many IP hops away)= , > including its link-local addresses. >=20 > Sure, but you'll never get the LL address in your traceroute to look up, = so I > think the web page is moot. >=20 > > LL addresses can be present in payloads w/o problem. >=20 > Yes, but traceroute doesn't use the payload. >=20 > > LL addresses can be present in IPv6 Routing Header. >=20 > Yes, but I'm not sure how that applies here, nor am I sure it is useful f= or them > to appear there. >=20 > > With this at hand a 'traceroute' program can report LL addresses. >=20 > Not the way traceroute programs currently work. I think you would be hard > pressed to create a traceroute program that could do so without modifying > code on virtually every deployed IPv6 router as well. >=20 > Owen >=20 > > > > Alex > > > >> > >> Gert Doering -- NetMaster > >> > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Mar 12 14:16:16 2015 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 5EC021A9148 for ; Thu, 12 Mar 2015 14:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 540_y7fEOhIo for ; Thu, 12 Mar 2015 14:16:12 -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 4DD7C1A913E for ; Thu, 12 Mar 2015 14:16:12 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t2CLG5wZ078710 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 21:16:05 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <55020214.60607@foobar.org> Date: Thu, 12 Mar 2015 21:16:04 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> In-Reply-To: <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 21:16:14 -0000 On 12/03/2015 15:24, Ole Troan wrote: > right. the methodology seems to detect a site/system filtering policy. > for an analogy, try to run those measurements against any of my hosts > inside the Cisco corporate network. you’ll find that all UDP gets > filtered. can you or should you draw any general conclusions from that? > I think not. exactly, which was why the first question I asked about this draft revision was where the measurements were taken from. As you point out, this is critically important. >> 2. if end points on the v6 internet attempt to connects to these >> systems where the packets are configured to use EHs, those connections >> may fail as a direct result of using EHs. > > sure, is that a problem? I'd be inclined to think that if a connection fails due to a mechanism which is or should be invisible to end users (e.g. fragmentation) then yep, that's a problem. >> 3. this appears to be a problem at both the core and edge of the ipv6 >> internet > > I can’t find anything in the draft showing that the core of the Internet > is applying this filtering policy. this was mentioned in the draft: > Secondly, our results indicate that a significant percentage of such > packet drops occur in transit Autonomous Systems. Nick From nobody Thu Mar 12 14:32:01 2015 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 DCB941A92AD for ; Thu, 12 Mar 2015 14:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 RLio2Xo52WHj for ; Thu, 12 Mar 2015 14:31:59 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 4310B1A9143 for ; Thu, 12 Mar 2015 14:31:59 -0700 (PDT) Received: by pabli10 with SMTP id li10so23607580pab.13 for ; Thu, 12 Mar 2015 14:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ygpoDmwJf/KcGbCWoas/k2eW1lJep+kQnAJcZ1FWgkg=; b=0hXwFS0S+mRu8Us+yLfFBAymsGaPHVdfi88xRmxwSXt3xuGicPQ/dq8LOZQhWA5Amh LShrT/qzZ9W9VwY6Zaopql4rxxiSw9HXbVYDr1kTrErrMA1GhoBs9Grv9wCqeFBC5MEh l/m/+liihTe9xKMt8aCLTdiVO7+Pq2ZX7voUzjlVvnTpfw5sAcQUKqFQgYy2zK0Yvq+E e8Tg9ojgqxnfA1WlafQQb/z37tciHKqIV4RaEz7muyHkp59cu3EaVpsTYkYKi8z8Y7oa +3EemaPM8Wwg8QBjDOxdtQaufi+YCZU8tepfek6RhcRz12qA9kC7I2uwKzQjI2SWTCHz RyYA== X-Received: by 10.70.35.193 with SMTP id k1mr82679171pdj.46.1426195918499; Thu, 12 Mar 2015 14:31:58 -0700 (PDT) Received: from ?IPv6:2406:e007:6ea1:1:28cc:dc4c:9703:6781? ([2406:e007:6ea1:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id fi8sm61615pdb.43.2015.03.12.14.31.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 14:31:57 -0700 (PDT) Message-ID: <550205D5.3020504@gmail.com> Date: Fri, 13 Mar 2015 10:32:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nick Hilliard , Ole Troan References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> In-Reply-To: <55020214.60607@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 21:32:01 -0000 On 13/03/2015 10:16, Nick Hilliard wrote: > On 12/03/2015 15:24, Ole Troan wrote: >> right. the methodology seems to detect a site/system filtering policy.= >> for an analogy, try to run those measurements against any of my hosts >> inside the Cisco corporate network. you=E2=80=99ll find that all UDP g= ets >> filtered. can you or should you draw any general conclusions from that= ? >> I think not. >=20 > exactly, which was why the first question I asked about this draft revi= sion > was where the measurements were taken from. As you point out, this is > critically important. >=20 >>> 2. if end points on the v6 internet attempt to connects to these >>> systems where the packets are configured to use EHs, those connection= s >>> may fail as a direct result of using EHs. >> >> sure, is that a problem? >=20 > I'd be inclined to think that if a connection fails due to a mechanism > which is or should be invisible to end users (e.g. fragmentation) then = yep, > that's a problem. Very much so. The reason I got interested in this problem in the first case was the discovery that to use certain extension headers between two experiment-specific servers on the Internet, it was necessary to literally bypass the site firewalls at both ends. And these results show failures not only at the end-AS but also in a noticeable fraction of cases at an intermediate AS. So the choice of servers is a bit beside the point. True, a much more widespread set of tests, probably using dedicated test boxes, would be needed to get a statistically valid assessment. But we already know that there's a widespread pattern of failure. Whether the IETF can do more about this than RFC 7045 is another question entirely. Brian >>> 3. this appears to be a problem at both the core and edge of the ipv6= >>> internet >> >> I can=E2=80=99t find anything in the draft showing that the core of th= e Internet >> is applying this filtering policy. >=20 > this was mentioned in the draft: >=20 >> Secondly, our results indicate that a significant percentage of such >> packet drops occur in transit Autonomous Systems. >=20 > Nick >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Mar 12 14:47:52 2015 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 2742A1A8723 for ; Thu, 12 Mar 2015 14:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 dXZWJqUOribU for ; Thu, 12 Mar 2015 14:47:49 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 CDB961A6FFF for ; Thu, 12 Mar 2015 14:47:49 -0700 (PDT) Received: by pabli10 with SMTP id li10so23839149pab.2 for ; Thu, 12 Mar 2015 14:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=w00ewRjqJMNb8WpM3wvEdLOU0tb2klYntUo5FSyAswM=; b=tMljiZg1v86QYz2PPZuxiIPiH+1CXGP+czsuYf6y1V3objySCwzHXB4mlsZZuuN3oG dSLN+dG5Oyzdt5l6V3xztDZOcQvS4r6rCz900Wd7rI6atJ3Y/QaownZk+tXB5mxehm9r 832xvCyW4LGHQNcaSukGcArOffPXntPnI0Bl5Znd/an8nxFKRa7d18Q6DU3LwFjcpTkS ryHn86cnQnHEz12aJnLhf/5y6KipRV8jSqSgqYhqbdpX2dbchrv7T5buTsIzuESMMqE9 grAzSlgvrjwh6rEOE5nXFu9yvMMY8UMRV4t1IHybilhjj9Mi4S1CJWgrhE+ygvURqMLp CWiA== X-Received: by 10.66.224.164 with SMTP id rd4mr93675553pac.12.1426196868785; Thu, 12 Mar 2015 14:47:48 -0700 (PDT) Received: from ?IPv6:2406:e007:6ea1:1:28cc:dc4c:9703:6781? ([2406:e007:6ea1:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id a6sm73469pdn.93.2015.03.12.14.47.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 14:47:47 -0700 (PDT) Message-ID: <55020987.1080705@gmail.com> Date: Fri, 13 Mar 2015 10:47:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alexandru Petrescu , Gert Doering , sthaug@nethelp.no References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> In-Reply-To: <5501914D.8060604@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] What about the word "local" don't you understand [Should we use "unnumbered" in IPv6?] 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, 12 Mar 2015 21:47:51 -0000 Alex, On 13/03/2015 02:14, Alexandru Petrescu wrote: > Le 12/03/2015 14:00, Gert Doering a =C3=A9crit : =2E.. >> That is, sort of, what the "local" in "local-scoped" is about, no? >=20 > It's local for locally-scoped protocols. But I can very well have a we= b page telling me all the addresses of a very distant > router (many IP hops away), including its link-local addresses. Theoretically, such a thing could exist, but I can't imagine any ISP that cares about protecting its infrastructure from bad actors doing such a thing. > LL addresses can be present in payloads w/o problem. They are explicitly meaniningless off the link. With a Zone ID attached, they are explicitly meaningless off the host. So putting them in a payload is almost always problematic. (And yes, I'm aware of the problem for CUPS caused by RFC6874.) > LL addresses can be present in IPv6 Routing Header. Indeed; I am contemplating whether it's worth a draft specifically forbidding this. > With this at hand a 'traceroute' program can report LL addresses. It can, and they are useless. Brian From nobody Thu Mar 12 15:08:37 2015 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 875911A6FFA for ; Thu, 12 Mar 2015 15:08:35 -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 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 x0WM2xIjbRhT for ; Thu, 12 Mar 2015 15:08:34 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F781A009B for ; Thu, 12 Mar 2015 15:08:34 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 6D5FA6198; Thu, 12 Mar 2015 15:08:32 -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=pls2cBgcbO8oOdxMuUZz4EJia8g=; b= eIPOtqfiT1egtFnTFwIyGL8aijlOW4qvTDmFAwAWdwcUi2hlFXuRd7hUbEG7Fz61 jiff4cAW86Up4OXch88pMa4zFHSySiKY8RsOtK6zC5oxYVgNaiNShJAESiiP1+WY fJA2Mub5ArPYvHQAWngq8onPJdjb6+ddSDlmCkObNvM= 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=N227rryJwn9DGmBtL1xEcQJQ1o HeBsUJwT/aYCjs7GdgCbbviFXWb8IiOZlkKb3Ao0xUj89jNEWen9A6F3wsK+cPHY cBotOYAnA2HJDbLuU+9cy/bYLrVHXcWlIsuf/Us75fZ4Gb07yr+LmIP/eEjRqRBB ALdZ+rQQkUTHKkXAo= Received: from gomlefisk.localdomain (unknown [195.159.234.46]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 0A4306192; Thu, 12 Mar 2015 15:08:32 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 8796040AEFA1; Thu, 12 Mar 2015 23:08:34 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7098F2DD-28AF-4A45-8C1B-E9E29A960D01"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <550205D5.3020504@gmail.com> Date: Thu, 12 Mar 2015 23:08:33 +0100 Message-Id: <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2087) Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 22:08:35 -0000 --Apple-Mail=_7098F2DD-28AF-4A45-8C1B-E9E29A960D01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>=20 >> I'd be inclined to think that if a connection fails due to a = mechanism >> which is or should be invisible to end users (e.g. fragmentation) = then yep, >> that's a problem. >=20 > Very much so. The reason I got interested in this problem in the first > case was the discovery that to use certain extension headers between > two experiment-specific servers on the Internet, it was necessary to > literally bypass the site firewalls at both ends. And these results = show ^^^^^^^^^^^^ well, there=E2=80=99s your problem. > failures not only at the end-AS but also in a noticeable fraction > of cases at an intermediate AS. So the choice of servers is a bit = beside > the point. that=E2=80=99s a more interesting case. with a relatively large = uncertainty. presumably we could take some of these paths from the data set and ask = the suspected dropping providers what=E2=80=99s going on? >=20 > True, a much more widespread set of tests, probably using dedicated > test boxes, would be needed to get a statistically valid assessment. > But we already know that there's a widespread pattern of failure. I think it has to be shown that this isn=E2=80=99t end-AS firewall = policy. >=20 > Whether the IETF can do more about this than RFC 7045 is another > question entirely. apart from dropping HBH I would be quite surprised if there were any = transit AS operators thinking that filtering fragments was acceptable = for a functioning Internet. let=E2=80=99s get some more real data on = what=E2=80=99s really going on. cheers, Ole --Apple-Mail=_7098F2DD-28AF-4A45-8C1B-E9E29A960D01 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 iQEcBAEBCgAGBQJVAg5iAAoJEFuJXizso86gz1IH/2Ezx+juh1CAIsCLXN+fldne tKlJPNjn/8PWdL9/kSx48WEazCkczAUxXPK87XjVeaypyxRZCLvOd1+5I4P0pXax UtHavJGzHz2mBZXBqi0s0T1QaHkssEJsRi3ZnwmjIzZbZNp1v56gtznSBRY4iXtK +WyRcN0wXcbA1BmpnrfI7EfFNt7okjlPVxO8zZs8Cbr2LyWsAwavuSsURBKVFVUB Jrgb+k4fK1kpD8UCWOU3MN8zuSVEs1sKzyZty+4vsj2YL4CRizB/w/PJ4H0VP19z 7otqpjGAwHwXVtiC3XflwQP+FfZIE/mL0pM5s0gIYPxNstlRIAuaOzVxI+c5y40= =Y4hP -----END PGP SIGNATURE----- --Apple-Mail=_7098F2DD-28AF-4A45-8C1B-E9E29A960D01-- From nobody Thu Mar 12 15:27:39 2015 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 72ECD1A8837 for ; Thu, 12 Mar 2015 15:27:38 -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 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 wY4Z18moRjSu for ; Thu, 12 Mar 2015 15:27:34 -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 5C8301A87BE for ; Thu, 12 Mar 2015 15:27:34 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t2CMRPRw080403 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 22:27:27 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <550212CB.2090306@foobar.org> Date: Thu, 12 Mar 2015 22:27:23 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan , Brian E Carpenter References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> In-Reply-To: <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 22:27:38 -0000 On 12/03/2015 22:08, Ole Troan wrote: > I think it has to be shown that this isn’t end-AS firewall policy. as it stands, I'm happy that there is enough data in the draft to show that this isn't solely an edge problem. > I would be quite surprised if there were any transit AS operators > thinking that filtering fragments was acceptable for a functioning > Internet. transit operators have been doing this for years. One reason they might do it is CoPP limitations on the PFC3 supervisor card on the c6500/7600 platform. Although this kit is well past its useful lifetime, there are lots of these boxes in operation on many networks, including many of the well-known "tier 1" transit operators. Nick From nobody Thu Mar 12 15:35:10 2015 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 3969A1A87AE for ; Thu, 12 Mar 2015 15:35:09 -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 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 hV5mFFUQXiPE for ; Thu, 12 Mar 2015 15:35:08 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5DD51A878E for ; Thu, 12 Mar 2015 15:35:07 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id A29006312; Thu, 12 Mar 2015 15:35: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=AkpYP9czDXLWNs6bUudZyih+C1I=; b= LpDfq9BCm07R+97WP0EWIBkYPRChDCBxPx/XbtkvYEg9JWRQ+nvTmeUnkPVnnb77 pIw+2TvK8hnZynLjZAV9Y8KaP7+LHivEdKdbTBSh3BQb9Id1LGkefGDklP7MqGv+ 7sJZeebpVvbi0gGG5vo80dt0g1M/Zm9mtIx1p0S5i2A= 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=CcLT4GckDKs7kYavRnQDqms85W rCCur22GXYAStQa1lgzgrqVwkv7oxWi3R25jFoTlnmogxEeiPkejCfz/l0Iie0Yo owPMlFxgFx4w/aosFD9vfLBY7mnzwuEh9W9f3LqObAnAO00C/89ZP9NnNibOZV/c pNHL82M8WoFy9rNDg= Received: from gomlefisk.localdomain (unknown [195.159.234.46]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 1D3156310; Thu, 12 Mar 2015 15:35:06 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 2B6CD40AF831; Thu, 12 Mar 2015 23:35:08 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_08727086-A70C-4944-A00F-90BD01A12BA0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <550212CB.2090306@foobar.org> Date: Thu, 12 Mar 2015 23:35:07 +0100 Message-Id: References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <550212CB.2090306@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.2087) Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 22:35:09 -0000 --Apple-Mail=_08727086-A70C-4944-A00F-90BD01A12BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Nick, >> I think it has to be shown that this isn=E2=80=99t end-AS firewall = policy. >=20 > as it stands, I'm happy that there is enough data in the draft to show = that > this isn't solely an edge problem. >=20 >> I would be quite surprised if there were any transit AS operators >> thinking that filtering fragments was acceptable for a functioning >> Internet. >=20 > transit operators have been doing this for years. One reason they = might do > it is CoPP limitations on the PFC3 supervisor card on the c6500/7600 > platform. Although this kit is well past its useful lifetime, there = are > lots of these boxes in operation on many networks, including many of = the > well-known "tier 1" transit operators. yes, so that example would definitely be in the = misconfiguration/software/hardware bug category. cheers, Ole --Apple-Mail=_08727086-A70C-4944-A00F-90BD01A12BA0 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 iQEcBAEBCgAGBQJVAhSbAAoJEFuJXizso86gq1YH+warOHT3v3WF7IK9qbn1n8Wa OfUT1IwtQADK2+aQie93OFa5/yiXRmoLOzSv9UOykbnND+o+gQIJBsTP9mn6ubwv eOlVq8CRXdF0OvJqesazCNDylZaq6jowIR7rHNA2NqT262Jg7+M6dsUq7nVqUcgY Pr7xAURNncGQRTqHDbuDHuESyv13pP6szGfm01eVmcttPW3EWRBiP1qhmD5StX+9 tvaTfnO60PitXFw5amUox16E8S7bpUHOcVAHaGEqQ6VzZYVXLwUO6hMd5TGlN/E3 UOVDnLnVOVReyDvyNFJbgLBEEf6LlCDcamcKqz1+hLK0W8DB06CTwH5jEWiB00E= =5lRO -----END PGP SIGNATURE----- --Apple-Mail=_08727086-A70C-4944-A00F-90BD01A12BA0-- From nobody Thu Mar 12 15:42:09 2015 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 3F00A1A8826 for ; Thu, 12 Mar 2015 15:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 CDuXe694DjgE for ; Thu, 12 Mar 2015 15:42:05 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::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 4E6971A87E9 for ; Thu, 12 Mar 2015 15:42:05 -0700 (PDT) Received: by pdbfl12 with SMTP id fl12so23572589pdb.9 for ; Thu, 12 Mar 2015 15:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W5iSv7fflTNxMqA3YVQlBLI6/o99k7D/IcSbcGk2dvY=; b=mbF0bdfBHFCaNoxDt7i1BN9k7D46LUtMwTQaXKH6tMu49G2M0/Hnpc7dRykic1Nuj/ mzmUB7gN6qYnjOA6h2sOqbNucf9BCggMnfVhNr/clHBYdwAzvaSMO3+Ry0N0fqhYfQ54 F0G/Ut5tTzIy6+1+X5uAIx2md1Oo/oekwjQeD5RA5fodVwiGmcaxd23f7o0CiLtxeE/N LH7qfkqgVJLob2EEqK9WyrGFiWO1IEO7f7Ttw6BZWvrGC5+IO3xTEdNDnlPYiOptMuWZ kZTUdZS8JYWmrEeJaNRKBo1gjih0yzcP4g//Nls7Bf4KHFwZ7w75Qgc0lRgxb+ZaV5RJ 1IDw== X-Received: by 10.66.63.106 with SMTP id f10mr95485491pas.0.1426200124945; Thu, 12 Mar 2015 15:42:04 -0700 (PDT) Received: from ?IPv6:2406:e007:6ea1:1:28cc:dc4c:9703:6781? ([2406:e007:6ea1:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id w1sm194645pdp.25.2015.03.12.15.42.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 15:42:03 -0700 (PDT) Message-ID: <55021642.2070900@gmail.com> Date: Fri, 13 Mar 2015 11:42:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nick Hilliard , Ole Troan References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <550212CB.2090306@foobar.org> In-Reply-To: <550212CB.2090306@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 22:42:07 -0000 On 13/03/2015 11:27, Nick Hilliard wrote: > On 12/03/2015 22:08, Ole Troan wrote: >> I think it has to be shown that this isn=E2=80=99t end-AS firewall pol= icy. And/or load balancers that barf on extension headers. I agree that end-AS middleboxes are a large part of the problem (but see Nick's point below). Brian >=20 > as it stands, I'm happy that there is enough data in the draft to show = that > this isn't solely an edge problem. >=20 >> I would be quite surprised if there were any transit AS operators >> thinking that filtering fragments was acceptable for a functioning >> Internet. >=20 > transit operators have been doing this for years. One reason they migh= t do > it is CoPP limitations on the PFC3 supervisor card on the c6500/7600 > platform. Although this kit is well past its useful lifetime, there ar= e > lots of these boxes in operation on many networks, including many of th= e > well-known "tier 1" transit operators. >=20 > Nick >=20 >=20 From nobody Thu Mar 12 15:52:21 2015 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 0C5461A0199 for ; Thu, 12 Mar 2015 15:52:20 -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 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 HIT1PAco335v for ; Thu, 12 Mar 2015 15:52:18 -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 4C1A31A0046 for ; Thu, 12 Mar 2015 15:52:18 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t2CMqCs7080906 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 22:52:13 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <55021899.7080908@foobar.org> Date: Thu, 12 Mar 2015 22:52:09 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <550212CB.2090306@foobar.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 12 Mar 2015 22:52:20 -0000 On 12/03/2015 22:35, Ole Troan wrote: > yes, so that example would definitely be in the > misconfiguration/software/hardware bug category. If this is the best approach we can close down this discussion on the spot and declare the entire issue to be a problem relating to misconfiguration, bugs or both. The standards are clear on the requirement to support IPv6 EHs so if operators / vendors aren't following it properly then surely that's out of scope for the IETF? Or we could acknowledge that there is a problem, look into the causes and see if it's worth doing something about it with a view to fixing it in the long term. I'm inclined to think that the latter is a more sensible approach. Nick From nobody Thu Mar 12 16:39:00 2015 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 643CB1A884B for ; Thu, 12 Mar 2015 16:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[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_REPLYTO=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 XnW-3hgEEbYh for ; Thu, 12 Mar 2015 16:38:55 -0700 (PDT) Received: from nm28-vm1.bullet.mail.bf1.yahoo.com (nm28-vm1.bullet.mail.bf1.yahoo.com [98.139.212.252]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06E71A8842 for ; Thu, 12 Mar 2015 16:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1426203534; bh=Ajf1g91rkTukkeM7if6h7WoVx0O2zXJgLRJL/bscZ2M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=l30h3/3QiroTMsmI1QI4vB4mz5g2/7GKwHO0Wxl6KoPW5cG7DOvQeoRIoEBA7lQRtxVSQT4JcHlEyC0shvjUHUB+NjF1ezR2XTqsEw87iq7ALU2FF5CB7VRhkB2Ry6jQMwfwx10ikeBT2xaM2g0WXuKUJPMVwNCSFb1A44zx7UZwph1iPSTYY/YUJEGSvyROsNSzmVTCBPUdYuQG6Dk8tWlAdMAYXxkvPqPm8L2/MQCAk3D8TI07Qv3fiZT1XQG4kCyHYirqF5JdvCTwQdGnGnHWr19iKowSMi494lMsUz8XhbHynXH1J8kdGIW2ejWquavq/V2cUyrYyk5EAsteLA== Received: from [66.196.81.174] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:38:54 -0000 Received: from [98.139.212.204] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:38:54 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:38:54 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 69599.91311.bm@omp1013.mail.bf1.yahoo.com X-YMail-OSG: mMchQx0VM1m5mvdurdNU1Tkd..4RvTlMxHsTPCJVvHOkiyq7bNX.noPzP_m0697 K7OBtz_vq_eVPwyTUO9.I0bxH94Noc2OhFczbCHxjz2lU7mtEIRlAUaZYttvCvgoV77OXEiJ2zFm fAg.upR1.Vbdwfmio9XIwcaCvHkhq8lHDg6x4YYcEM.WkqHbUTv0l5LjnYmSbpCN1LePE9YYvM0g AwHAvPBN4ZsshfTK1jYX9hDsCb5Tb.Xg.m84BOBm9RWGGZ52wwz4AxDyCvDz_kXRBE6P9xkzU5Xr xiINKUu934zzB.92ycuF7Npd6zh0Z1CroQIkbD.Imb9bwh1mWH5WEo8vM2WS2Fg1tcRz65N5n5LG RbnmGdtafLV3GDXyHdk38xAV8Jg1H8pDnO9L2HE604qzzh8JBsucuS8uWL05nzGO_GN3Jka2sTHa 5Wd_bmSykLG9qQmRVdTiBYZYRGW.7ZqBekr9O_qD1f2OrAj.p79DR8cSIrLkXAxLWqNxp8dCcT7W eceGWzQvlfgv3qPTQxbZYgo7Md_tbMIQRKCGz5rdlD3opA2U- Received: by 76.13.26.108; Thu, 12 Mar 2015 23:38:53 +0000 Date: Thu, 12 Mar 2015 23:38:53 +0000 (UTC) From: Mark ZZZ Smith To: Erik Kline , Falcon Darkstar Momot Message-ID: <1866443558.5357791.1426203533181.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5357790_82030405.1426203533177" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 23:38:59 -0000 ------=_Part_5357790_82030405.1426203533177 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I'd also think 'locally-numbered' doesn't have enough clarity, because it could sound general enough that it covers/describes Unique Local Addressing. I think "link-local only" is the most accurate description e.g. "link-local only links", "link-local only addressing". From: Erik Kline To: Falcon Darkstar Momot Cc: "v6ops@ietf.org" Sent: Wednesday, 11 March 2015, 18:51 Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? > I put forth the term "locally-numbered" as a succinct and apropos > alternative. I was thinking about that as well, but dropped it on the assumption that if the context were mistaken in conversation to be IPv4 (or we wanted a common term for both) that locally-numbered might be interpreted as "has RFC1918 addresses". (Sorry, I really don't want to take us down the road of the "hextet" discussion. :-) _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_5357790_82030405.1426203533177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd = also think 'locally-numbered' doesn't have enough clarity, because it could= sound general enough that it covers/describes Unique Local Addressing.
I th= ink "link-local only" is the most accurate description e.g. "link-local onl= y links", "link-local only addressing".

From: Erik Kline <ek@google.com>
To: Falcon Darkstar Momot <falcon@iridiumlinux.org> =
Cc: "v6ops@ietf.org" &= lt;v6ops@ietf.org>
Sent: Wednesday, 11 March 2015, 18:51
Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?

> I put forth the term "locally-numbered" as a succinc= t and apropos
> alternative.

I was thinking about that as well, but dropped it on the assump= tion
that if the context were mistaken in conversation to= be IPv4 (or we
wanted a common term for both) that local= ly-numbered might be
interpreted as "has RFC1918 addresse= s".

(Sorry, I really don't want to tak= e us down the road of the "hextet"
discussion. :-)




_____________________________= __________________
v6ops mailing list
<= a shape=3D"rect" ymailto=3D"mailto:v6ops@ietf.org" href=3D"mailto:v6ops@iet= f.org" id=3D"yui_3_16_0_1_1426203005725_11177">v6ops@ietf.org
https://www= .ietf.org/mailman/listinfo/v6ops


=
------=_Part_5357790_82030405.1426203533177-- From nobody Thu Mar 12 16:44:00 2015 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 7F3691A8847 for ; Thu, 12 Mar 2015 16:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] 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 NJCatgbm8SJV for ; Thu, 12 Mar 2015 16:43:57 -0700 (PDT) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5CF1A882A for ; Thu, 12 Mar 2015 16:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1426203836; bh=gI42TOEXsQ1QyEzBVbqFGrDaom2BXpGi+u/AMXl3wGM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=hI544HTDlE1zHFLXY9itxI+hmQhTXAo6N6t8WoPP7Q5tzwWQ2xZFxAU/9qXCG2RcBTrEsDmT11+ipE3KbQ1CM78cNgPUksbdkyTuJpTKGXc6yVtXmXtRTR1ftXK9P/jP8DxrszC8irjxKaT/nrgS+QaKPRo+uRFNdKXFEiZZFjO2EAZjH6dB9+Tj+6Y5jjlWim+nuYWwhFoAranuVe0fMvu/Cu6vTYT0c5OpU9qINYqOkOyeFh9ClGwThyPBkdM3HlTRbW/WUCOovfkc/gGwyPmxkwpX+ukJ7HXQRp6BvgFAswwxcUmxAleugXu4K9usH/uTIccrEY1CEP/MmIWVCQ== Received: from [98.139.215.141] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:43:56 -0000 Received: from [98.139.212.237] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:43:56 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:43:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 522323.177.bm@omp1046.mail.bf1.yahoo.com X-YMail-OSG: PnaPFB0VM1nr209G9LkOoAqnIh_GBRsTJf4sZVzMI.gJsn4aRoVsz_G87IlPzpu hDQ.gk0_rq55pybOTZmgjUX3.2VLVSdosrmHRFObn0taoU4si5FRjAhkSBWYuSSijEOVW9ZYeo5n Yyp6X9beq8p5CGRAL63N93fnC3.qKljayEshZSjQHgUF1uj9Ua82ZRIF08H3f0jqd7fEXLjViOKw LSG2kwQVE569886aF2uxoT3fFtb0RnhJQYrG7txsOlurOwfG2NZ8zo1NZjZdnLbRbsI8Wi9J5zYz v1qVUiYZChBF0WtlJDnIeakUfY1Y7.trfWZxVW9CkrCioT.LNWYTM8t38jFXMsiv7TOzOleRNH7h DXScv2ENxtAXOqk1fmy2dt55yYyBSmqkwrUuh6k9ZfOHP3r5W4vyJ8vy5ZDiKUbbzZS_vt3.INMf MINa1dnuxie51In8cWZP9xhREHQqZdubPiQW2.zrO.lSZY3Mr_4mBOFQSTVpaapdih9xb_8eQ4yr fnsBSZ72z0wPt6VjrYdRbJuyRFeYo44viRKr8avBfJoDwxW52.VpCEs.Z_1EiOuVN8P3EPMUb1WY EbtXnsSQgwxHLE8mvWrk_1s9z Received: by 66.196.80.193; Thu, 12 Mar 2015 23:43:56 +0000 Date: Thu, 12 Mar 2015 23:43:55 +0000 (UTC) From: Mark ZZZ Smith To: Nick Hilliard , Gert Doering Message-ID: <643679624.44423.1426203835721.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <550020EC.1080907@foobar.org> References: <550020EC.1080907@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 23:43:58 -0000 If you don't ensure clarity and accuracy, simple misunderstandings can have catastrophic consequences : "NASA's metric confusion caused Mars orbiter loss - September 30, 1999" http://edition.cnn.com/TECH/space/9909/30/mars.metric/ ________________________________ From: Nick Hilliard To: Gert Doering Cc: "v6ops@ietf.org" Sent: Wednesday, 11 March 2015, 22:03 Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? On 11/03/2015 10:14, Gert Doering wrote: > On Wed, Mar 11, 2015 at 04:51:31PM +0900, Erik Kline wrote: >> (Sorry, I really don't want to take us down the road of the "hextet" >> discussion. :-) > > We're already on the way... expecting a long linguistic treaty next. As we've only had 23 emails so far on this topic, I'm going to chip in my 2 eurocents: namely, whatever is chosen, I politely suggest that we put some html color tags in the draft to let posterity know how important this topic is, and how seriously it was considered by the WG. Also, the tags should be red (#ff0000) to attract the appropriate level of attention. We all understand it would be a mistake to let this issue be quietly resolved without serious discussion, so it's only reasonable to make future RFC readers aware of our heroic efforts to do what's best for them. Nick _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Mar 12 16:54:40 2015 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 A91001A8850 for ; Thu, 12 Mar 2015 16:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] 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 6J7mXIRT2KPY for ; Thu, 12 Mar 2015 16:54:33 -0700 (PDT) Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C8A1A884B for ; Thu, 12 Mar 2015 16:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1426204472; bh=lhv4ftK1sb4bPakBdo7PTD35iCZaMGgUhVC1jQ9d3ds=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=MkA/0yF4DzQxu4bIhFPimw//bPGsKx9UJitrxSs+6HfMw/dPelyeSKXJLDoUdpubxUQoD1So4rdZtXzyEQtBARuFpdB/3q2sGryl4HzIMjns4+l94GosxWkWlb3hHBxolWU2Sx+DsAx9D7ajI9F8SzERt3XvX1v9sposqoGr4NVVU/HDckOmXfoQFlAR8b/iJ7UFXVVhBWfdBr5l3Af5nsvEOQP4zd8B0HM3wHW43T/ZzYLN4HJNpUWUXn0o6o54i92JrwsYsQ9HPvJ/5ozAz2faPOFMA1ylBEl4IwEjnyT934ULNL+WMmh2mtBCQIN1W+qaZEk9+P7C9q8mBEXa0w== Received: from [98.139.214.32] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:54:32 -0000 Received: from [98.139.212.235] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:54:32 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 23:54:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 741238.31135.bm@omp1044.mail.bf1.yahoo.com X-YMail-OSG: Q_Kvy0kVM1lPJy7Mz_JTOTJUw4ViwU8_J0sDaR4BMqVFdEdM2hqiUlIIGAId0PZ 23JTq5BR9MkzAshTPR6T_QFQ.YDwh6JgpuH0.Y1JMH.XfbJvB0zLzdj37mwbVcCNd00bcM7IjPlU 74ChU58_wO3EKDW1Pjvtkdm6PRkDSLvPvtgn_mC7wa2phQiguP2M0xPIs2MkTtH_G5vG77Mzdh9o 9LvNv4W5vbBz0snyAEBLsKEdyTA1LoXHZa_snFPtSVTIiJwSNiYnp8kRMwCPjKLkwgSHA7rr3uSy b_A.yoX9oRbYaki86MW5enJzshADGTku2HXUxZt4mijVl6ch4bhLP6AhpNUoAyoU2RoN15XkOrcA tRmYnEMYXPsb0sgUxAyrTtJBamxD26mwszutXEwLuIJi_o7OG2RYaLZdd4_g8yxJ5XR5wltfDf05 tOYdKuRvRPtYu53SVnEgts2PYd6CYA9XCTR7bjCpfuIJEmbBBKTir6Mb9ifjIq8u3dnVpRsJxfH4 HLTKvk8Ug6llm8F_pAG5orVPoOVo8jno0GxiwcYueO5fjXBtNUg-- Received: by 66.196.81.107; Thu, 12 Mar 2015 23:54:32 +0000 Date: Thu, 12 Mar 2015 23:54:12 +0000 (UTC) From: Mark ZZZ Smith To: "sthaug@nethelp.no" , "alexandru.petrescu@gmail.com" Message-ID: <18365446.5344355.1426204452708.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150312.134133.74704744.sthaug@nethelp.no> References: <20150312.134133.74704744.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 23:54:37 -0000 ----- Original Message ----- From: "sthaug@nethelp.no" To: alexandru.petrescu@gmail.com Cc: v6ops@ietf.org Sent: Thursday, 12 March 2015, 23:41 Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? > YEs, we want traceroute to report an address of a hop, rather than a > three-star string "* * *". > > But traceroute should be able to report link-local addresses, and ULAs, > as well. If it doesnt then it's a problem of that traceroute program. Of course traceroute can report them. They are just not very helpful. > If an enduser needs rather globally-scoped and unique (rathern than LL > and ULA) addresses in traceroute outputs then one should ask her why? > Be them globally-scoped and unique they dont tell anything useful to a > human user of traceroute. They surely dont tell _where_ these addresses > are (like in 'what country'). Getting globally-scoped and unique addresses in the answer is a very important part of what I use traceroute for. I strongly disagree with the claim that "they dont tell anything useful to a human user of traceroute". In most cases it is the PTR lookups for these addresses that actually have the most interesting information - but not always. The IP addresses themselves are also interesting, and can be used for further rounds of traceroute, for instance. They can also be looked up through the various RIRs etc. > Besides, traceroute output is hugely more meaningful when it does not > display addresses but FQDNs. These FQDNs have nothing to do with > address scope either. Surely they do. I cannot get a meaningful PTR lookup for a link-local address. I *can* in many cases get a meaningful PTR lookup for a globally-scoped address. / Actually, as LLs have 64 bit IIDs, you could create network wide unique LL IIDs for all of your router interfaces such that PTRs for them would be unambiguous. A forward AAAA for the PTR answer could then provide the OAM loopback for ssh etc. purposes. / I would normally avoid link-local only links in a network, however if I was in a situation where they would be the best choice, then I'd doing things to make them more usable such as creating network wide unique LL IIDs. Steinar Haug, AS 2116 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Mar 13 02:36:55 2015 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 5EB1D1A1B67 for ; Fri, 13 Mar 2015 02:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] 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 WQv8G__ttMZs for ; Fri, 13 Mar 2015 02:36:51 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836C11A1B99 for ; Fri, 13 Mar 2015 02:36:51 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=48231 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YWM1N-0005Zj-OY; Fri, 13 Mar 2015 10:36:45 +0100 Date: Fri, 13 Mar 2015 10:36:15 +0100 From: Tore Anderson To: draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org Message-ID: <20150313103615.1380aeb1@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org, jool@nic.mx Subject: [v6ops] Stateful NAT64: Strange translation of ICMPv4 error source addresses 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: Fri, 13 Mar 2015 09:36:54 -0000 tl;dr: Stateful NAT64 (RFC6146) requires that whenever an ICMPv4 error is received from a router in the IPv4 network, the (IPv4-converted) IPv6 source address of the translated ICMPv6 error must be set to the (IPv4-converted) address of the destination address in the embedded ICMPv4 payload, i.e., the original destination of the packet causing the ICMPv4 error. I find this rather counter-intuitive - I would expect the (IPv4-converted) address of the IPv4 router originating the ICMPv4 error to be used instead. Is my reading of RFC6146 faulty, or if not, is this truly the intented behaviour (why?), or is an erratum warranted? How does actual Stateful NAT64 implementations behave? [Cc: v6ops] Longer version: While testing Jool, an implementation of Stateful NAT64, I noticed that traceroutes started from the IPv6 network towards IPv4 destinations were looking decidedly odd. Some traceroute programs (e.g., mtr) would report that any traceroute target (including definitively unreachable destinations such as a martian) would be shown as successfully reached on the hop immediately after the Stateful NAT64 router, while others (e.g., tracroute6) would report each hop beyond the Stateful NAT64 as having the same address of the traceroute target. Examples of these odd traceroute outputs can be found in the bug report I submitted about this error: https://github.com/NICMx/NAT64/issues/132 It turns out that first class of traceroute programs considers any [ICMPv6] packet received, including "time exceeded" errors, originating from the targeted address as a overall success. The second class of traceroute programs will on the other hand continue to transmit packets with an increasing Hop Limit until a non-ICMPv6 error (ICMPv6 echo-request, TCP SYN/ACK, etc. depending on type of traceroute) has been receeived from the target. After closer reading of RFC6146, both the Jool developers and I agree that it appears that Jool is not buggy, as it faithfully implements the algorithm in RFC6146. See below of a walk-through of our understanding of the algorithm. However the resulting outcome makes absolutely no sense from an operational point of view; I'd expect the IPv4 hops to be represented using their IPv4-converted IPv6 address, in other words by having the RFC6052 translation prefix prepended. This would have the added benefit of causing the correct hostnames for each hop to be reported if DNS64 is in use. Towards the end of the initial message of the Github issue there is an example traceroute output that looks more like what I'd expect, but on the other hand that's not using a true Stateful NAT64 (RFC6146) implementation, but rather the bastard child of TAYGA (a SIIT-ish IPv4/IPv6 translator) plus NAPT44 (Linux IPTables), which might explain that its outcome isn't RFC6146 compliant. Walkthrough of Stateful NAT64 processing, re-using the example addresses used in section 1.2.2 of RFC6146: 1) A TCP packet is sent from 2001:db8::1,1500 towards 64:ff9b::192.0.2.1,80 through a Stateful NAT64 (whose IPv4 address is 203.0.113.1). The NAT64 picks an available source port (2000) and saves the following mapping: (2001:db8::1,1500) <--> (203.0.113.1,2000) The resulting translated IPv4 packet gets the following addresses: Src: 203.0.113.1,2000 Dst: 192.0.2.1,80 2) This packet ends up being discarded by the IPv4 router 198.51.100.1 for some reason (say, TTL exceeded). It originates an ICMPv4 error packet that looks like this: Src: 198.51.100.1 Dst: 203.0.113.1 Src embedded in ICMPv4 payload: 203.0.113.1,2000 Dst embedded in ICMPv4 payload: 192.0.2.1,80 3) Upon receipt of the ICMPv4 error packet, the NAT64 determines an "Incoming Tuple" according to section 3.4: > If the incoming IP packet contains a complete (un-fragmented) ICMP > error message containing a UDP or a TCP packet, then the incoming > 5-tuple is computed by extracting the appropriate fields from the IP > packet embedded inside the ICMP error message. However, the role of > source and destination is swapped when doing this: the embedded > source IP address becomes the destination IP address in the incoming > 5-tuple, the embedded source port becomes the destination port in the > incoming 5-tuple, etc. Thus, now we have a complete Incoming Tuple, containing the following: SrcIP: 192.0.2.1 SrcPort: 80 DstIP: 203.0.113.1 DstPort: 2000 Protocol: 6 (TCP) Note that at this point the IPv4 source address of the IPv4 router originating the ICMPv4 error (198.51.100.1) is already lost, but I'll complete the walkthrough for completeness anyway... 4) The NAT64 proceeds to compute the "Outgoing Tuple" for this packet, according to section 3.6.1: > The transport protocol in the outgoing 5-tuple is always the same as > that in the incoming 5-tuple. When translating from IPv4 ICMP to > IPv6 ICMP, the protocol number in the last next header field in the > protocol chain is set to 58 (IPv6-ICMP). These two sentences do seem to me to contradict each other, but my assumption is the latter sentences are to be understood as an exception to the first sentence (otherwise the Protocol of the Outgoing Tuple ends up being TCP, which would make zero sense). Thus the Outgoing Tuple at this point contains: Protocol: 58 (IPv6-ICMP) > When translating in the IPv4 --> IPv6 direction, let the source and > destination transport addresses in the incoming 5-tuple be (S,s) and > (D,d), respectively. The outgoing source transport address is > computed as follows: In other words, at this point we (temporarily) have: (S,s) =3D (192.0.2.1,80) (D,d) =3D (203.0.113.1,2000) > The outgoing source transport address is generated from S using > the address transformation algorithm described in Section 3.5.4. Section 3.5.4 essentially says =C2=ABsee RFC6052=C2=BB, so: Replacement S =3D 64:ff9b::192.0.2.1 > The BIB table is searched for an entry (X',x) <--> (D,d), and if > one is found, the outgoing destination transport address is set to > (X',x). This lookup will find the entry that was saved in step #1. Thus: Replacement (D,d) =3D (2001:db8::1,1500) So now we have a complete Outgoing Tuple: SrcIP: 64:ff9b::192.0.2.1 SrcPort: 80 DstIP: 2001:db8::1 DstPort: 1500 Protocol: 48 (IPv6-ICMP) 5) The Stateful NAT64 builds an IPv6 packet according to section 3.7: > o When translating an IP header (Sections 4.1 and 5.1 of [RFC6145]), > the source and destination IP address fields are set to the source > and destination IP addresses from the outgoing tuple as determined > in Section 3.6. and > o When the protocol following the IP header is ICMP and it is an > ICMP error message, the source and destination transport addresses > in the embedded packet are set to the destination and source > transport addresses from the outgoing 5-tuple (note the swap of > source and destination). Thus we end up with the final translated ICMPv6 packet: Src: 64:ff9b::192.0.2.1 <-- I'd expect 64:ff9b::198.51.100.1 here! Dst: 2001:db8::1 <-- makes sense Src embedded in ICMPv6 payload: 2001:db8::1,1500 <-- makes sense Dst embedded in ICMPv6 payload: 64:ff9b::192.0.2.1,80 <-- makes sense Tore From nobody Fri Mar 13 03:24:17 2015 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 807611A006F for ; Fri, 13 Mar 2015 03:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fv4gvzRJXzdE for ; Fri, 13 Mar 2015 03:24:08 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id 79E161A0037 for ; Fri, 13 Mar 2015 03:24:08 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 7677A13F42DF; Fri, 13 Mar 2015 04:23:37 -0600 (MDT) X-Spam-ASN: Received: from [10.3.0.145] (mail-02.leviathansecurity.com [173.160.224.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id C2EFF13F428C for ; Fri, 13 Mar 2015 04:23:32 -0600 (MDT) Message-ID: <5502BA88.8020700@iridiumlinux.org> Date: Fri, 13 Mar 2015 03:23:04 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <55020987.1080705@gmail.com> In-Reply-To: <55020987.1080705@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] What about the word "local" don't you understand [Should we use "unnumbered" in IPv6?] 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: Fri, 13 Mar 2015 10:24:14 -0000 On 2015-03-12 14:47, Brian E Carpenter wrote: >> LL addresses can be present in IPv6 Routing Header. > Indeed; I am contemplating whether it's worth a draft specifically > forbidding this. Surely not. However, it does remind me of martian packets a little bit, and maybe a larger draft could consolidate security practices for IPv6, such as filtering packets with ridiculous routing headers such as those where the address might actually be used for routing, inter alia. --Falcon Darkstar Momot --Shadytel From nobody Fri Mar 13 04:05:18 2015 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 D78821A016A for ; Fri, 13 Mar 2015 04:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YiCTVw_dVwUs for ; Fri, 13 Mar 2015 04:05:16 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id 55C971A014B for ; Fri, 13 Mar 2015 04:05:16 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 8EBB314FC2D1; Fri, 13 Mar 2015 05:04:45 -0600 (MDT) X-Spam-ASN: Received: from [10.3.0.145] (mail-02.leviathansecurity.com [173.160.224.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id ABAFA13F428C; Fri, 13 Mar 2015 05:04:43 -0600 (MDT) Message-ID: <5502C44A.8050306@iridiumlinux.org> Date: Fri, 13 Mar 2015 04:04:42 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark ZZZ Smith References: <1866443558.5357791.1426203533181.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1866443558.5357791.1426203533181.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------000304050006000301040202" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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: Fri, 13 Mar 2015 11:05:18 -0000 This is a multi-part message in MIME format. --------------000304050006000301040202 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ok, how about just "link-numbered"? Nobody could confuse that with ULA or RFC1918 or IPv4-style unnumbered links, and it should be intuitive to anyone who knows how IPv6 addresses work. On 2015-03-12 16:38, Mark ZZZ Smith wrote: > I'd also think 'locally-numbered' doesn't have enough clarity, because > it could sound general enough that it covers/describes Unique Local > Addressing. > > I think "link-local only" is the most accurate description e.g. > "link-local only links", "link-local only addressing". > > ------------------------------------------------------------------------ > *From:* Erik Kline > *To:* Falcon Darkstar Momot > *Cc:* "v6ops@ietf.org" > *Sent:* Wednesday, 11 March 2015, 18:51 > *Subject:* Re: [v6ops] Should we use "unnumbered" in IPv6? > > > I put forth the term "locally-numbered" as a succinct and apropos > > alternative. > > I was thinking about that as well, but dropped it on the assumption > that if the context were mistaken in conversation to be IPv4 (or we > wanted a common term for both) that locally-numbered might be > interpreted as "has RFC1918 addresses". > > (Sorry, I really don't want to take us down the road of the "hextet" > discussion. :-) > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --------------000304050006000301040202 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ok, how about just "link-numbered"?  Nobody could confuse that with ULA or RFC1918 or IPv4-style unnumbered links, and it should be intuitive to anyone who knows how IPv6 addresses work.

On 2015-03-12 16:38, Mark ZZZ Smith wrote:
I'd also think 'locally-numbered' doesn't have enough clarity, because it could sound general enough that it covers/describes Unique Local Addressing.

I think "link-local only" is the most accurate description e.g. "link-local only links", "link-local only addressing".

From: Erik Kline <ek@google.com>
To: Falcon Darkstar Momot <falcon@iridiumlinux.org>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Wednesday, 11 March 2015, 18:51
Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?

> I put forth the term "locally-numbered" as a succinct and apropos
> alternative.

I was thinking about that as well, but dropped it on the assumption
that if the context were mistaken in conversation to be IPv4 (or we
wanted a common term for both) that locally-numbered might be
interpreted as "has RFC1918 addresses".

(Sorry, I really don't want to take us down the road of the "hextet"
discussion. :-)




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



--------------000304050006000301040202-- From nobody Fri Mar 13 04:33:38 2015 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 596781A0250 for ; Fri, 13 Mar 2015 04:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_22=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 NvINK6SM2Mig for ; Fri, 13 Mar 2015 04:33:34 -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 1DCBC1A032D for ; Fri, 13 Mar 2015 04:33:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2DBXQ3I031929; Fri, 13 Mar 2015 12:33:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2FE482027F6; Fri, 13 Mar 2015 12:33:52 +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 13A0F202497; Fri, 13 Mar 2015 12:33:52 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2DBX52v009794; Fri, 13 Mar 2015 12:33:26 +0100 Message-ID: <5502CAF1.8070109@gmail.com> Date: Fri, 13 Mar 2015 12:33:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Owen DeLong References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <8A27F909-4176-4F63-830F-D422B17C16AD@delong.com> In-Reply-To: <8A27F909-4176-4F63-830F-D422B17C16AD@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - traceroute is not a reason for mandatory GUA 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: Fri, 13 Mar 2015 11:33:37 -0000 Le 12/03/2015 18:40, Owen DeLong a écrit : > [snip] > >>> >>> I’m not saying interfaces shouldn’t have a link local address. >>> (jeez.) >>> >>> I’m saying that not puting a real address on a link that shows >>> up in traceroutes is a bad idea. >> >> Yes and no. >> >> YEs, we want traceroute to report an address of a hop, rather than >> a three-star string "* * *â€. > > No… We want traceroute to report an address of a hop that has a > valid binding in ip6.arpa that tells people something meaningful > about the hop, and, ideally, the interface of arrival at said hop. > >> But traceroute should be able to report link-local addresses, and >> ULAs, as well. If it doesnt then it's a problem of that >> traceroute program. > > See above. Merely reporting an address that is utterly and > completely meaningless outside of the zone of administrative control > (ULA) or outside of the local link (LL) is less than helpful. It depends what is in that address. It's its scope which does not matter. >> If an enduser needs rather globally-scoped and unique (rathern >> than LL and ULA) addresses in traceroute outputs then one should >> ask her why? Be them globally-scoped and unique they dont tell >> anything useful to a human user of traceroute. They surely dont >> tell _where_ these addresses are (like in 'what country’). > > Well, the address being GUA alone is not the complete solution, but > it is certainly a necessary component. The address being a GUA (and not a LL) is an artifact of porting traceroute from IPv4 to IPv6. A native IPv6 traceroute would report LLs as well. And be ported back to IPv4 to report IPv4 LLs. > Obviously, the next step is to provide a useful mapping in ip6.arpa > as well. Yes. > For example: > > owen.delong.com:owen /home4/owen (29) % traceroute6 www.facebook.com > traceroute to www.facebook.com > (2a03:2880:10:cf07:face:b00c:0:1), 30 hops > max, 80 byte packets 1 2620:0:930:0:2e6b:f5ff:fe03:a80 > (2620:0:930:0:2e6b:f5ff:fe03:a80) 1.788 ms 1.777 ms 1.787 ms 2 > owen-2.tunnel.tserv2.fmt.ipv6.he.net > (2001:470:1f03:9c::1) 12.973 ms 19.452 ms 20.374 ms 3 > ge4-22.core2.fmt1.he.net > (2001:470:0:1f::1) 28.750 ms 29.679 ms 29.739 ms 4 > ge5-15.core1.fmt2.he.net > (2001:470:0:1bc::1) 20.313 ms 20.331 ms 20.337 ms 5 > 10ge1-1.core1.sjc2.he.net > (2001:470:0:31::2) 20.332 ms * * 6 * > facebook.gige-g5-9.core1.sjc2.he.net > (2001:470:0:14a::2) 18.399 ms 18.371 ms 7 ae1.bb03.sjc1.tfbnw.net > (2620:0:1cff:dead:beef::c5a) 18.370 > ms 24.237 ms 14.423 ms 8 ae24.bb04.prn2.tfbnw.net > (2620:0:1cff:dead:beef::c32) 33.334 > ms 32.289 ms 33.340 ms 9 ae4.dr05.prn1.tfbnw.net > (2620:0:1cff:dead:beef::68d) 39.411 > ms ae13.dr05.prn1.tfbnw.net > (2620:0:1cff:dead:beef::69d) 39.557 ms ae4.dr02.prn1.tfbnw.net > (2620:0:1cff:dead:beef::69b) 38.365 > ms 10 po1019.csw12a.prn1.tfbnw.net > (2620:0:1cff:dead:beef::1769) > 48.094 ms po1021.csw12d.prn1.tfbnw.net > (2620:0:1cff:dead:beef::1785) > 39.399 ms po1019.csw12b.prn1.tfbnw.net > (2620:0:1cff:dead:beef::1775) > 39.348 ms 11 * * * 12 edge-star6-shv-12-prn1.facebook.com > > (2a03:2880:10:cf07:face:b00c:0:1) 37.765 ms 38.419 ms 36.471 ms > > > Hop 1 doesn’t provide useful information, but it’s the SLAAC address > of the interior side of a local router, You see, why do you call it a SLAAC address? It's unsafe to assume ff:fe and global prefix means SLAAC. The randomly generated addresses, the DHCP, or the imaginative sysadmins, may have put the same ff:fe in there. ff:fe is not forbidden to DHCP, to sysadmins and to the random generation of privacy addresses. > so it’s only going to be seen on outbound traceroutes from my small > site. > > The other hops do provide useful ip6.arpa mappings (with the obvious > exception of hop 11 which doesn’t respond at all, probably a load > balancer at FB). > > I can tell from the information provided by the various operators > that my packet is delivered to an HE tunnelserver in their Fremont 1 > datacenter, then forwarded to a core router in that same datacenter, > over to their Fremont 2 datacenter, etc. Except that traceroute does not tell for each tunnel its 4 addresses. > I can even tell that on the core router in Fremont 1, my packet > arrived on gigabit ethernet interface card 4 port 22. I can also see > interface information on the remaining hops as well. > > The vast majority of providers put this information into ip6.arpa to > make their lives easier when it comes to troubleshooting, but it also > happens to make life easier for external users as well. Ok. >> An address present in a traceroute output tells many things _if_ >> that end user has an mental association of the address set >> out-of-band (like "all addresses starting 2a02 belong to the >> operator I trust"). But these out-of-band associations have no >> requirement whatsoever on the scope of the address, or its >> uniqueness across Internet, or prefix-middle-suffix position of >> the trusted incantation. One could very well have fe80:X:1 >> displayed by traceroute, and know out-of-band that when X is in the >> address then the operator is trusted. (e.g. X==face:b00c). > > Actually, they do. > > If I build a mental association of “all addresses starting with > fd0c:face:b00c::†belong to Face Book, not only am I an idiot for > trusting some sort of association between ULA and a particular > organization, but I’m also quite likely to be wrong some significant > portion of the time. You make a good supposition. There is no guarantee but it's likely to be the case. It's the same level of confidence in assuming 2a01:face:b00c:: belongs to facebook. The scope does not matter, there is no difference between global or local scope. >> Besides, traceroute output is hugely more meaningful when it does >> not display addresses but FQDNs. These FQDNs have nothing to do >> with address scope either. > > Yes, they do. You can’t (legitimately) create externally visible > ip6.arpa records for addresses that are not GUA scoped. If you think > that you can, please share whatever you are smoking. Do you mean that DNS requests are blocked if the parameter starts with "fe80"? Alex > > Owen > >> >> Alex >> >> >>> >>>> They are viewed by some as also having an important security >>>> property: they simply don't work off-link. >>>> draft-behringer-anima-autonomic-control-plane takes this view, >>>> for example. >>> >>> Blah blah blah. >>> >>>> Unnumbered, in the literal sense, doesn't exist in IPv6, which >>>> is why we are having this terminological discussion in the >>>> first place. >>> >>> It doesn’t exist in IPv4 in the literal sense, either. As others >>> have pointed out, what is called an unnumbered interface in >>> IPv4 is an interface that shares numbering with a loopback or >>> other interface which is an utter hack that yielded more >>> confusion than useful results in the early efforts to reduce IPv4 >>> address consumption. >>> >>> So, if you have something you don’t want to communicate off link >>> AT ALL, then by all means, go ahead and use link-local only >>> numbering to your hearts content. >>> >>> Otherwise, please put a real GUA on the interface to reduce the >>> number of problems you inflict on others when they have to >>> troubleshoot something that involves/transits/originates >>> from/etc. your network. >>> >>> Owen >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> >>> >>> >>> >>> _______________________________________________ >> v6ops mailing list v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Mar 13 04:42:06 2015 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 BCD4D1A0378 for ; Fri, 13 Mar 2015 04:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 jnbMjXEsLZKF for ; Fri, 13 Mar 2015 04:42: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 754951A0122 for ; Fri, 13 Mar 2015 04:42:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2DBftAF029822; Fri, 13 Mar 2015 12:41:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 738902018A9; Fri, 13 Mar 2015 12:42:20 +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 6520C20138A; Fri, 13 Mar 2015 12:42:20 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2DBfdIP018288; Fri, 13 Mar 2015 12:41:54 +0100 Message-ID: <5502CCF3.1020804@gmail.com> Date: Fri, 13 Mar 2015 12:41:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Owen DeLong References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <55018CAA.7010104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - traceroute 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: Fri, 13 Mar 2015 11:42:04 -0000 Le 12/03/2015 18:46, Owen DeLong a écrit : > >> On Mar 12, 2015, at 05:55 , Alexandru Petrescu >> > > wrote: >> >> Le 12/03/2015 13:41,sthaug@nethelp.no a >> écrit : >>>> YEs, we want traceroute to report an address of a hop, rather >>>> than a three-star string "* * *". >>>> >>>> But traceroute should be able to report link-local addresses, >>>> and ULAs, as well. If it doesnt then it's a problem of that >>>> traceroute program. >>> >>> Of course traceroute can report them. They are just not very >>> helpful. >>> >>>> If an enduser needs rather globally-scoped and unique (rathern >>>> than LL and ULA) addresses in traceroute outputs then one >>>> should ask her why? Be them globally-scoped and unique they >>>> dont tell anything useful to a human user of traceroute. They >>>> surely dont tell _where_ these addresses are (like in 'what >>>> country'). >>> >>> Getting globally-scoped and unique addresses in the answer is a >>> very important part of what I use traceroute for. I strongly >>> disagree with the claim that "they dont tell anything useful to a >>> human user of traceroute". In most cases it is the PTR lookups >>> for these addresses that actually have the most interesting >>> information - but not always. The IP addresses themselves are >>> also interesting, and can be used for further rounds of >>> traceroute, for instance. They can also be looked up through the >>> various RIRs etc. >> >> I think none of these can-do things can not be done with link-local >> addresses. >> >> You can have reverse DNS lookups for LL addresses, you can have LL >> addresses in the RIR allocation databases (maybe as comments), >> etc. > > I personally guarantee you that no RIR whois server is going to > respond usefully to a query for an address starting in fe80:: any > time soon. Well, it depends how the request is made and how me as owner ask the RIR to put things in that database. A RIR already puts my phone number in that database - why not a link-local address crafted to my taste? > I can also guarantee you that attempts to get any portion of > 0.8.e.f.ip6.arpa delegated to your nameserver by any of the RIRs are > also not likely to succeed. I agree. > Given that, how, exactly, do you propose that your above statements > can possible be true? I can always tell people to use my public DNS server if they want to LL-traceroute through my domain. >>>> Besides, traceroute output is hugely more meaningful when it >>>> does not display addresses but FQDNs. These FQDNs have nothing >>>> to do with address scope either. >>> >>> Surely they do. I cannot get a meaningful PTR lookup for a >>> link-local address. I *can* in many cases get a meaningful PTR >>> lookup for a globally-scoped address. >> >> But a LL address can be in the DNS also. It has not been put there >> in some particular case, but nothing stops it to be there. > > Not in a useful way it cannot. Sure, you can create an > 0.8.e.f.ip6.arpa zone within your DNS server and answer queries that > arrive there, but anyone outside of your administrative control is > unlikely to ask your server for that information. The RIRs are not > going to delegate NS for any portion of 0.8.e.f.ip6.arpa, and I > expect neither will IANA or IETF. YEs, but there are other perspectives as well. For example, google does not ask people to be under their adminsitrative control, but offer this 8.8.8.8 DNS server, and it's used extensively. > We’re talking about a global internet here, 'Global' Internet? What's the DNS server that could accept arbitrary requests in this global Internet? There isn't any which has no commercial interest in a _local_ business. > not some isolated LAN segment. If it’s an isolated LAN segment do > whatever you want, the IETF doesn’t care. You don’t need an RFC. RFCs > and the IETF process are for developing standards for cooperating > networks participating in a global internet. If you aren’t one of > those, then you can follow or not follow them as you wish on your > non-connected network. Ok, but I will refrain from further commenting on this DNS aspect and its locality. Alex > > Owen > > From nobody Fri Mar 13 04:49:16 2015 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 6FEA51A0267 for ; Fri, 13 Mar 2015 04:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 wQgodtnB0reC for ; Fri, 13 Mar 2015 04:49:12 -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 8951B1A0122 for ; Fri, 13 Mar 2015 04:49:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2DBn8uR004543; Fri, 13 Mar 2015 12:49:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7CB14201500; Fri, 13 Mar 2015 12:49:33 +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 6CA2B200B4E; Fri, 13 Mar 2015 12:49:33 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2DBmqB6025342; Fri, 13 Mar 2015 12:49:07 +0100 Message-ID: <5502CEA4.7000302@gmail.com> Date: Fri, 13 Mar 2015 12:48:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Owen DeLong References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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: Fri, 13 Mar 2015 11:49:15 -0000 Le 12/03/2015 18:52, Owen DeLong a écrit : > >> On Mar 12, 2015, at 06:14 , Alexandru Petrescu >> wrote: >> >> Le 12/03/2015 14:00, Gert Doering a écrit : >>> Hi, >>> >>> On Thu, Mar 12, 2015 at 01:41:33PM +0100, sthaug@nethelp.no >>> wrote: >>>>> But traceroute should be able to report link-local addresses, >>>>> and ULAs, as well. If it doesnt then it's a problem of that >>>>> traceroute program. >>>> Of course traceroute can report them. They are just not very >>>> helpful. >>> >>> While *traceroute* would be able to report anything, no router >>> worth its money should ever send a packet with a LLA source off a >>> link. >> >> Well, a router should not _forward_ such a packet, but it could >> always issue one, why not? >> >> Apps with beaconing semantics, or video stream (no need of reply), >> may use this. >> >>> So you should never see any packets that traceroute could report >>> about. >> >> Traceroute is a diagnostic program. I think you have no RFC that >> specifies how traceroute acts. >> >> You can write a 'traceroute' program that reports LL addresses, I >> dont see a problem in that. > > Here’s the problem… > > Traceroute depends on receiving ICMP HOP_COUNT_EXCEEDED messages with > the hop address embedded in the SRC field of the ICMP datagram. HOP_COUNT_EXCEEDED is a way of traceing a route. There are other ways in which do trace routes. ICMP_HOP_COUNT_EXCEEDED may be forbidden by some routers as well. > If you are running traceroute on a machine that is not adjacent to > the hop responding with said message from a LL source address, then > you will never see the packet because NONE of the routers between it > and you should forward said packet to a different interface from the > one it arrived on. > > So, traceroute may report whatever it receives, but it CANNOT receive > a packet with a LL Source address from a non-adjacent router unless > all of the routers in between violate the RFCs regarding forwarding > of LL packets. Ok. >>> That is, sort of, what the "local" in "local-scoped" is about, >>> no? >> >> It's local for locally-scoped protocols. But I can very well have >> a web page telling me all the addresses of a very distant router >> (many IP hops away), including its link-local addresses. > > Sure, but you’ll never get the LL address in your traceroute to look > up, so I think the web page is moot. > >> LL addresses can be present in payloads w/o problem. > > Yes, but traceroute doesn’t use the payload. > >> LL addresses can be present in IPv6 Routing Header. > > Yes, but I’m not sure how that applies here, nor am I sure it is > useful for them to appear there. > >> With this at hand a 'traceroute' program can report LL addresses. > > Not the way traceroute programs currently work. I think you would be > hard pressed to create a traceroute program that could do so without > modifying code on virtually every deployed IPv6 router as well. I agree. Alex > > Owen > >> >> Alex >> >>> >>> Gert Doering -- NetMaster >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Fri Mar 13 04:53:23 2015 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 DD6421A0371 for ; Fri, 13 Mar 2015 04:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 v1kZu0Au9knu for ; Fri, 13 Mar 2015 04:53:19 -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 44A8F1A037E for ; Fri, 13 Mar 2015 04:53:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2DBrB1D008832; Fri, 13 Mar 2015 12:53:11 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 69D86201741; Fri, 13 Mar 2015 12:53:36 +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 5BCBD201508; Fri, 13 Mar 2015 12:53:36 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2DBrAKF026747; Fri, 13 Mar 2015 12:53:10 +0100 Message-ID: <5502CFA6.70503@gmail.com> Date: Fri, 13 Mar 2015 12:53:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Metzler, Dan J" , Owen DeLong References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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: Fri, 13 Mar 2015 11:53:22 -0000 Le 12/03/2015 20:25, Metzler, Dan J a écrit : > I don't understand this discussion. I thought the topic was a > terminology discussion about whether to use the term "un-numbered" > when referring to an interface that only has a link-local address. My point was to say that traceroute needing GUAs should not mean the links without GUAs (hence 'unnumbered') should not exist. To put it other way, links without GUAs are there, and a name for them shoudl be found. > Traceroute should work with link-local addresses, but only when you > target a link-local address. (It won't go off link, so either that > address is a neighbor or it is not reachable, and traceroute probably > reflects that already.) Yes. > Same thing with ULA. If you actually use the ULA in the traceroute > command or it's in the route, then I would think it already shows > up. If not, you aren't going to see it. If LLs dont show in traceroute output because not on same link then ULA will not show either, unless in the same domain. > To me, the term "un-numbered" doesn't make much sense because the > interface has a link-local address. I agree. > > - Dan > >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Owen DeLong Sent: >> Thursday, March 12, 2015 12:52 PM To: Alexandru Petrescu Cc: >> v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in >> IPv6? >> >> >>> On Mar 12, 2015, at 06:14 , Alexandru Petrescu >> wrote: >>> >>> Le 12/03/2015 14:00, Gert Doering a écrit : >>>> Hi, >>>> >>>> On Thu, Mar 12, 2015 at 01:41:33PM +0100, sthaug@nethelp.no >>>> wrote: >>>>>> But traceroute should be able to report link-local >>>>>> addresses, and ULAs, as well. If it doesnt then it's a >>>>>> problem of that traceroute program. >>>>> Of course traceroute can report them. They are just not very >>>>> helpful. >>>> >>>> While *traceroute* would be able to report anything, no router >>>> worth its money should ever send a packet with a LLA source >>>> off a link. >>> >>> Well, a router should not _forward_ such a packet, but it could >>> always issue one, why not? >>> >>> Apps with beaconing semantics, or video stream (no need of >>> reply), may use >> this. >>> >>>> So you should never see any packets that traceroute could >>>> report about. >>> >>> Traceroute is a diagnostic program. I think you have no RFC that >>> specifies >> how traceroute acts. >>> >>> You can write a 'traceroute' program that reports LL addresses, I >>> dont see a >> problem in that. >> >> Here's the problem. >> >> Traceroute depends on receiving ICMP HOP_COUNT_EXCEEDED messages >> with the hop address embedded in the SRC field of the ICMP >> datagram. >> >> If you are running traceroute on a machine that is not adjacent to >> the hop responding with said message from a LL source address, >> then you will never see the packet because NONE of the routers >> between it and you should forward said packet to a different >> interface from the one it arrived on. >> >> So, traceroute may report whatever it receives, but it CANNOT >> receive a packet with a LL Source address from a non-adjacent >> router unless all of the routers in between violate the RFCs >> regarding forwarding of LL packets. >> >>>> That is, sort of, what the "local" in "local-scoped" is about, >>>> no? >>> >>> It's local for locally-scoped protocols. But I can very well >>> have a web page >> telling me all the addresses of a very distant router (many IP hops >> away), including its link-local addresses. >> >> Sure, but you'll never get the LL address in your traceroute to >> look up, so I think the web page is moot. >> >>> LL addresses can be present in payloads w/o problem. >> >> Yes, but traceroute doesn't use the payload. >> >>> LL addresses can be present in IPv6 Routing Header. >> >> Yes, but I'm not sure how that applies here, nor am I sure it is >> useful for them to appear there. >> >>> With this at hand a 'traceroute' program can report LL >>> addresses. >> >> Not the way traceroute programs currently work. I think you would >> be hard pressed to create a traceroute program that could do so >> without modifying code on virtually every deployed IPv6 router as >> well. >> >> Owen >> >>> >>> Alex >>> >>>> >>>> Gert Doering -- NetMaster >>>> >>> >>> >>> _______________________________________________ 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 13 05:30:32 2015 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 2EA111A09C9 for ; Fri, 13 Mar 2015 05:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 ez_UVdcEA7Yz for ; Fri, 13 Mar 2015 05:30:30 -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 A15CC1A037A for ; Fri, 13 Mar 2015 05:30:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2DCUOq0021394; Fri, 13 Mar 2015 13:30:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 81DE72012E4; Fri, 13 Mar 2015 13:30:49 +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 6FED0200C14; Fri, 13 Mar 2015 13:30:49 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2DCU1wD004978; Fri, 13 Mar 2015 13:30:23 +0100 Message-ID: <5502D849.90101@gmail.com> Date: Fri, 13 Mar 2015 13:30:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Owen DeLong References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 12:30:32 -0000 On this particular point. Le 12/03/2015 18:52, Owen DeLong a écrit : [...] > So, traceroute may report whatever it receives, but it CANNOT receive > a packet with a LL Source address from a non-adjacent router unless > all of the routers in between violate the RFCs regarding forwarding > of LL packets. For example RFC4291 "Addr Architecture" forbids packets with src or dst address to get away from a link. It literraly says "Routers must not forward any packets with Link-Local source or destination addresses to other links." Whereas the dst part reads best, I wonder whether the src part does not amount a bit to ingress filtering. Ingress filtering is a policy useful in some security context, but is also seen as a bad technique that needs to be overcome by some other technique. Ingress filtering would not be part of architectural thinking, but of policy thinking. There may be, in some context, a need of a packet with a LL src address and a GUA dst address. This packet would be forwarded by routers, although they may log it as an exceptional case. But it should not be dropped. If this were done, then maybe traceroute programs which rely on the chance of HOP_COUNT_EXCEEDED would report LLs as well. Alex > >>> That is, sort of, what the "local" in "local-scoped" is about, >>> no? >> >> It's local for locally-scoped protocols. But I can very well have >> a web page telling me all the addresses of a very distant router >> (many IP hops away), including its link-local addresses. > > Sure, but you’ll never get the LL address in your traceroute to look > up, so I think the web page is moot. > >> LL addresses can be present in payloads w/o problem. > > Yes, but traceroute doesn’t use the payload. > >> LL addresses can be present in IPv6 Routing Header. > > Yes, but I’m not sure how that applies here, nor am I sure it is > useful for them to appear there. > >> With this at hand a 'traceroute' program can report LL addresses. > > Not the way traceroute programs currently work. I think you would be > hard pressed to create a traceroute program that could do so without > modifying code on virtually every deployed IPv6 router as well. > > Owen > >> >> Alex >> >>> >>> Gert Doering -- NetMaster >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Fri Mar 13 05:42:41 2015 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 BDD0F1A0419 for ; Fri, 13 Mar 2015 05:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LXT4zc8AkvJI for ; Fri, 13 Mar 2015 05:42:34 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E0B1A0122 for ; Fri, 13 Mar 2015 05:42:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C89A8A2; Fri, 13 Mar 2015 13:42:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1426250551; bh=f1xyUWJECOyrA6Y5RrurdJtOW/rQzVcmZaOn4E65g3Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fzRiJONmO3kVQLaOh7Z/tdSo1Jl8Lte478N0YgBC1j93qw90thj67UuMk6nnn/Y0N Z0yK65J/44bPu35di8ObPnjrT1yjx8zXj9ZmD36m4Dxeizo5rp2/ssJJRfhaW/WXOU 1nWL+UowYqaBW8Hb9S1t+jSfMnv30nLxNriPLosE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BC00AA1; Fri, 13 Mar 2015 13:42:31 +0100 (CET) Date: Fri, 13 Mar 2015 13:42:31 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <5502D849.90101@gmail.com> Message-ID: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1371128264-1426250551=:20507" Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 12:42:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1371128264-1426250551=:20507 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 13 Mar 2015, Alexandru Petrescu wrote: > On this particular point. > > Le 12/03/2015 18:52, Owen DeLong a écrit : > [...] >> So, traceroute may report whatever it receives, but it CANNOT receive >> a packet with a LL Source address from a non-adjacent router unless >> all of the routers in between violate the RFCs regarding forwarding >> of LL packets. > > For example RFC4291 "Addr Architecture" forbids packets with src or dst > address to get away from a link. It literraly says "Routers must not > forward any packets with Link-Local source or destination addresses to > other links." > > Whereas the dst part reads best, I wonder whether the src part does not > amount a bit to ingress filtering. Ingress filtering is a policy useful > in some security context, but is also seen as a bad technique that needs > to be overcome by some other technique. Ingress filtering would not be > part of architectural thinking, but of policy thinking. > > There may be, in some context, a need of a packet with a LL src address > and a GUA dst address. This packet would be forwarded by routers, > although they may log it as an exceptional case. But it should not be > dropped. Yes it should. RFC4291 says it MUST be dropped, with very good reason. We do not want LL (src or dst) packets being routed around. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1371128264-1426250551=:20507-- From nobody Fri Mar 13 06:14:11 2015 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 474801A1B0D for ; Fri, 13 Mar 2015 06:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 ibPgLdNAUweJ for ; Fri, 13 Mar 2015 06:14:00 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 3A22C1A1B21 for ; Fri, 13 Mar 2015 06:14:00 -0700 (PDT) Received: from 83-215-234-57.stadt.stat.salzburg-online.at ([83.215.234.57] helo=[10.1.0.75]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YWPPZ-0006MS-Gi; Fri, 13 Mar 2015 14:13:58 +0100 Message-ID: <5502DDE8.2040800@si6networks.com> Date: Fri, 13 Mar 2015 13:54:00 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nick Hilliard , Fernando Gont , "v6ops@ietf.org" References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <54FF0602.40007@foobar.org> In-Reply-To: <54FF0602.40007@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 13:14:02 -0000 On 03/10/2015 03:56 PM, Nick Hilliard wrote: > On 10/03/2015 01:08, Fernando Gont wrote: >> Please do let us now if you have any feedback. > > Interesting. Where did you take the measurements from? For the results we've published in the I-D, the tests were performed from host Slovenia. Same results were obtained when redoing the tests from Brazil. And measuring things from the UK, and even (distributed) with the RIPE probes gives the same results. -- this is not surprising, since the drops do not happen close to the origin, but rather at the Dest AS or transit ASes. Thanks, -- 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 13 06:14:12 2015 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 8BCE11A1B21 for ; Fri, 13 Mar 2015 06:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 DntCjlI-RIi3 for ; Fri, 13 Mar 2015 06:14:01 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 CD1C91A1B30 for ; Fri, 13 Mar 2015 06:14:00 -0700 (PDT) Received: from 83-215-234-57.stadt.stat.salzburg-online.at ([83.215.234.57] helo=[10.1.0.75]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YWPPb-0006MZ-IO; Fri, 13 Mar 2015 14:13:59 +0100 Message-ID: <5502DEA3.3030700@si6networks.com> Date: Fri, 13 Mar 2015 13:57:07 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brian E Carpenter , IPv6 Operations References: <20150309053609.23108.98801.idtracker@ietfa.amsl.com> <54FFB9F8.9000408@gmail.com> In-Reply-To: <54FFB9F8.9000408@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt 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: Fri, 13 Mar 2015 13:14:02 -0000 On 03/11/2015 04:43 AM, Brian E Carpenter wrote: > Hi, > > I just noticed that the draft does not state the contents > of the DO8 and HBH8 headers used. Are they just PadN? Yes. > Anyway, to fully understand the experiment, it should be stated. Page 3 says: In the case of packets with Destination Options Header and Hop-by-Hop Options header, the desired EH size was achieved by means of PadN options [RFC2460]. Cheers, -- 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 13 06:14:13 2015 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 A6B171A1B4E for ; Fri, 13 Mar 2015 06:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 YPPDviyyJdrU for ; Fri, 13 Mar 2015 06:14:02 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 A5F361A1B0D for ; Fri, 13 Mar 2015 06:14:02 -0700 (PDT) Received: from 83-215-234-57.stadt.stat.salzburg-online.at ([83.215.234.57] helo=[10.1.0.75]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YWPPc-0006Mg-HM; Fri, 13 Mar 2015 14:14:00 +0100 Message-ID: <5502E049.7030004@si6networks.com> Date: Fri, 13 Mar 2015 14:04:09 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan , Fernando Gont References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> In-Reply-To: <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 13:14:07 -0000 On 03/12/2015 02:06 PM, Ole Troan wrote: > I don’t think you can equate ‘real world’ with ‘public servers’. Well, public servers are part of the real world. What we meant is that this I-D gives results from actual measurements. FWIW, if anyone is concerned about the title, we could update it. I personally don't think it's needed... but I wouldn't be opposed to do so. > to me it seems the draft documents what should be expected. public > servers doesn’t accept packets that aren’t part of the service > they offer. Well, in order for options to be incrementally deployable, they should be allowed. When it comes to IP options, I'm not sure I consider them to be "part of the service". Fragmentation, in particular, is a core part of IP. > what is it you find unexpected in the behaviour you have found? > > I’m concerned about this draft. I think it will be used to justify > claims that fragmentation, extension headers or new transport > protocols cannot be deployed, but as far as I can see it does no > such thing. Me, I see the results as "there is a problem here". That's it. There are other efforts (Brian and Sheng's RFC7045, the I-D we published on option transmission aimed at 6man, e.g.) that indeed try to help in improving the state of affairs (rather than "ban" EHs). > if you wanted to see how extension headers are treated end to end > in the Internet, then measure that. host-to-servers is certainly part of that. Certainly measuring client-to-clients would also be nice -- and that's in the works through the use of RIPE atlas. However, that would be *additional* data as opposed to *stuff to replace what's currently in the I-D*. Thanks! Cheers, -- 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 13 06:14:15 2015 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 19D311A1B4E for ; Fri, 13 Mar 2015 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 MgoYnQh85lOl for ; Fri, 13 Mar 2015 06:14:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 EFCAC1A1B21 for ; Fri, 13 Mar 2015 06:14:02 -0700 (PDT) Received: from 83-215-234-57.stadt.stat.salzburg-online.at ([83.215.234.57] helo=[10.1.0.75]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YWPPd-0006Mj-HF; Fri, 13 Mar 2015 14:14:01 +0100 Message-ID: <5502E0F1.7040309@si6networks.com> Date: Fri, 13 Mar 2015 14:06:57 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan , Nick Hilliard References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> In-Reply-To: <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 13:14:08 -0000 On 03/12/2015 04:24 PM, Ole Troan wrote: >> >> 3. this appears to be a problem at both the core and edge of the >> ipv6 internet > > I can’t find anything in the draft showing that the core of the > Internet is applying this filtering policy. "Drop rates by non-dest AS"? Cheers, -- 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 13 06:14:16 2015 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 9DED51A1B64 for ; Fri, 13 Mar 2015 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 ilfJCMMX0pHb for ; Fri, 13 Mar 2015 06:14:07 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 5E86A1A1B30 for ; Fri, 13 Mar 2015 06:14:04 -0700 (PDT) Received: from 83-215-234-57.stadt.stat.salzburg-online.at ([83.215.234.57] helo=[10.1.0.75]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YWPPe-0006Mu-Mb; Fri, 13 Mar 2015 14:14:02 +0100 Message-ID: <5502E263.3020905@si6networks.com> Date: Fri, 13 Mar 2015 14:13:07 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan , Brian E Carpenter References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> In-Reply-To: <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 13:14:08 -0000 On 03/12/2015 11:08 PM, Ole Troan wrote: > >> failures not only at the end-AS but also in a noticeable fraction >> of cases at an intermediate AS. So the choice of servers is a >> bit beside the point. > > that’s a more interesting case. with a relatively large > uncertainty. presumably we could take some of these paths from the > data set and ask the suspected dropping providers what’s going on? I can provide the list of ASes if you folks wish (I recently updated the tools such that they inform the dropping ASes... os the list is readiliy available). >> Whether the IETF can do more about this than RFC 7045 is another >> question entirely. > > apart from dropping HBH I would be quite surprised if there were > any transit AS operators thinking that filtering fragments was > acceptable for a functioning Internet. let’s get some more real > data on what’s really going on. What's (specifically) the data that you're looking for? -- I'm not objecting, but rather asking so that ew can produce whatever you think is missing. Thanks! Cheers, -- 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 13 06:17:26 2015 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 F38121A1B64 for ; Fri, 13 Mar 2015 06:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 Q5XJOJAoEkUt for ; Fri, 13 Mar 2015 06:17:23 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 8A9CB1A0089 for ; Fri, 13 Mar 2015 06:17:23 -0700 (PDT) Received: from 83-215-234-57.stadt.stat.salzburg-online.at ([83.215.234.57] helo=[10.1.0.75]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YWPSr-0006OC-Al; Fri, 13 Mar 2015 14:17:22 +0100 Message-ID: <5502E326.9040808@si6networks.com> Date: Fri, 13 Mar 2015 14:16:22 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nick Hilliard , Ole Troan References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <550212CB.2090306@foobar.org> <55021899.7080908@foobar.org> In-Reply-To: <55021899.7080908@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 13:17:25 -0000 On 03/12/2015 11:52 PM, Nick Hilliard wrote: > On 12/03/2015 22:35, Ole Troan wrote: >> yes, so that example would definitely be in the >> misconfiguration/software/hardware bug category. > > If this is the best approach we can close down this discussion on the spot > and declare the entire issue to be a problem relating to misconfiguration, > bugs or both. mm. does that really solve the problem? Whether there's a bug, misconfiguration, or something else that prevents me form using EHs, seems rather irrelevant -- at the end of the day, no matter the specfic cause, you cannot use EHs in those networks. > The standards are clear on the requirement to support IPv6 > EHs so if operators / vendors aren't following it properly then surely > that's out of scope for the IETF? > > Or we could acknowledge that there is a problem, look into the causes and > see if it's worth doing something about it with a view to fixing it in the > long term. > > I'm inclined to think that the latter is a more sensible approach. Fully agree. Thanks! Cheers, -- 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 13 06:26:37 2015 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 9D4881A1BFC for ; Fri, 13 Mar 2015 06:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 UQ_-c0dtcscN for ; Fri, 13 Mar 2015 06:26:34 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 D620F1A1B92 for ; Fri, 13 Mar 2015 06:26:33 -0700 (PDT) Received: from 83-215-234-57.stadt.stat.salzburg-online.at ([83.215.234.57] helo=[10.1.0.75]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YWPbk-0006Pc-9p; Fri, 13 Mar 2015 14:26:32 +0100 Message-ID: <5502E584.1080204@gont.com.ar> Date: Fri, 13 Mar 2015 14:26:28 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Silvia Hagen , Nick Hilliard , Ole Troan References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <550212CB.2090306@foobar.org> <55021899.7080908@foobar.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 13:26:36 -0000 Hi, Silvia, On 03/13/2015 08:28 AM, Silvia Hagen wrote: > I totally understand all those issues, limitations, practices and > concerns. I am concerned about a tendency in the discussions to try > to make up and adjust standards for vendor limitations, configuration > issues, hardware bugs etc. And I think that is the wrong way to go. I > do believe that when it comes to architectural things like EHs the > working groups should stick to the design and the architecture and > help and expect the market to implement it properly. It is not a > working group/IETF problem if hardware have limitations, if firewall > administrators decide to drop EHs etc.... We should stick to the > original design and let this be their issue to solve by developing > mechanisms which support the future protocol and its architecture. I sympathize with the idea. However, I should note that there are areas where "proper implementation" doesn't seem to be on the horizon. Specific example: support of IPv6 header chains of arbitrary lengths (at least a packet full of EHs). Most of the architectures I recall checking enforce a limit on theIPv6 header chain. -- and it seems to be a "chicken and egg" problem: It's hard to believe that a router vendor will put money into something that is currently not required by any protocols (in practice). And of course you cannot relly on such full-sized EH chains if there's no support for them. FWIW, I'm not in favor of "banning" EHs, but I'm rather all for improving the current state of affairs. 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 Fri Mar 13 08:26:12 2015 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 9A3C31A6FF7 for ; Fri, 13 Mar 2015 08:26:10 -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 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 Wq_OLNMJAxmB for ; Fri, 13 Mar 2015 08:26:08 -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 738511A1AB5 for ; Fri, 13 Mar 2015 08:26:08 -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.1/8.14.9) with ESMTPSA id t2DFQ2mm005303 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 15:26:03 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <55030189.8010305@foobar.org> Date: Fri, 13 Mar 2015 15:26:01 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Fernando Gont , Fernando Gont , "v6ops@ietf.org" References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <54FF0602.40007@foobar.org> <5502DDE8.2040800@si6networks.com> In-Reply-To: <5502DDE8.2040800@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 15:26:10 -0000 On 13/03/2015 12:54, Fernando Gont wrote: > For the results we've published in the I-D, the tests were performed > from host Slovenia. Same results were obtained when redoing the tests > from Brazil. > > And measuring things from the UK, and even (distributed) with the RIPE > probes gives the same results. -- this is not surprising, since the > drops do not happen close to the origin, but rather at the Dest AS or > transit ASes. ok great. I had assumed it was from multiple start points. The source ASNs and any filtering between the source hosts and the upstream links (even if there is none) should be mentioned in the draft because it's an important part of the experiment methodology. Nick From nobody Fri Mar 13 09:15:41 2015 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 54ED71A8F45 for ; Fri, 13 Mar 2015 09:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 6HMTnMOUN5j3 for ; Fri, 13 Mar 2015 09:15:37 -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 3FAFD1A8F37 for ; Fri, 13 Mar 2015 09:15:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2DGFLxd016086; Fri, 13 Mar 2015 17:15:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D6A1A2057E7; Fri, 13 Mar 2015 17:15:46 +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 C70382057C6; Fri, 13 Mar 2015 17:15:46 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2DGF373022136; Fri, 13 Mar 2015 17:15:20 +0100 Message-ID: <55030D07.5070306@gmail.com> Date: Fri, 13 Mar 2015 17:15:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 16:15:39 -0000 Le 13/03/2015 13:42, Mikael Abrahamsson a écrit : > On Fri, 13 Mar 2015, Alexandru Petrescu wrote: > >> On this particular point. >> >> Le 12/03/2015 18:52, Owen DeLong a écrit : [...] >>> So, traceroute may report whatever it receives, but it CANNOT >>> receive a packet with a LL Source address from a non-adjacent >>> router unless all of the routers in between violate the RFCs >>> regarding forwarding of LL packets. >> >> For example RFC4291 "Addr Architecture" forbids packets with src >> or dst address to get away from a link. It literraly says >> "Routers must not forward any packets with Link-Local source or >> destination addresses to other links." >> >> Whereas the dst part reads best, I wonder whether the src part >> does not amount a bit to ingress filtering. Ingress filtering is >> a policy useful in some security context, but is also seen as a >> bad technique that needs to be overcome by some other technique. >> Ingress filtering would not be part of architectural thinking, but >> of policy thinking. >> >> There may be, in some context, a need of a packet with a LL src >> address and a GUA dst address. This packet would be forwarded by >> routers, although they may log it as an exceptional case. But it >> should not be dropped. > > Yes it should. RFC4291 says it MUST be dropped, with very good > reason. We do not want LL (src or dst) packets being routed around. It's a good principle, one of the few still resisting to exceptions. Maybe one thinks that lack of uniqueness guarantees by administrative allocation, and lack of same-scope equipotency, may induce harm when forwarding LL-src packets. Yet packets with src ULA and dst GUA _are_ routed around. Packets with src unicast and dst multicast _are_ routed around. Packets with src LL and dst GUA multiple hops away from that link can be helpful to some applications not needing replies (e.g. periodic beacons of routing protocols, or of tunnel maintenance, or of NAT-state maintenance during traversal). I'd go as far as saying that packets with dst LL which is _one_ hop away should be forwarded, because the Router is able to detect address collisions on both its links. Beyond one hop it would be a problem, but forwarding LL across one hop should not break anything. Alex > From nobody Fri Mar 13 09:22:21 2015 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 A70101A892F for ; Fri, 13 Mar 2015 09:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XZdbaif2Wt4b for ; Fri, 13 Mar 2015 09:22:18 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C2C1A8907 for ; Fri, 13 Mar 2015 09:22:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2DGMHPK021552; Fri, 13 Mar 2015 09:22:17 -0700 Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2DGMFM6021527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 13 Mar 2015 09:22:16 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.100]) with mapi id 14.03.0210.002; Fri, 13 Mar 2015 09:22:15 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Mikael Abrahamsson Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away Thread-Index: AQHQXaj64x+tAUa03UWC/53Dv/6hxp0al5nw Date: Fri, 13 Mar 2015 16:22:14 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> In-Reply-To: <55030D07.5070306@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 16:22:19 -0000 Hi, I am way out of context on this thread, but I wanted to ask the following. It should be OK for a router to leave some of its links as link-local-only as long as the router has at least one GUA that it can use as the source address of any ICMPs it needs to send - right? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > Sent: Friday, March 13, 2015 9:15 AM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbiddin= g LL away >=20 > Le 13/03/2015 13:42, Mikael Abrahamsson a =E9crit : > > On Fri, 13 Mar 2015, Alexandru Petrescu wrote: > > > >> On this particular point. > >> > >> Le 12/03/2015 18:52, Owen DeLong a =E9crit : [...] > >>> So, traceroute may report whatever it receives, but it CANNOT > >>> receive a packet with a LL Source address from a non-adjacent > >>> router unless all of the routers in between violate the RFCs > >>> regarding forwarding of LL packets. > >> > >> For example RFC4291 "Addr Architecture" forbids packets with src > >> or dst address to get away from a link. It literraly says > >> "Routers must not forward any packets with Link-Local source or > >> destination addresses to other links." > >> > >> Whereas the dst part reads best, I wonder whether the src part > >> does not amount a bit to ingress filtering. Ingress filtering is > >> a policy useful in some security context, but is also seen as a > >> bad technique that needs to be overcome by some other technique. > >> Ingress filtering would not be part of architectural thinking, but > >> of policy thinking. > >> > >> There may be, in some context, a need of a packet with a LL src > >> address and a GUA dst address. This packet would be forwarded by > >> routers, although they may log it as an exceptional case. But it > >> should not be dropped. > > > > Yes it should. RFC4291 says it MUST be dropped, with very good > > reason. We do not want LL (src or dst) packets being routed around. >=20 > It's a good principle, one of the few still resisting to exceptions. >=20 > Maybe one thinks that lack of uniqueness guarantees by administrative > allocation, and lack of same-scope equipotency, may induce harm when > forwarding LL-src packets. >=20 > Yet packets with src ULA and dst GUA _are_ routed around. >=20 > Packets with src unicast and dst multicast _are_ routed around. >=20 > Packets with src LL and dst GUA multiple hops away from that link can be > helpful to some applications not needing replies (e.g. periodic beacons > of routing protocols, or of tunnel maintenance, or of NAT-state > maintenance during traversal). >=20 > I'd go as far as saying that packets with dst LL which is _one_ hop away > should be forwarded, because the Router is able to detect address > collisions on both its links. Beyond one hop it would be a problem, but > forwarding LL across one hop should not break anything. >=20 > Alex >=20 > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Mar 13 09:32:38 2015 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 04B3E1A00B0 for ; Fri, 13 Mar 2015 09:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 1Wp7ks7NAKMs for ; Fri, 13 Mar 2015 09:32:35 -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 9434F1A005D for ; Fri, 13 Mar 2015 09:32:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2DGWTWA025560; Fri, 13 Mar 2015 17:32:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36A152057A5; Fri, 13 Mar 2015 17:32: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 28E76203A6C; Fri, 13 Mar 2015 17:32:55 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2DGWBDm023783; Fri, 13 Mar 2015 17:32:29 +0100 Message-ID: <5503110B.6080606@gmail.com> Date: Fri, 13 Mar 2015 17:32:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , Mikael Abrahamsson References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 16:32:38 -0000 Le 13/03/2015 17:22, Templin, Fred L a écrit : > Hi, > > I am way out of context on this thread, but I wanted to ask the > following. It should be OK for a router to leave some of its links > as link-local-only as long as the router has at least one GUA that it > can use as the source address of any ICMPs it needs to send - right? I think yes, that would be sufficient to respect RFCs. And yes, it makes ok to talk about ll-only links on which traceroute still works (even though it reports the GUA not the LL). It would not help traceroute to display LL addresses. It would mean to ifconfig the same GUA on several of its interfaces; if so the interface would no longer be LL-only, although the other side of a link may be LL-only. That link would be a link half-ll-only, or 'half-unnumbered' if I can say so. Alex > > Thanks - Fred fred.l.templin@boeing.com > >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Friday, March 13, 2015 9:15 AM To: Mikael Abrahamsson Cc: >> v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in >> IPv6? - RFCs forbidding LL away >> >> Le 13/03/2015 13:42, Mikael Abrahamsson a écrit : >>> On Fri, 13 Mar 2015, Alexandru Petrescu wrote: >>> >>>> On this particular point. >>>> >>>> Le 12/03/2015 18:52, Owen DeLong a écrit : [...] >>>>> So, traceroute may report whatever it receives, but it >>>>> CANNOT receive a packet with a LL Source address from a >>>>> non-adjacent router unless all of the routers in between >>>>> violate the RFCs regarding forwarding of LL packets. >>>> >>>> For example RFC4291 "Addr Architecture" forbids packets with >>>> src or dst address to get away from a link. It literraly says >>>> "Routers must not forward any packets with Link-Local source >>>> or destination addresses to other links." >>>> >>>> Whereas the dst part reads best, I wonder whether the src part >>>> does not amount a bit to ingress filtering. Ingress filtering >>>> is a policy useful in some security context, but is also seen >>>> as a bad technique that needs to be overcome by some other >>>> technique. Ingress filtering would not be part of architectural >>>> thinking, but of policy thinking. >>>> >>>> There may be, in some context, a need of a packet with a LL >>>> src address and a GUA dst address. This packet would be >>>> forwarded by routers, although they may log it as an >>>> exceptional case. But it should not be dropped. >>> >>> Yes it should. RFC4291 says it MUST be dropped, with very good >>> reason. We do not want LL (src or dst) packets being routed >>> around. >> >> It's a good principle, one of the few still resisting to >> exceptions. >> >> Maybe one thinks that lack of uniqueness guarantees by >> administrative allocation, and lack of same-scope equipotency, may >> induce harm when forwarding LL-src packets. >> >> Yet packets with src ULA and dst GUA _are_ routed around. >> >> Packets with src unicast and dst multicast _are_ routed around. >> >> Packets with src LL and dst GUA multiple hops away from that link >> can be helpful to some applications not needing replies (e.g. >> periodic beacons of routing protocols, or of tunnel maintenance, or >> of NAT-state maintenance during traversal). >> >> I'd go as far as saying that packets with dst LL which is _one_ hop >> away should be forwarded, because the Router is able to detect >> address collisions on both its links. Beyond one hop it would be a >> problem, but forwarding LL across one hop should not break >> anything. >> >> Alex >> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Mar 13 09:43:39 2015 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 730911A86EC for ; Fri, 13 Mar 2015 09:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lzeDePvCgTz2 for ; Fri, 13 Mar 2015 09:43:36 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3388D1A006B for ; Fri, 13 Mar 2015 09:43:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2DGhZMp025056; Fri, 13 Mar 2015 11:43:35 -0500 Received: from XCH-BLV-404.nw.nos.boeing.com (xch-blv-404.nw.nos.boeing.com [130.247.25.157]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2DGhQZQ024475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 13 Mar 2015 11:43:27 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.24]) with mapi id 14.03.0210.002; Fri, 13 Mar 2015 09:43:25 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Mikael Abrahamsson Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away Thread-Index: AQHQXaj64x+tAUa03UWC/53Dv/6hxp0al5nwgAB48ID//41dsA== Date: Fri, 13 Mar 2015 16:43:25 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E1C9CC@XCH-BLV-504.nw.nos.boeing.com> References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> <5503110B.6080606@gmail.com> In-Reply-To: <5503110B.6080606@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 16:43:38 -0000 Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, March 13, 2015 9:32 AM > To: Templin, Fred L; Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbiddin= g LL away >=20 > Le 13/03/2015 17:22, Templin, Fred L a =E9crit : > > Hi, > > > > I am way out of context on this thread, but I wanted to ask the > > following. It should be OK for a router to leave some of its links > > as link-local-only as long as the router has at least one GUA that it > > can use as the source address of any ICMPs it needs to send - right? >=20 > I think yes, that would be sufficient to respect RFCs. >=20 > And yes, it makes ok to talk about ll-only links on which traceroute > still works (even though it reports the GUA not the LL). >=20 > It would not help traceroute to display LL addresses. >=20 > It would mean to ifconfig the same GUA on several of its interfaces; if > so the interface would no longer be LL-only, although the other side of > a link may be LL-only. That link would be a link half-ll-only, or > 'half-unnumbered' if I can say so. I am thinking of a router that pins a GUA on some sort of internal virtual interface (like a loopback) but leaves all of its other interfaces as link local only. Do you see a problem with that? Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Thanks - Fred fred.l.templin@boeing.com > > > >> -----Original Message----- From: v6ops > >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu > >> Sent: Friday, March 13, 2015 9:15 AM To: Mikael Abrahamsson Cc: > >> v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in > >> IPv6? - RFCs forbidding LL away > >> > >> Le 13/03/2015 13:42, Mikael Abrahamsson a =E9crit : > >>> On Fri, 13 Mar 2015, Alexandru Petrescu wrote: > >>> > >>>> On this particular point. > >>>> > >>>> Le 12/03/2015 18:52, Owen DeLong a =E9crit : [...] > >>>>> So, traceroute may report whatever it receives, but it > >>>>> CANNOT receive a packet with a LL Source address from a > >>>>> non-adjacent router unless all of the routers in between > >>>>> violate the RFCs regarding forwarding of LL packets. > >>>> > >>>> For example RFC4291 "Addr Architecture" forbids packets with > >>>> src or dst address to get away from a link. It literraly says > >>>> "Routers must not forward any packets with Link-Local source > >>>> or destination addresses to other links." > >>>> > >>>> Whereas the dst part reads best, I wonder whether the src part > >>>> does not amount a bit to ingress filtering. Ingress filtering > >>>> is a policy useful in some security context, but is also seen > >>>> as a bad technique that needs to be overcome by some other > >>>> technique. Ingress filtering would not be part of architectural > >>>> thinking, but of policy thinking. > >>>> > >>>> There may be, in some context, a need of a packet with a LL > >>>> src address and a GUA dst address. This packet would be > >>>> forwarded by routers, although they may log it as an > >>>> exceptional case. But it should not be dropped. > >>> > >>> Yes it should. RFC4291 says it MUST be dropped, with very good > >>> reason. We do not want LL (src or dst) packets being routed > >>> around. > >> > >> It's a good principle, one of the few still resisting to > >> exceptions. > >> > >> Maybe one thinks that lack of uniqueness guarantees by > >> administrative allocation, and lack of same-scope equipotency, may > >> induce harm when forwarding LL-src packets. > >> > >> Yet packets with src ULA and dst GUA _are_ routed around. > >> > >> Packets with src unicast and dst multicast _are_ routed around. > >> > >> Packets with src LL and dst GUA multiple hops away from that link > >> can be helpful to some applications not needing replies (e.g. > >> periodic beacons of routing protocols, or of tunnel maintenance, or > >> of NAT-state maintenance during traversal). > >> > >> I'd go as far as saying that packets with dst LL which is _one_ hop > >> away should be forwarded, because the Router is able to detect > >> address collisions on both its links. Beyond one hop it would be a > >> problem, but forwarding LL across one hop should not break > >> anything. > >> > >> Alex > >> > >>> > >> > >> > >> _______________________________________________ v6ops mailing list > >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > >=20 From nobody Fri Mar 13 09:52:18 2015 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 A1EE31A87BD for ; Fri, 13 Mar 2015 09:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 823iTJAhjrqX for ; Fri, 13 Mar 2015 09:52:14 -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 04DA81A8715 for ; Fri, 13 Mar 2015 09:52:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2DGq2UA002296; Fri, 13 Mar 2015 17:52:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5513F20573D; Fri, 13 Mar 2015 17:52:28 +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 45EB4201263; Fri, 13 Mar 2015 17:52:28 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2DGpjpR030191; Fri, 13 Mar 2015 17:52:02 +0100 Message-ID: <550315A1.4090607@gmail.com> Date: Fri, 13 Mar 2015 17:51:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , Mikael Abrahamsson References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> <5503110B.6080606@gmail.com> <2134F8430051B64F815C691A62D9831832E1C9CC@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E1C9CC@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 16:52:16 -0000 Hi Fred, Le 13/03/2015 17:43, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, March 13, 2015 >> 9:32 AM To: Templin, Fred L; Mikael Abrahamsson Cc: >> v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in >> IPv6? - RFCs forbidding LL away >> >> Le 13/03/2015 17:22, Templin, Fred L a écrit : >>> Hi, >>> >>> I am way out of context on this thread, but I wanted to ask the >>> following. It should be OK for a router to leave some of its >>> links as link-local-only as long as the router has at least one >>> GUA that it can use as the source address of any ICMPs it needs >>> to send - right? >> >> I think yes, that would be sufficient to respect RFCs. >> >> And yes, it makes ok to talk about ll-only links on which >> traceroute still works (even though it reports the GUA not the >> LL). >> >> It would not help traceroute to display LL addresses. >> >> It would mean to ifconfig the same GUA on several of its >> interfaces; if so the interface would no longer be LL-only, >> although the other side of a link may be LL-only. That link would >> be a link half-ll-only, or 'half-unnumbered' if I can say so. > > I am thinking of a router that pins a GUA on some sort of internal > virtual interface (like a loopback) but leaves all of its other > interfaces as link local only. Do you see a problem with that? I don't see a problem with that. These would be LL-only links, although the Routers themselves have GUAs. The routing would work. I am not sure though what will be the src address of this HOP_COUNT_EXCEEDED ICMP message - the GUA pinned on the virtual interface? Or the LL address on the real interface? Alex > > Thanks - Fred fred.l.templin@boeing.com > >> Alex >> >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>>> -----Original Message----- From: v6ops >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru >>>> Petrescu Sent: Friday, March 13, 2015 9:15 AM To: Mikael >>>> Abrahamsson Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we >>>> use "unnumbered" in IPv6? - RFCs forbidding LL away >>>> >>>> Le 13/03/2015 13:42, Mikael Abrahamsson a écrit : >>>>> On Fri, 13 Mar 2015, Alexandru Petrescu wrote: >>>>> >>>>>> On this particular point. >>>>>> >>>>>> Le 12/03/2015 18:52, Owen DeLong a écrit : [...] >>>>>>> So, traceroute may report whatever it receives, but it >>>>>>> CANNOT receive a packet with a LL Source address from a >>>>>>> non-adjacent router unless all of the routers in between >>>>>>> violate the RFCs regarding forwarding of LL packets. >>>>>> >>>>>> For example RFC4291 "Addr Architecture" forbids packets >>>>>> with src or dst address to get away from a link. It >>>>>> literraly says "Routers must not forward any packets with >>>>>> Link-Local source or destination addresses to other >>>>>> links." >>>>>> >>>>>> Whereas the dst part reads best, I wonder whether the src >>>>>> part does not amount a bit to ingress filtering. Ingress >>>>>> filtering is a policy useful in some security context, but >>>>>> is also seen as a bad technique that needs to be overcome >>>>>> by some other technique. Ingress filtering would not be >>>>>> part of architectural thinking, but of policy thinking. >>>>>> >>>>>> There may be, in some context, a need of a packet with a >>>>>> LL src address and a GUA dst address. This packet would >>>>>> be forwarded by routers, although they may log it as an >>>>>> exceptional case. But it should not be dropped. >>>>> >>>>> Yes it should. RFC4291 says it MUST be dropped, with very >>>>> good reason. We do not want LL (src or dst) packets being >>>>> routed around. >>>> >>>> It's a good principle, one of the few still resisting to >>>> exceptions. >>>> >>>> Maybe one thinks that lack of uniqueness guarantees by >>>> administrative allocation, and lack of same-scope equipotency, >>>> may induce harm when forwarding LL-src packets. >>>> >>>> Yet packets with src ULA and dst GUA _are_ routed around. >>>> >>>> Packets with src unicast and dst multicast _are_ routed >>>> around. >>>> >>>> Packets with src LL and dst GUA multiple hops away from that >>>> link can be helpful to some applications not needing replies >>>> (e.g. periodic beacons of routing protocols, or of tunnel >>>> maintenance, or of NAT-state maintenance during traversal). >>>> >>>> I'd go as far as saying that packets with dst LL which is _one_ >>>> hop away should be forwarded, because the Router is able to >>>> detect address collisions on both its links. Beyond one hop it >>>> would be a problem, but forwarding LL across one hop should not >>>> break anything. >>>> >>>> Alex >>>> >>>>> >>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> > > > From nobody Fri Mar 13 10:16:38 2015 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 0C4761A8A9A for ; Fri, 13 Mar 2015 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 puLlDNmoI1yh for ; Fri, 13 Mar 2015 10:16:36 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022CA1A7D82 for ; Fri, 13 Mar 2015 10:16:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2DHGZh1015125; Fri, 13 Mar 2015 12:16:35 -0500 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2DHGQxI015073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 13 Mar 2015 12:16:26 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.47]) with mapi id 14.03.0210.002; Fri, 13 Mar 2015 10:16:25 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Mikael Abrahamsson Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away Thread-Index: AQHQXaj64x+tAUa03UWC/53Dv/6hxp0al5nwgAB48ID//41dsIAAeBqA//+QUfA= Date: Fri, 13 Mar 2015 17:16:24 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E1CACB@XCH-BLV-504.nw.nos.boeing.com> References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> <5503110B.6080606@gmail.com> <2134F8430051B64F815C691A62D9831832E1C9CC@XCH-BLV-504.nw.nos.boeing.com> <550315A1.4090607@gmail.com> In-Reply-To: <550315A1.4090607@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 17:16:38 -0000 Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, March 13, 2015 9:52 AM > To: Templin, Fred L; Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbiddin= g LL away >=20 > Hi Fred, >=20 > Le 13/03/2015 17:43, Templin, Fred L a =E9crit : > > Hi Alex, > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, March 13, 2015 > >> 9:32 AM To: Templin, Fred L; Mikael Abrahamsson Cc: > >> v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in > >> IPv6? - RFCs forbidding LL away > >> > >> Le 13/03/2015 17:22, Templin, Fred L a =E9crit : > >>> Hi, > >>> > >>> I am way out of context on this thread, but I wanted to ask the > >>> following. It should be OK for a router to leave some of its > >>> links as link-local-only as long as the router has at least one > >>> GUA that it can use as the source address of any ICMPs it needs > >>> to send - right? > >> > >> I think yes, that would be sufficient to respect RFCs. > >> > >> And yes, it makes ok to talk about ll-only links on which > >> traceroute still works (even though it reports the GUA not the > >> LL). > >> > >> It would not help traceroute to display LL addresses. > >> > >> It would mean to ifconfig the same GUA on several of its > >> interfaces; if so the interface would no longer be LL-only, > >> although the other side of a link may be LL-only. That link would > >> be a link half-ll-only, or 'half-unnumbered' if I can say so. > > > > I am thinking of a router that pins a GUA on some sort of internal > > virtual interface (like a loopback) but leaves all of its other > > interfaces as link local only. Do you see a problem with that? >=20 > I don't see a problem with that. These would be LL-only links, although > the Routers themselves have GUAs. The routing would work. >=20 > I am not sure though what will be the src address of this > HOP_COUNT_EXCEEDED ICMP message - the GUA pinned on the virtual > interface? Or the LL address on the real interface? Would have to be the GUA, I guess. I think all of this is explained in a source address selection document somewhere (someone mentioned RFC6724) - I just wanted to be sure the use case was not being deprecated. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Thanks - Fred fred.l.templin@boeing.com > > > >> Alex > >> > >>> > >>> Thanks - Fred fred.l.templin@boeing.com > >>> > >>>> -----Original Message----- From: v6ops > >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru > >>>> Petrescu Sent: Friday, March 13, 2015 9:15 AM To: Mikael > >>>> Abrahamsson Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we > >>>> use "unnumbered" in IPv6? - RFCs forbidding LL away > >>>> > >>>> Le 13/03/2015 13:42, Mikael Abrahamsson a =E9crit : > >>>>> On Fri, 13 Mar 2015, Alexandru Petrescu wrote: > >>>>> > >>>>>> On this particular point. > >>>>>> > >>>>>> Le 12/03/2015 18:52, Owen DeLong a =E9crit : [...] > >>>>>>> So, traceroute may report whatever it receives, but it > >>>>>>> CANNOT receive a packet with a LL Source address from a > >>>>>>> non-adjacent router unless all of the routers in between > >>>>>>> violate the RFCs regarding forwarding of LL packets. > >>>>>> > >>>>>> For example RFC4291 "Addr Architecture" forbids packets > >>>>>> with src or dst address to get away from a link. It > >>>>>> literraly says "Routers must not forward any packets with > >>>>>> Link-Local source or destination addresses to other > >>>>>> links." > >>>>>> > >>>>>> Whereas the dst part reads best, I wonder whether the src > >>>>>> part does not amount a bit to ingress filtering. Ingress > >>>>>> filtering is a policy useful in some security context, but > >>>>>> is also seen as a bad technique that needs to be overcome > >>>>>> by some other technique. Ingress filtering would not be > >>>>>> part of architectural thinking, but of policy thinking. > >>>>>> > >>>>>> There may be, in some context, a need of a packet with a > >>>>>> LL src address and a GUA dst address. This packet would > >>>>>> be forwarded by routers, although they may log it as an > >>>>>> exceptional case. But it should not be dropped. > >>>>> > >>>>> Yes it should. RFC4291 says it MUST be dropped, with very > >>>>> good reason. We do not want LL (src or dst) packets being > >>>>> routed around. > >>>> > >>>> It's a good principle, one of the few still resisting to > >>>> exceptions. > >>>> > >>>> Maybe one thinks that lack of uniqueness guarantees by > >>>> administrative allocation, and lack of same-scope equipotency, > >>>> may induce harm when forwarding LL-src packets. > >>>> > >>>> Yet packets with src ULA and dst GUA _are_ routed around. > >>>> > >>>> Packets with src unicast and dst multicast _are_ routed > >>>> around. > >>>> > >>>> Packets with src LL and dst GUA multiple hops away from that > >>>> link can be helpful to some applications not needing replies > >>>> (e.g. periodic beacons of routing protocols, or of tunnel > >>>> maintenance, or of NAT-state maintenance during traversal). > >>>> > >>>> I'd go as far as saying that packets with dst LL which is _one_ > >>>> hop away should be forwarded, because the Router is able to > >>>> detect address collisions on both its links. Beyond one hop it > >>>> would be a problem, but forwarding LL across one hop should not > >>>> break anything. > >>>> > >>>> Alex > >>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ v6ops mailing > >>>> list v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops > >>> > >>> > >> > > > > > > >=20 From nobody Fri Mar 13 10:24:29 2015 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 DE3811A906B for ; Fri, 13 Mar 2015 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 1kYvIfmC-b8R for ; Fri, 13 Mar 2015 10:24:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF651A9050 for ; Fri, 13 Mar 2015 10:24:25 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2DHNsS6000665; Fri, 13 Mar 2015 17:23:54 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t2DHNsS6000665 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1426267434; bh=CSK8VNMQ58ly3lhZU2Bqf3pk670=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=bsSasXowws7NYRqrhmURoroKHWl11fn65IydrUylv2YlyqLLpZ/vMbRWaUWQiq+wE 7j7BvLw2hp+k40IuO61cQYN/l71GCcKl2cXzazeTAp6W6THHNLZ18tbBrib4XJW/0W c/bGmfRHc+WvBAllyxDbaAEEE72f/iawLv+DpfFk= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id r2CHNs0944512449IY ret-id none; Fri, 13 Mar 2015 17:23:54 +0000 Received: from [IPv6:2001:630:d0:f111:eca5:b6c1:357a:21e5] ([IPv6:2001:630:d0:f111:eca5:b6c1:357a:21e5]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2DHNoBi024519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 17:23:50 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Chown In-Reply-To: <55030189.8010305@foobar.org> Date: Fri, 13 Mar 2015 17:23:51 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <54FF0602.40007@foobar.org> <5502DDE8.2040800@si6networks.com> <55030189.8010305@foobar.org> <5D985F7D-0C9D-4171-9B80-B794D9B83A0A@ecs.soton.ac.uk> To: Nick Hilliard X-Mailer: Apple Mail (2.2070.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r2CHNs094451244900; tid=r2CHNs0944512449IY; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t2DHNsS6000665 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 17:24:28 -0000 > On 13 Mar 2015, at 15:26, Nick Hilliard wrote: >=20 > On 13/03/2015 12:54, Fernando Gont wrote: >> For the results we've published in the I-D, the tests were performed >> from host Slovenia. Same results were obtained when redoing the tests >> from Brazil. >>=20 >> And measuring things from the UK, and even (distributed) with the = RIPE >> probes gives the same results. -- this is not surprising, since the >> drops do not happen close to the origin, but rather at the Dest AS or >> transit ASes. >=20 > ok great. I had assumed it was from multiple start points. The = source > ASNs and any filtering between the source hosts and the upstream links > (even if there is none) should be mentioned in the draft because it's = an > important part of the experiment methodology. I agree. And a very fair point. There may be commonalities to certain = points of origin. That said, it is possible to benchmark local filtering = by tests to specific external services that can be seen to work. I=E2=80=99d add that not all results are black and white. As an example, = you can see drop rates increase as certain header chain lengths = increase.=20 Perhaps we can further clarify the methodology in response to comments = so that we can have people run the tests from a wider set of observation = points. And/or release the code used. We have held bar BoFs between those running the experiments at previous = IETFs, e.g. London. We can do more of that too, if people are = interested. Tim= From nobody Fri Mar 13 10:42:04 2015 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 3E4A81A1BC9 for ; Fri, 13 Mar 2015 10:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 QozWTve9MDbU for ; Fri, 13 Mar 2015 10:42:02 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 3263A1A1B2C for ; Fri, 13 Mar 2015 10:42:02 -0700 (PDT) Received: by obcva2 with SMTP id va2so21304449obc.3 for ; Fri, 13 Mar 2015 10:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t/rFfS/XIDRSSLH/rFZpU7i6y1hys4ixXkajd2aPUgg=; b=JHlYIuY0mMX1k4+1wWh3r6CzmoYwkwAnqFafr+lrm6K6thqbt5tPHF1gYpSYqMsGF0 244elsgqDjwg47fqlftDbmdxgG/fa+LY3D2vYyvvoU4XBMdnD9zNBtsNRPidgudwIIfs Zm7a8M+4HKBtbd7cmgMyc8wPQxqJLOgn8ozdM= 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-type; bh=t/rFfS/XIDRSSLH/rFZpU7i6y1hys4ixXkajd2aPUgg=; b=SlGBq04xi2k4hNyIZ9bb3yknu/UoUuHK59YoN/GxsoMl8C7UosB+0G4f05dsq1IGV7 CAhD4Tg7/N1zI0I0+lSJkwDBYWZNcr/XN83a7shBuM4CKIxm2B7uwcK/LeC1QvxL+0ZW 32H/5pIo5PdDMs9c8wU19+cnNN7sHDDAtGL8d6qNpzAoYLg2uqA5KxHZy0G/YmMoTkkJ PAWJBpo0lCndUzhaz7mhYzJ+bX9eN17hST/cvWzcmEeyby0x3+PELxg6z+qXH0D8fJGB T2keYy7fSyR876Idcf/wiaGel4gIJuV1Bw4yRQXMTcyt8tITDBYtkUXB3N7NDXjUvjQu 6AZg== X-Gm-Message-State: ALoCoQkeUmSHXRyYym5vN8WSBga0KzI2oQonIGiVND7sTnLVssq5b49WwDxcFhuGJ2SrN3U51j4e MIME-Version: 1.0 X-Received: by 10.202.95.2 with SMTP id t2mr36855057oib.104.1426268521495; Fri, 13 Mar 2015 10:42:01 -0700 (PDT) Received: by 10.76.150.2 with HTTP; Fri, 13 Mar 2015 10:42:01 -0700 (PDT) In-Reply-To: <20150313103615.1380aeb1@echo.ms.redpill-linpro.com> References: <20150313103615.1380aeb1@echo.ms.redpill-linpro.com> Date: Fri, 13 Mar 2015 10:42:01 -0700 Message-ID: From: James Woodyatt To: Tore Anderson Content-Type: multipart/alternative; boundary=001a113cdcce941b7905112f04d2 Archived-At: Cc: jool@nic.mx, IPv6 Ops WG , draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org Subject: Re: [v6ops] Stateful NAT64: Strange translation of ICMPv4 error source addresses 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: Fri, 13 Mar 2015 17:42:03 -0000 --001a113cdcce941b7905112f04d2 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 13, 2015 at 2:36 AM, Tore Anderson wrote: > > Stateful NAT64 (RFC6146) requires that whenever an ICMPv4 error is > received from a router in the IPv4 network, the (IPv4-converted) IPv6 > source address of the translated ICMPv6 error must be set to the > (IPv4-converted) address of the destination address in the embedded > ICMPv4 payload, i.e., the original destination of the packet causing > the ICMPv4 error. I find this rather counter-intuitive - I would expect > the (IPv4-converted) address of the IPv4 router originating the ICMPv4 > error to be used instead. Is my reading of RFC6146 faulty, or if not, > is this truly the intented behaviour (why?), or is an erratum warranted? > For what it's worth, I would find this counter-intuitive too, and I'd be surprised if this is really the intended behavior. Hopefully, the authors of the RFC will respond. -- james woodyatt Nest Labs, Communications Engineering --001a113cdcce941b7905112f04d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 13, 2015 at 2:36 AM, Tore Anderson <tore@fud.no> wrote:

Stateful NAT64 (RFC6146) requires that whenever an ICMPv4 error is
received from a router in the IPv4 network, the (IPv4-converted) IPv6
source address of the translated ICMPv6 error must be set to the
(IPv4-converted) address of the destination address in the embedded
ICMPv4 payload, i.e., the original destination of the packet causing
the ICMPv4 error. I find this rather counter-intuitive - I would expect
the (IPv4-converted) address of the IPv4 router originating the ICMPv4
error to be used instead. Is my reading of RFC6146 faulty, or if not,
is this truly the intented behaviour (why?), or is an erratum warranted?

For what it's worth, I would find this counter-intuitive too, a= nd I'd be surprised if this is really the intended behavior. Hopefully,= the authors of the RFC will respond.


--
james woodyatt <= jhw@nestlabs.com&= gt;
Nest Labs, Communications Engineering
--001a113cdcce941b7905112f04d2-- From nobody Fri Mar 13 11:03:17 2015 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 D4F161A1BC9 for ; Fri, 13 Mar 2015 11:03:15 -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 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 yXL0ZQgQGIQo for ; Fri, 13 Mar 2015 11:03:14 -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 AD8461A1A63 for ; Fri, 13 Mar 2015 11:03:13 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t2DI3CoS008842 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 18:03:13 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <5503265E.1060201@foobar.org> Date: Fri, 13 Mar 2015 18:03:10 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Gert Doering References: <550020EC.1080907@foobar.org> <643679624.44423.1426203835721.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <643679624.44423.1426203835721.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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: Fri, 13 Mar 2015 18:03:16 -0000 On 12/03/2015 23:43, Mark ZZZ Smith wrote: > If you don't ensure clarity and accuracy, simple misunderstandings can > have catastrophic consequences : For sure, yes. I'm just suggesting that 70 emails to discuss this topic so far (13 emails in the original thread and 57 emails so far in this thread) is bike-shedding. Nick From nobody Fri Mar 13 12:35:25 2015 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 8D6621A0137 for ; Fri, 13 Mar 2015 12:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iDytykoySFFd for ; Fri, 13 Mar 2015 12:35:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A6EE51A00F5 for ; Fri, 13 Mar 2015 12:35:21 -0700 (PDT) Received: from [IPv6:2620::930:0:1064:285c:7738:11b0] ([IPv6:2620:0:930:0:1064:285c:7738:11b0]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2DJUUG0007772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Mar 2015 12:30:30 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2DJUUG0007772 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426275030; bh=1awKu/plpshXSh/lVwknzs7w+sQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bqx3BhDiLjJmhDrJkAFJQDlqnc7ffm/Us0WdHGh6wbIlaS+DsK5V5Ld11li9ECO1o K4gEs/m2LSEqPJ7xfygWmcIK9VoW76iK+xgdfe/hMvVJENAVqGrWwYWiuT1tj64pks xuFw6baIyPQhsg/+TykkZn9kKRAJ1GHInMnOBlOw= Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (12B466) In-Reply-To: <5502CAF1.8070109@gmail.com> Date: Fri, 13 Mar 2015 12:30:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0DE4746B-4456-4141-9B70-157D41EB56DE@delong.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <390784307.3215428.1426033376902.JavaMail.yahoo@mail.yahoo.com> <54FFF1FE.7070900@iridiumlinux.org> <7556A094-8C7D-4128-A313-7EF8574901B7@delong.com> <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <8A27F909-4176-4F63-830F-D422B17C16AD@delong.com> <5502CAF1.8070109@gmail.com> To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 13 Mar 2015 12:30:30 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - traceroute is not a reason for mandatory GUA 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: Fri, 13 Mar 2015 19:35:24 -0000 > On Mar 13, 2015, at 04:33, Alexandru Petrescu wrote: >=20 > Le 12/03/2015 18:40, Owen DeLong a =A8=A6crit : >> [snip] >>=20 >>>>=20 >>>> I=A1=AFm not saying interfaces shouldn=A1=AFt have a link local address= . >>>> (jeez.) >>>>=20 >>>> I=A1=AFm saying that not puting a real address on a link that shows >>>> up in traceroutes is a bad idea. >>>=20 >>> Yes and no. >>>=20 >>> YEs, we want traceroute to report an address of a hop, rather than >>> a three-star string "* * *=A1=B1. >>=20 >> No=A1=AD We want traceroute to report an address of a hop that has a >> valid binding in ip6.arpa that tells people something meaningful >> about the hop, and, ideally, the interface of arrival at said hop. >>=20 >>> But traceroute should be able to report link-local addresses, and >>> ULAs, as well. If it doesnt then it's a problem of that >>> traceroute program. >>=20 >> See above. Merely reporting an address that is utterly and >> completely meaningless outside of the zone of administrative control >> (ULA) or outside of the local link (LL) is less than helpful. >=20 > It depends what is in that address. It's its scope which does not matter.= You are stubbornly determined to ignore the facts of the situation.=20 It is impossible to get ip6.arpa information for ULA or LL outside of a narr= ow administrative scope. Further, it is impossible to receive a hop-count-ex= ceeded message from a non-adjacent router using a LL address.=20 As such, scope very much matters.=20 >=20 >>> If an enduser needs rather globally-scoped and unique (rathern >>> than LL and ULA) addresses in traceroute outputs then one should >>> ask her why? Be them globally-scoped and unique they dont tell >>> anything useful to a human user of traceroute. They surely dont >>> tell _where_ these addresses are (like in 'what country=A1=AF). >>=20 >> Well, the address being GUA alone is not the complete solution, but >> it is certainly a necessary component. >=20 > The address being a GUA (and not a LL) is an artifact of porting > traceroute from IPv4 to IPv6. A native IPv6 traceroute would report LLs > as well. And be ported back to IPv4 to report IPv4 LLs. See above and multiple previous messages which have explained in detail why y= ou are wrong about this.=20 >=20 >> Obviously, the next step is to provide a useful mapping in ip6.arpa >> as well. >=20 > Yes. >=20 >> For example: >>=20 >> owen.delong.com:owen /home4/owen (29) % traceroute6 www.facebook.com >> traceroute to www.facebook.com >> (2a03:2880:10:cf07:face:b00c:0:1), 30 hops >> max, 80 byte packets 1 2620:0:930:0:2e6b:f5ff:fe03:a80 >> (2620:0:930:0:2e6b:f5ff:fe03:a80) 1.788 ms 1.777 ms 1.787 ms 2 >> owen-2.tunnel.tserv2.fmt.ipv6.he.net >> (2001:470:1f03:9c::1) 12.973 ms 19.452 ms 20.374 ms 3 >> ge4-22.core2.fmt1.he.net >> (2001:470:0:1f::1) 28.750 ms 29.679 ms 29.739 ms 4 >> ge5-15.core1.fmt2.he.net >> (2001:470:0:1bc::1) 20.313 ms 20.331 ms 20.337 ms 5 >> 10ge1-1.core1.sjc2.he.net >> (2001:470:0:31::2) 20.332 ms * * 6 * >> facebook.gige-g5-9.core1.sjc2.he.net >> (2001:470:0:14a::2) 18.399 ms 18.371 ms 7 ae1.bb03.sjc1.tfbnw.net >> (2620:0:1cff:dead:beef::c5a) 18.370 >> ms 24.237 ms 14.423 ms 8 ae24.bb04.prn2.tfbnw.net >> (2620:0:1cff:dead:beef::c32) 33.334 >> ms 32.289 ms 33.340 ms 9 ae4.dr05.prn1.tfbnw.net >> (2620:0:1cff:dead:beef::68d) 39.411 >> ms ae13.dr05.prn1.tfbnw.net >> (2620:0:1cff:dead:beef::69d) 39.557 ms ae4.dr02.prn1.tfbnw.net >> (2620:0:1cff:dead:beef::69b) 38.365 >> ms 10 po1019.csw12a.prn1.tfbnw.net >> (2620:0:1cff:dead:beef::1769) >> 48.094 ms po1021.csw12d.prn1.tfbnw.net >> (2620:0:1cff:dead:beef::1785) >> 39.399 ms po1019.csw12b.prn1.tfbnw.net >> (2620:0:1cff:dead:beef::1775) >> 39.348 ms 11 * * * 12 edge-star6-shv-12-prn1.facebook.com >> >> (2a03:2880:10:cf07:face:b00c:0:1) 37.765 ms 38.419 ms 36.471 ms >>=20 >>=20 >> Hop 1 doesn=A1=AFt provide useful information, but it=A1=AFs the SLAAC ad= dress >> of the interior side of a local router, >=20 > You see, why do you call it a SLAAC address? >=20 > It's unsafe to assume ff:fe and global prefix means SLAAC. It's my device and I know that the address was generated using SLAAC. NO ass= umption involved, I configured it that way.=20 >=20 > The randomly generated addresses, the DHCP, or the imaginative > sysadmins, may have put the same ff:fe in there. ff:fe is not forbidden > to DHCP, to sysadmins and to the random generation of privacy addresses. I never said it was.=20 >=20 >> so it=A1=AFs only going to be seen on outbound traceroutes from my small >> site. >>=20 >> The other hops do provide useful ip6.arpa mappings (with the obvious >> exception of hop 11 which doesn=A1=AFt respond at all, probably a load >> balancer at FB). >>=20 >> I can tell from the information provided by the various operators >> that my packet is delivered to an HE tunnelserver in their Fremont 1 >> datacenter, then forwarded to a core router in that same datacenter, >> over to their Fremont 2 datacenter, etc. >=20 > Except that traceroute does not tell for each tunnel its 4 addresses. So what? It gives me enough information to identify the tunnel specifically.= If I need more, I can find the tunnel configure with all four addresses usi= ng any one of the addresses.=20 >=20 >> I can even tell that on the core router in Fremont 1, my packet >> arrived on gigabit ethernet interface card 4 port 22. I can also see >> interface information on the remaining hops as well. >>=20 >> The vast majority of providers put this information into ip6.arpa to >> make their lives easier when it comes to troubleshooting, but it also >> happens to make life easier for external users as well. >=20 > Ok. >=20 >>> An address present in a traceroute output tells many things _if_ >>> that end user has an mental association of the address set >>> out-of-band (like "all addresses starting 2a02 belong to the >>> operator I trust"). But these out-of-band associations have no >>> requirement whatsoever on the scope of the address, or its >>> uniqueness across Internet, or prefix-middle-suffix position of >>> the trusted incantation. One could very well have fe80:X:1 >>> displayed by traceroute, and know out-of-band that when X is in the >>> address then the operator is trusted. (e.g. X=3D=3Dface:b00c). >>=20 >> Actually, they do. >>=20 >> If I build a mental association of =A1=B0all addresses starting with >> fd0c:face:b00c::=A1=B1 belong to Face Book, not only am I an idiot for >> trusting some sort of association between ULA and a particular >> organization, but I=A1=AFm also quite likely to be wrong some significant= >> portion of the time. >=20 > You make a good supposition. There is no guarantee but it's likely to be t= he case. It's the same level of confidence in assuming 2a01:face:b00c:: bel= ongs to facebook. The scope does not matter, there is no difference between= global or local scope. Actually, I'm pretty confident that 2a01:face:b00c:: does not at all belong t= o Face Book. According to RIPE, that range is not assigned to anyone.=20 Scope does matter. There is no reliable registry for LL or ULA. There is no g= uarantee of uniqueness for ULA and LL is virtually guaranteed to be duplicat= ed elsewhere.=20 On the other hand, I know with great certainty that 2620:0:930:: is DELONG a= nd 2001:470:: is Hurricane Electric (or their customers).=20 That's the whole point of GUA and the RIR system.=20 >=20 >>> Besides, traceroute output is hugely more meaningful when it does >>> not display addresses but FQDNs. These FQDNs have nothing to do >>> with address scope either. >>=20 >> Yes, they do. You can=A1=AFt (legitimately) create externally visible >> ip6.arpa records for addresses that are not GUA scoped. If you think >> that you can, please share whatever you are smoking. >=20 > Do you mean that DNS requests are blocked if the parameter starts with "fe= 80"? I mean that nobody at the root is going to delegate any portion of 0.e.8.f.i= p6.arpa to you.=20 Whatever you put in your server is meaningless outside of your zone of contr= ol unless it is delegated from the root.=20 It really would be good if you made the effort to understand how DNS, trace r= oute, ULA, and Link Local actually work before going another round in this c= onversation. It is clear from your statements that you have some incorrect a= ssumptions at least.=20 Owen From nobody Fri Mar 13 13:59:40 2015 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 0B4FF1A87C2 for ; Fri, 13 Mar 2015 13:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 rNkn9ZKvqcHN for ; Fri, 13 Mar 2015 13:59:38 -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 2D4F41A037D for ; Fri, 13 Mar 2015 13:59:37 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id ED91B62A6D for ; Fri, 13 Mar 2015 21:59:35 +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 B20F96091D for ; Fri, 13 Mar 2015 21:59:35 +0100 (CET) Received: (qmail 17420 invoked by uid 1007); 13 Mar 2015 21:59:35 +0100 Date: Fri, 13 Mar 2015 21:59:35 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150313205935.GK54385@Space.Net> References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <55018CAA.7010104@gmail.com> <5502CCF3.1020804@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5502CCF3.1020804@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] Should we use "unnumbered" in IPv6? - traceroute 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: Fri, 13 Mar 2015 20:59:40 -0000 Hi, On Fri, Mar 13, 2015 at 12:41:39PM +0100, Alexandru Petrescu wrote: > Ok, but I will refrain from further commenting Very much appreciated. Thanks. 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 13 14:09:57 2015 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 A5A2F1A6F87 for ; Fri, 13 Mar 2015 14:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 hvf3K_KpGpjO for ; Fri, 13 Mar 2015 14:09:53 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 94FAF1A00CD for ; Fri, 13 Mar 2015 14:09:53 -0700 (PDT) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YWWq3-0007ix-FP; Fri, 13 Mar 2015 22:09:51 +0100 Message-ID: <550350B1.7070700@si6networks.com> Date: Fri, 13 Mar 2015 22:03:45 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nick Hilliard , Fernando Gont , "v6ops@ietf.org" References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <54FF0602.40007@foobar.org> <5502DDE8.2040800@si6networks.com> <55030189.8010305@foobar.org> In-Reply-To: <55030189.8010305@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 13 Mar 2015 21:09:55 -0000 Nick, On 03/13/2015 04:26 PM, Nick Hilliard wrote: > On 13/03/2015 12:54, Fernando Gont wrote: >> For the results we've published in the I-D, the tests were performed >> from host Slovenia. Same results were obtained when redoing the tests >> from Brazil. >> >> And measuring things from the UK, and even (distributed) with the RIPE >> probes gives the same results. -- this is not surprising, since the >> drops do not happen close to the origin, but rather at the Dest AS or >> transit ASes. > > ok great. I had assumed it was from multiple start points. FWIW, a much more distributed set of measurements (with RIPE Atlas) were done, and the results were along the same lines. > The source > ASNs and any filtering between the source hosts and the upstream links > (even if there is none) should be mentioned in the draft because it's an > important part of the experiment methodology. FWIW, while not included in the I-D, for the measurements included in the I-D we also measured the number of hops from the Destination system where the packet drop occurs, etc. And the filtering does not hppen at the source. That why reproducing the measurements form a different location (or doing a more distributed set of measurements with RIPE Atlas doesn't get you different results). Thanks! Cheers, -- 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 13 15:22:45 2015 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 38B6E1A89AE for ; Fri, 13 Mar 2015 15:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 njFu4DrCRMSC for ; Fri, 13 Mar 2015 15:22:42 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD8C1A89E1 for ; Fri, 13 Mar 2015 15:22:41 -0700 (PDT) Received: from [IPv6:2620::930:0:1064:285c:7738:11b0] ([IPv6:2620:0:930:0:1064:285c:7738:11b0]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2DMKRv3015255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Mar 2015 15:20:27 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2DMKRv3015255 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426285227; bh=KAE51/GxETzBda2DHum5ynIRKxI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EfBFp+TcK7BUe04MQHMz9z6/nOA1RWCQRo9p0VbkkVQeU70Gee/IDBY0KvGMpN6b/ fW/gfA72BQCyij7TVf47dhd26LfNrUGBWJPToK0OPm4tmtIaeaIGFzQwbxjy7C3z3i KrsuZmuPYEh7vcZyhXxMAyRH2CZwhgHgg9x0pqOE= Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (12B466) In-Reply-To: <5502CFA6.70503@gmail.com> Date: Fri, 13 Mar 2015 15:20:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502CFA6.70503@gmail.com> To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 13 Mar 2015 15:20:27 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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: Fri, 13 Mar 2015 22:22:43 -0000 > On Mar 13, 2015, at 04:53, Alexandru Petrescu wrote: >=20 > Le 12/03/2015 20:25, Metzler, Dan J a =A8=A6crit : >> I don't understand this discussion. I thought the topic was a >> terminology discussion about whether to use the term "un-numbered" >> when referring to an interface that only has a link-local address. >=20 > My point was to say that traceroute needing GUAs should not mean the > links without GUAs (hence 'unnumbered') should not exist. >=20 > To put it other way, links without GUAs are there, and a name for them > shoudl be found. Link local only seems a perfectly valid term.=20 Such links should be discouraged if they handle non-local traffic, however.=20= Owen From nobody Fri Mar 13 15:27:22 2015 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 625DF1A066B for ; Fri, 13 Mar 2015 15:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 SUS-v7SmVLpx for ; Fri, 13 Mar 2015 15:27:20 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 735651A0072 for ; Fri, 13 Mar 2015 15:27:20 -0700 (PDT) Received: from [IPv6:2620::930:0:1064:285c:7738:11b0] ([IPv6:2620:0:930:0:1064:285c:7738:11b0]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2DMOjFU015871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Mar 2015 15:24:45 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2DMOjFU015871 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426285488; bh=c92PSfAdJdWTCDtI1fUUlP9qBh8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MpUHcR1aikYqteg+nCruXHhISyjbgJtqsq3wr4twVOtjliUU6mJIdUc6sa1S630JN i2hdFna7ZpOnmzt+F/DnPVm04gH+Z9Rr1GCg8P11ZElXUV7OOAuFI8qpf88+AYFg55 nHqqLquvtZX23RxddhUBgGKYFl85XzC3cKarUEXo= Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (12B466) In-Reply-To: <5502D849.90101@gmail.com> Date: Fri, 13 Mar 2015 15:24:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1D709C77-9FD7-4459-ABEA-2EE15CEADB53@delong.com> References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 13 Mar 2015 15:24:48 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 22:27:21 -0000 > On Mar 13, 2015, at 05:30, Alexandru Petrescu wrote: >=20 > On this particular point. >=20 > Le 12/03/2015 18:52, Owen DeLong a =A8=A6crit : > [...] >> So, traceroute may report whatever it receives, but it CANNOT receive >> a packet with a LL Source address from a non-adjacent router unless >> all of the routers in between violate the RFCs regarding forwarding >> of LL packets. >=20 > For example RFC4291 "Addr Architecture" forbids packets with src or dst > address to get away from a link. It literraly says "Routers must not > forward any packets with Link-Local source or destination addresses to > other links." >=20 > Whereas the dst part reads best, I wonder whether the src part does not > amount a bit to ingress filtering. Ingress filtering is a policy useful > in some security context, but is also seen as a bad technique that needs > to be overcome by some other technique. Ingress filtering would not be > part of architectural thinking, but of policy thinking. Nope. It is well considered architectural thinking.=20 A packet which is global in scope should come from a host which can be reach= ed globally and an address which has a valid global registration in an RIR d= atabase.=20 >=20 > There may be, in some context, a need of a packet with a LL src address > and a GUA dst address. This packet would be forwarded by routers, > although they may log it as an exceptional case. But it should not be > dropped. There is not. In fact, allowing such a thing is a terrible idea for many rea= sons which were discussed at length years ago.=20 >=20 > If this were done, then maybe traceroute programs which rely on the > chance of HOP_COUNT_EXCEEDED would report LLs as well. While it would enable this particular possibility of dubious benefit at best= , I would hold that possibility out as more of a reason not to do so than a r= eason to do so.=20 Owen From nobody Fri Mar 13 15:32:32 2015 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 5E7C31A8723 for ; Fri, 13 Mar 2015 15:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 qa8Nyz_To5p4 for ; Fri, 13 Mar 2015 15:32:28 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E96291A066B for ; Fri, 13 Mar 2015 15:32:27 -0700 (PDT) Received: from [IPv6:2620::930:0:1064:285c:7738:11b0] ([IPv6:2620:0:930:0:1064:285c:7738:11b0]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2DMRuHD016636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Mar 2015 15:27:56 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2DMRuHD016636 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1426285677; bh=dklVKYad8fH03ur5e0qhZs/xjlU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TYtBfoYJAt6Y+BShX70AD8MefOdTSY2TR3t+BQ46joXULIDfo69dtZ7JR1Nty0uml DcK575pm+wSSVr07W7lUFYxRYlSwt897eFPVIKlJLE2LpQnri/1lHbgeZFURvI4Nk9 yMUDX6/R+LN3i0p94R0+8ZxlY4UTiMINKrsioN/g= Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (12B466) In-Reply-To: <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 13 Mar 2015 15:27:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 13 Mar 2015 15:27:57 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 22:32:29 -0000 Depends on your meaning of OK.=20 It is technically permissible by the RFCs, but it's generally a bad idea as i= t creates ambiguities in diagnostic processes which are usually harmful.=20 Unless you have some overriding benefit or reason for it, I think best pract= ice is unique GUA per interface.=20 Owen > On Mar 13, 2015, at 09:22, Templin, Fred L wro= te: >=20 > Hi, >=20 > I am way out of context on this thread, but I wanted to ask the > following. It should be OK for a router to leave some of its links as > link-local-only as long as the router has at least one GUA that it can > use as the source address of any ICMPs it needs to send - right? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petres= cu >> Sent: Friday, March 13, 2015 9:15 AM >> To: Mikael Abrahamsson >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbiddin= g LL away >>=20 >> Le 13/03/2015 13:42, Mikael Abrahamsson a =A8=A6crit : >>> On Fri, 13 Mar 2015, Alexandru Petrescu wrote: >>>=20 >>>> On this particular point. >>>>=20 >>>> Le 12/03/2015 18:52, Owen DeLong a =A8=A6crit : [...] >>>>> So, traceroute may report whatever it receives, but it CANNOT >>>>> receive a packet with a LL Source address from a non-adjacent >>>>> router unless all of the routers in between violate the RFCs >>>>> regarding forwarding of LL packets. >>>>=20 >>>> For example RFC4291 "Addr Architecture" forbids packets with src >>>> or dst address to get away from a link. It literraly says >>>> "Routers must not forward any packets with Link-Local source or >>>> destination addresses to other links." >>>>=20 >>>> Whereas the dst part reads best, I wonder whether the src part >>>> does not amount a bit to ingress filtering. Ingress filtering is >>>> a policy useful in some security context, but is also seen as a >>>> bad technique that needs to be overcome by some other technique. >>>> Ingress filtering would not be part of architectural thinking, but >>>> of policy thinking. >>>>=20 >>>> There may be, in some context, a need of a packet with a LL src >>>> address and a GUA dst address. This packet would be forwarded by >>>> routers, although they may log it as an exceptional case. But it >>>> should not be dropped. >>>=20 >>> Yes it should. RFC4291 says it MUST be dropped, with very good >>> reason. We do not want LL (src or dst) packets being routed around. >>=20 >> It's a good principle, one of the few still resisting to exceptions. >>=20 >> Maybe one thinks that lack of uniqueness guarantees by administrative >> allocation, and lack of same-scope equipotency, may induce harm when >> forwarding LL-src packets. >>=20 >> Yet packets with src ULA and dst GUA _are_ routed around. >>=20 >> Packets with src unicast and dst multicast _are_ routed around. >>=20 >> Packets with src LL and dst GUA multiple hops away from that link can be >> helpful to some applications not needing replies (e.g. periodic beacons >> of routing protocols, or of tunnel maintenance, or of NAT-state >> maintenance during traversal). >>=20 >> I'd go as far as saying that packets with dst LL which is _one_ hop away >> should be forwarded, because the Router is able to detect address >> collisions on both its links. Beyond one hop it would be a problem, but >> forwarding LL across one hop should not break anything. >>=20 >> Alex >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Mar 13 15:36:07 2015 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 C59FD1A0217 for ; Fri, 13 Mar 2015 15:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jfB_IW5iLwok for ; Fri, 13 Mar 2015 15:36:03 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73C71A8735 for ; Fri, 13 Mar 2015 15:36:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2DMa2Xd031480; Fri, 13 Mar 2015 15:36:02 -0700 Received: from XCH-BLV-408.nw.nos.boeing.com (xch-blv-408.nw.nos.boeing.com [130.247.25.166]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2DMa0VI031472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 13 Mar 2015 15:36:01 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.179]) with mapi id 14.03.0210.002; Fri, 13 Mar 2015 15:36:00 -0700 From: "Templin, Fred L" To: Owen DeLong Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away Thread-Index: AQHQXaj64x+tAUa03UWC/53Dv/6hxp0al5nwgADcVQD//4wosA== Date: Fri, 13 Mar 2015 22:36:00 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E1CFF7@XCH-BLV-504.nw.nos.boeing.com> References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Fri, 13 Mar 2015 22:36:05 -0000 Hi Owen, > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Friday, March 13, 2015 3:28 PM > To: Templin, Fred L > Cc: Alexandru Petrescu; Mikael Abrahamsson; v6ops@ietf.org > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbiddin= g LL away >=20 > Depends on your meaning of OK. >=20 > It is technically permissible by the RFCs, but it's generally a bad idea = as it creates ambiguities in diagnostic processes which are usually > harmful. >=20 > Unless you have some overriding benefit or reason for it, I think best pr= actice is unique GUA per interface. AERO is an example of a link-local-only link. IPv6 addresses and prefixes a= re assigned *through* the link, and not *to* the link. Which should be fine as long as = all AERO routers have at least one GUA they can use for diagnostic purposes, right? Thanks - Fred fred.l.templin@boeing.com =20 > Owen >=20 >=20 >=20 >=20 > > On Mar 13, 2015, at 09:22, Templin, Fred L = wrote: > > > > Hi, > > > > I am way out of context on this thread, but I wanted to ask the > > following. It should be OK for a router to leave some of its links as > > link-local-only as long as the router has at least one GUA that it can > > use as the source address of any ICMPs it needs to send - right? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Pet= rescu > >> Sent: Friday, March 13, 2015 9:15 AM > >> To: Mikael Abrahamsson > >> Cc: v6ops@ietf.org > >> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbid= ding LL away > >> > >> Le 13/03/2015 13:42, Mikael Abrahamsson a =E9crit : > >>> On Fri, 13 Mar 2015, Alexandru Petrescu wrote: > >>> > >>>> On this particular point. > >>>> > >>>> Le 12/03/2015 18:52, Owen DeLong a =E9crit : [...] > >>>>> So, traceroute may report whatever it receives, but it CANNOT > >>>>> receive a packet with a LL Source address from a non-adjacent > >>>>> router unless all of the routers in between violate the RFCs > >>>>> regarding forwarding of LL packets. > >>>> > >>>> For example RFC4291 "Addr Architecture" forbids packets with src > >>>> or dst address to get away from a link. It literraly says > >>>> "Routers must not forward any packets with Link-Local source or > >>>> destination addresses to other links." > >>>> > >>>> Whereas the dst part reads best, I wonder whether the src part > >>>> does not amount a bit to ingress filtering. Ingress filtering is > >>>> a policy useful in some security context, but is also seen as a > >>>> bad technique that needs to be overcome by some other technique. > >>>> Ingress filtering would not be part of architectural thinking, but > >>>> of policy thinking. > >>>> > >>>> There may be, in some context, a need of a packet with a LL src > >>>> address and a GUA dst address. This packet would be forwarded by > >>>> routers, although they may log it as an exceptional case. But it > >>>> should not be dropped. > >>> > >>> Yes it should. RFC4291 says it MUST be dropped, with very good > >>> reason. We do not want LL (src or dst) packets being routed around. > >> > >> It's a good principle, one of the few still resisting to exceptions. > >> > >> Maybe one thinks that lack of uniqueness guarantees by administrative > >> allocation, and lack of same-scope equipotency, may induce harm when > >> forwarding LL-src packets. > >> > >> Yet packets with src ULA and dst GUA _are_ routed around. > >> > >> Packets with src unicast and dst multicast _are_ routed around. > >> > >> Packets with src LL and dst GUA multiple hops away from that link can = be > >> helpful to some applications not needing replies (e.g. periodic beacon= s > >> of routing protocols, or of tunnel maintenance, or of NAT-state > >> maintenance during traversal). > >> > >> I'd go as far as saying that packets with dst LL which is _one_ hop aw= ay > >> should be forwarded, because the Router is able to detect address > >> collisions on both its links. Beyond one hop it would be a problem, b= ut > >> forwarding LL across one hop should not break anything. > >> > >> Alex > >> > >> > >> > >> _______________________________________________ > >> 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 13 17:28:00 2015 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 90DCD1A8BB4 for ; Fri, 13 Mar 2015 17:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 S5zNHWdKMP9O for ; Fri, 13 Mar 2015 17:27:57 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 DF17D1A874D for ; Fri, 13 Mar 2015 17:27:56 -0700 (PDT) Received: by pabyw6 with SMTP id yw6so3669111pab.2 for ; Fri, 13 Mar 2015 17:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uEU8f7LvHSUNk9puDeO8x4UwN5q7YDZiPUxGYAz0Lfs=; b=epQPfXwOaXaKCcT+GPlHPgBqxG4WZhqCf5HpVcEyFX1nBTjSc2S64M29hiJxYuaC2/ UaHopqpejiEtpHUOvvGc7ixyOluQQd77wBSLFluiOKs9WDDBYxWwOJlGeZeEQ4WoIso0 xZIm1ni7OKjlPz8l1c/KqZvDmMat5T972bbPIc5OgwM+pgrAStocEc+4gZJsvT0Ov/Ad 9REo8ZBYnCUwSp1GO6nvsH7dKspN2CY7hpUZM7rMOs+OoqkvEoFhq+OTWMsaT1Uow0V2 4S3xshERlPnUnzpr8DK1ZI2fRRzHxoSfewtqH6gNjnTQ4fuGG+P/mKRS44rjNnm72J+j VtOA== X-Received: by 10.66.55.42 with SMTP id o10mr57847245pap.148.1426292876649; Fri, 13 Mar 2015 17:27:56 -0700 (PDT) Received: from ?IPv6:2406:e007:497e:1:28cc:dc4c:9703:6781? ([2406:e007:497e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id fz15sm5339666pdb.54.2015.03.13.17.27.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 17:27:55 -0700 (PDT) Message-ID: <55038095.3070109@gmail.com> Date: Sat, 14 Mar 2015 13:28:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Fernando Gont , Silvia Hagen , Nick Hilliard , Ole Troan References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <550212CB.2090306@foobar.org> <55021899.7080908@foobar.org> <5502E584.1080204@gont.com.ar> In-Reply-To: <5502E584.1080204@gont.com.ar> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 14 Mar 2015 00:27:58 -0000 On 14/03/2015 02:26, Fernando Gont wrote: > Hi, Silvia, > > On 03/13/2015 08:28 AM, Silvia Hagen wrote: >> I totally understand all those issues, limitations, practices and >> concerns. I am concerned about a tendency in the discussions to try >> to make up and adjust standards for vendor limitations, configuration >> issues, hardware bugs etc. And I think that is the wrong way to go. I >> do believe that when it comes to architectural things like EHs the >> working groups should stick to the design and the architecture and >> help and expect the market to implement it properly. It is not a >> working group/IETF problem if hardware have limitations, if firewall >> administrators decide to drop EHs etc.... We should stick to the >> original design and let this be their issue to solve by developing >> mechanisms which support the future protocol and its architecture. > > I sympathize with the idea. However, I should note that there are areas > where "proper implementation" doesn't seem to be on the horizon. > Specific example: support of IPv6 header chains of arbitrary lengths (at > least a packet full of EHs). And chip-level hardware designers will explain to you exactly why this is a painfully expensive thing to do at line speed. This stuff was designed by software people at the tail end of the 32-bit minicomputer era, and things looked different to them^H^H^H^Hus than they do to a 21st century chip designer. At some point we might get lucky and someone will actually design RFC 7045 chips... but remember that one of the things we had to put in that RFC was: The list of standard and experimental extension header types is maintained by IANA (see Section 4), and implementors are advised to check this list regularly for updates. Even when I drafted that, I could hear my chip designer friend laughing heartily. Brian > Most of the architectures I recall checking > enforce a limit on theIPv6 header chain. -- and it seems to be a > "chicken and egg" problem: It's hard to believe that a router vendor > will put money into something that is currently not required by any > protocols (in practice). And of course you cannot relly on such > full-sized EH chains if there's no support for them. > > FWIW, I'm not in favor of "banning" EHs, but I'm rather all for > improving the current state of affairs. > > Thanks, > From nobody Fri Mar 13 22:21:40 2015 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 841491AC3F1 for ; Fri, 13 Mar 2015 22:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tgTp5TjYIHlW for ; Fri, 13 Mar 2015 22:21:38 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40231AC3EF for ; Fri, 13 Mar 2015 22:21:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 60319A1; Sat, 14 Mar 2015 06:21:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1426310495; bh=xpHjnf91r5v/haFGmCia+BGtNr8L/tUUWIGDZm4V4Q8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vdicp6x4I4/+bfAkbVFIGEZc+j2qJ+mQTOOybAjRvV8QRhMmQRBLgyPMOD8o09W82 S3aBkxr4E+dqHR0aAnfs6r/cFgwTpD4CViVhqgpJE9/eUb8J6ksadkVSSoBKGGPyr7 jtFHT5tBfbyjNdI3PeI3mKYXYLaA7tWKTd2qLf+Q= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 548A59F; Sat, 14 Mar 2015 06:21:35 +0100 (CET) Date: Sat, 14 Mar 2015 06:21:35 +0100 (CET) From: Mikael Abrahamsson To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D9831832E1CFF7@XCH-BLV-504.nw.nos.boeing.com> Message-ID: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E1CFF7@XCH-BLV-504.nw.nos.boeing.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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, 14 Mar 2015 05:21:39 -0000 On Fri, 13 Mar 2015, Templin, Fred L wrote: > AERO is an example of a link-local-only link. IPv6 addresses and > prefixes are assigned *through* the link, and not *to* the link. Which > should be fine as long as all AERO routers have at least one GUA they > can use for diagnostic purposes, right? Yes. A router may use the weak host model to source packets with a loopback interface IP address that have a destination outside the directly connected interfaces which have LL only address. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Mar 15 16:06:48 2015 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 BD22B1A1BCD for ; Sun, 15 Mar 2015 16:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 J63_J8ADVSy9 for ; Sun, 15 Mar 2015 16:06:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2991A0334 for ; Sun, 15 Mar 2015 16:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=666; q=dns/txt; s=iport; t=1426460805; x=1427670405; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6OHOfzJF4EgDGcEmdyUowLs79u4Jthp1Fg2hktdlABI=; b=K7OAxwUjmK417MjeeSWO+eI5KA8pAmH2hOPLNtp37eT03nnD1Rb+18BS 3yi900V1bBp+JaXpXM8RcvkoxxaDOlNpCp09JfonxvPalvxNhnd7DhXXp 19A7W3m2vYm4u1NiyPTFGUu5vpplsuK8Oy05tpYWP8htWySZoKtXFlK6t U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D0BACNDwZV/5pdJa1bgwaBMIMGvxKHNwIceTgUAQEBAQEBAXyEEAEBBCMRRRACAQgYAgImAgICMBUQAgQOBYgvqxeYXgEBAQEBAQEBAQEBAQEBAQEBAQEZgSGJcYQ7GBsHgmiBQwEEj3aJRZNVI4Nub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,406,1422921600"; d="scan'208";a="132144719" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 15 Mar 2015 23:06:44 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2FN6imp014347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Mar 2015 23:06:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.127]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sun, 15 Mar 2015 18:06:44 -0500 From: "Eric Vyncke (evyncke)" To: "sthaug@nethelp.no" Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQXMB26HyQzIkkWE2xXEi7TL70yJ0ZHg6AgAVR5oA= Date: Sun, 15 Mar 2015 23:06:37 +0000 Message-ID: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> In-Reply-To: <20150312.134133.74704744.sthaug@nethelp.no> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.61.107.220] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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: Sun, 15 Mar 2015 23:06:46 -0000 T24gMTIvMDMvMTUgMTM6NDEsICJzdGhhdWdAbmV0aGVscC5ubyIgPHN0aGF1Z0BuZXRoZWxwLm5v PiB3cm90ZToNCj4+IFlFcywgd2Ugd2FudCB0cmFjZXJvdXRlIHRvIHJlcG9ydCBhbiBhZGRyZXNz IG9mIGEgaG9wLCByYXRoZXIgdGhhbiBhDQo+PiB0aHJlZS1zdGFyIHN0cmluZyAiKiAqICoiLg0K Pj4gDQo+PiBCdXQgdHJhY2Vyb3V0ZSBzaG91bGQgYmUgYWJsZSB0byByZXBvcnQgbGluay1sb2Nh bCBhZGRyZXNzZXMsIGFuZCBVTEFzLA0KPj4gYXMgd2VsbC4gIElmIGl0IGRvZXNudCB0aGVuIGl0 J3MgYSBwcm9ibGVtIG9mIHRoYXQgdHJhY2Vyb3V0ZSBwcm9ncmFtLg0KPg0KPk9mIGNvdXJzZSB0 cmFjZXJvdXRlIGNhbiByZXBvcnQgdGhlbS4gVGhleSBhcmUganVzdCBub3QgdmVyeSBoZWxwZnVs Lg0KDQpJZiBvbmx5IHJvdXRlcnMgYW5kIHRyYWNlIHJvdXRlcyBwcm9ncmFtcyBzdXBwb3J0ZWQg UkZDNTgzNy4uLiA7LSkNCg0KLcOpcmljDQoNCg== From nobody Sun Mar 15 16:06:50 2015 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 AAF3D1A0334 for ; Sun, 15 Mar 2015 16:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 EjVWuHtf3Rh7 for ; Sun, 15 Mar 2015 16:06:45 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9411A1BC6 for ; Sun, 15 Mar 2015 16:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7038; q=dns/txt; s=iport; t=1426460804; x=1427670404; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jWJs7U72RD35+Oo5cN3jhfCe8E/5aOYUWOKxgI9SCbE=; b=A2GFC+L8I/AX/c1o6J7wpi5oo83ppXhdL7lSNcd7vaydOwGgQAnZSdwF 9u1w2lvscB5fsiQXusPio73HjukqDueUGHzN38dyMX6dFGiAueJOjw1w+ NEutdZmvTgu1VqGesLtsPvo2YAccvXqYYMP2T0SSf9fxfggZddeW8cwaM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AyBQABDwZV/5RdJa1BGoMGUlUFBIMIwQUMhXICHHlMAQEBAQEBfYQPAQEBBAEBASAROgkSAgEIEQMBAgMCHwcCAgIlCxUICAIEARIJC4gbCAU3qlKaMgEBAQEBAQEBAgEBAQEBAQEBARmBIYl2hD4YIgaCYoFFBZA6g2uFe4EbOYJyglSGThCCVYNHI4ICHBSBPG8BEYEyfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,406,1422921600"; d="scan'208";a="132244623" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 15 Mar 2015 23:06:43 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2FN6hrw014438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Mar 2015 23:06:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.127]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Sun, 15 Mar 2015 18:06:43 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) Thread-Index: AQHQWs7PxLq1VIcV1E6/+HsVS3BBAZ0eZj4A Date: Sun, 15 Mar 2015 23:06:34 +0000 Message-ID: References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> In-Reply-To: <54FE4416.60601@gont.com.ar> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.61.107.220] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Sun, 15 Mar 2015 23:06:47 -0000 RmVybmFuZG8sIEplbiBhbmQgVGltLA0KDQpUaGlzIGlzIGluZGVlZCBhIHZlcnkgaW1wb3J0YW50 IHRvcGljIHRoYXQgZGVzZXJ2ZXMgdGhlIGZ1bGwgZm9jdXMgb2YgdGhlDQpJbnRlcm5ldCBhdCBs YXJnZSAocmVhZCBiZXlvbmQgSUVURiA9PSB0byBvcGVyYXRvciBncm91cHMgc3VjaCBhcyBOQU5P RykuDQpUaGlzIHRvcGljIGlzIFNPIGltcG9ydGFudCB0aGF0IEkgd291bGQgYXBwcmVjaWF0ZSBh biBpbXByb3ZlZCB2ZXJzaW9uIG9mDQppdCAoYW5kIEkgY2FuIHdvcmsgd2l0aCB5b3Ugb24gdGhp cykuDQoNCkJlc2lkZSB0aGUgdmVyeSBtdWNoIG5lZWRlZCByZWZyZXNoIChTdW1tZXIgMjAxNCBp cyBhIGxvbmcgdGltZSBhZ28pOg0KLSBzaG91bGQgZXhwbGFpbiBob3cgdGhlIHJhbmdlIG9mICdk cm9wcGVkIGJ5IGludGVybWVkaWF0ZSBBUycgaXMgY29tcHV0ZWQ/DQotIHNob3VsZCBzcGVjaWZ5 IHdoaWNoIGtpbmQgb2YgZnJhZ21lbnRzIHdlcmUgdXNlZD8gSWYgZmlyc3QgZnJhZ21lbnQgd2Fz DQp3aXRob3V0IGVub3VnaCBvZiBsYXllci00IGluZm9ybWF0aW9uLCB0aGVuIEkgYW0gaGFwcHkg d2l0aCAxMDAlIGRyb3AgOi0pDQoodGhhbmtzIEZlcm5hbmRvIGZvciB5b3VyIFJGQyBhbGxvd2lu ZyB0aGlzIHBhcmFub2lkIGJlaGF2aW9yIDotKSApDQotIGRldGVjdGluZyB0aGUgZHJvcHBpbmcg QVMgaXMgcmVhbGx5IHJlYWxseSB0cmlja3kgKGxvb2sgZm9yIGFjYWRlbWljDQpwYXBlcnMgb24g cm91dGVyIGFsaWFzaW5nKS4gRGlkIHRoZSB0ZXN0IHVzZSAnc2xvdyB0ZXN0aW5nJz8gU2VjdXJp dHkNCmNhdXRpb3VzIG9wZXJhdG9ycyBhcmUgcmF0ZS1saW1pdGluZyB0aGVpciBJQ01QIGdlbmVy YXRpb24sIHNvLA0KdGVzdGluZy9zY2FubmluZyB0b28gZmFzdCBjb3VsZCB0cmlnZ2VyIHRoaXMg cmF0ZS1saW1pdGluZw0KLSBhdCBzb21lIHBvaW50IG9mIHRpbWUgKHByb2JhYmx5IG91dHNpZGUg SUVURiksIHlvdSBzaG91bGQgbWFkZSB0aGUgJ3dhbGwNCm9mIHNoYW1lJyBwdWJsaWMgdG8gaW5j ZW50aXZlIGRyb3BwaW5nIEFTIHRvIGNoYW5nZSBiZWhhdmlvcg0KDQpNaW5vciBjb21tZW50czoN Ci0gYXMgZXhwcmVzc2VkIGJ5IG90aGVycywgdGVzdGluZyBBbGV4YS93ZWxsLWtub3duIGRvbWFp bnMgaXMgcHJvYmFibHkgbm90DQpnaXZpbmcgYSByZWFsaXN0aWMgdmlldyAodG9vIG1hbnkgQ0RO IG9yIFNMQiBmb3IgdGhvc2UgZG9tYWlucykNCi0gdGVzdGluZyBmcm9tIGEgY291cGxlIG9mIHNp dGVzIChvciBmcm9tIFJJUEUgQXRsYXMgZ29pbmcgdGhyb3VnaA0KcmVzaWRlbnRpYWwgcm91dGVy cykgbWF5IGJpYXMgdGhlIG91dHB1dCByZXN1bHQNCi0gYWxzbyB0ZXN0aW5nIGFnYWluc3QgMSBt aWxsaW9uIHNpdGUgYW5kIHdlaWdodGluZyBnb29nbGUuY29tIG9uIHRoZSBzYW1lDQpsZXZlbCBv ZiB2eW5ja2Uub3JnIGlzIGFsc28gcHJvdmlkaW5nIHNvbWUgYmlhcw0KLSBkcm9wcGluZyBIYkgg aXMgT0sgZm9yIG1lLCBkcm9wcGluZyBkZXN0aW5hdGlvbiBoZWFkZXIgaXMgbGVzcywgc28sDQp2 YXN0bHkgZGlmZmVyZW50IG1lYXN1cmVtZW50IGFuZ2xlcw0KLSB1bnN1cmUgaG93IHRvIGhhbmRs ZSB0aGUgYWJvdmUgdGhvdWdoIDotKQ0KLSBJIG1hZGUgc2V2ZXJhbCBxdWljayBhbmQgZGlydHkg dGVzdHMgKHd3dy52eW5ja2Uub3JnL3NyLnBocCkgYW5kIEkgYW0NCndheSBtb3JlIHBvc2l0aXZl IHRoYW4geW91ciBvdXRjb21lLiBTdGlsbCB3b25kZXJpbmcgd2h5IGFuZCBsb29raW5nDQpmb3J3 YXJkIHRvIGFuYWx5emluZyB0aGlzIHdpdGggeW91IDotKQ0KDQpGaW5hbGx5LCBJIHdvdWxkIGhh dmUgaG9wZWQgdG8gc2VlIDEwMCUgcGFja2V0IGRyb3AgZm9yIEhiSCA7LSkNCg0KTGV0J3MgdGFs ayBpZiBub3QgYXQgVHJvb3BlcnMsIG9yIFY2IFdvcmxkIENvbmdyZXNzIHRoZW4gaW4gRGFsbGFz ICEgOi0pDQoNCkEgdmVyeSBtdWNoIG5lZWRlZCBwaWVjZSBvZiB3b3JrLA0KDQotw6lyaWMNCg0K DQpPbiAxMC8wMy8xNSAwMjowOCwgIkZlcm5hbmRvIEdvbnQiIDxmZXJuYW5kb0Bnb250LmNvbS5h cj4gd3JvdGU6DQoNCj5Gb2xrcywNCj4NCj5BdCB0aGUgSUVURiBtZWV0aW5nIGluIEhhd2FpaSB3 ZSBwcmVzZW50ZWQNCj5kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLWluLXJlYWwtd29ybGQuIEZv bGtzIHNlZW1lZCB0byBiZSBpbiBmYXZvciBvZg0KPmFuIEktRCBwcm92aWRpbmcgcmVhbC13b3Js ZCBkYXRhIGFib3V0IHRoZSBleHRlbnQgdG8gd2hpY2ggcGFja2V0cyB3aXRoDQo+RUhzIGFyZSBk cm9wcGVkIGluIHRoZSBJbnRlcm5ldCwgYnV0IGRpZG4ndCBzdXBwb3J0IGhhdmluZyB0aGUgSS1E DQo+cHJvdmlkZSBhZHZpY2Ugb24gdGhpcyB0b3BpYy4NCj4NCj5XZSBoYXZlIHJldmlzZWQgdGhl IEktRC4gTG90cyBvZiB0aGluZ3Mgd2VyZSBjb3JyZWN0ZWQgYW5kL29yIGNsYXJpZmllZC4NCj5B bmQgYWxsIHN1Y2ggdGV4dCB0aGUgd2cgd2FzIG5vdCBpbiBhZ3JlZW1lbnQgd2l0aCBoYXMgbm93 IGJlZW4gcmVtb3ZlZC4NCj4NCj5UaGUgbmV3IHJldiBpcyBhdmFpbGFibGUgYXQ6DQo+PGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMt aW4tcmVhbC13b3INCj5sZC0wMi50eHQ+DQo+DQo+UGxlYXNlIGRvIGxldCB1cyBub3cgaWYgeW91 IGhhdmUgYW55IGZlZWRiYWNrLg0KPg0KPlRoYW5rcyENCj4NCj5CZXN0IHJlZ2FyZHMsDQo+RmVy bmFuZG8NCj4NCj4NCj4NCj4NCj4tLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0K PlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC1nb250LXY2b3Bz LWlwdjYtZWhzLWluLXJlYWwtd29ybGQtMDIudHh0DQo+RGF0ZTogU3VuLCAwOCBNYXIgMjAxNSAy MjozNjowOSAtMDcwMA0KPkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPlRvOiBXaWxs IExpdSAoU2h1Y2hlbmcpIDxsaXVzaHVjaGVuZ0BodWF3ZWkuY29tPiwgSi4gTGlua292YQ0KPjxm dXJyeUBnb29nbGUuY29tPiwgU2h1Y2hlbmcgTElVIChXaWxsKSA8bGl1c2h1Y2hlbmdAaHVhd2Vp LmNvbT4sIFRpbQ0KPkNob3duIDx0amNAZWNzLnNvdG9uLmFjLnVrPiwgVGltIENob3duIDx0amNA ZWNzLnNvdG9uLmFjLnVrPiwgRmVybmFuZG8NCj5Hb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+ LCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+LCBKLg0KPkxpbmtvdmEgPGZ1 cnJ5QGdvb2dsZS5jb20+DQo+DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdvbnQt djZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZC0wMi50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEZlcm5hbmRvIEdvbnQgYW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJl cG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13 b3JsZA0KPlJldmlzaW9uOgkwMg0KPlRpdGxlOgkJT2JzZXJ2YXRpb25zIG9uIElQdjYgRUggRmls dGVyaW5nIGluIHRoZSBSZWFsIFdvcmxkDQo+RG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wOA0KPkdy b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQkxNQ0KPlVSTDoNCj5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLWlu LXJlYWwtd29ybA0KPmQtMDIudHh0DQo+U3RhdHVzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZC8NCj5IdG1s aXplZDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nb250LXY2b3BzLWlwdjYt ZWhzLWluLXJlYWwtd29ybGQtMDINCj5EaWZmOg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZC0wDQo+Mg0KPg0K PkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgcmVhbC13b3JsZCBkYXRhIHJl Z2FyZGluZyB0aGUgZXh0ZW50IHRvIHdoaWNoDQo+ICAgcGFja2V0cyB3aXRoIElQdjYgZXh0ZW5z aW9uIGhlYWRlcnMgYXJlIGZpbHRlcmVkIGluIHRoZSBJbnRlcm5ldCAoYXMNCj4gICBtZWFzdXJl ZCBpbiBBdWd1c3QgMjAxNCksIGFuZCB3aGVyZSBpbiB0aGUgbmV0d29yayBzdWNoIGZpbHRlcmlu Zw0KPiAgIG9jY3Vycy4gIFRoZSBhZm9yZW1lbnRpb25lZCByZXN1bHRzIHNlcnZlIGFzIGEgcHJv YmxlbSBzdGF0ZW1lbnQgdGhhdA0KPiAgIGlzIGV4cGVjdGVkIHRvIHRyaWdnZXIgb3BlcmF0aW9u YWwgYWR2aWNlIG9uIHRoZSBmaWx0ZXJpbmcgb2YgSVB2Ng0KPiAgIHBhY2tldHMgY2Fycnlpbmcg SVB2NiBFeHRlbnNpb24gSGVhZGVycywgc28gdGhhdCB0aGUgc2l0dWF0aW9uDQo+ICAgaW1wcm92 ZXMgb3ZlciB0aW1lLiAgVGhpcyBkb2N1bWVudCBhbHNvIGV4cGxhaW5zIGhvdyB0aGUNCj4gICBh Zm9yZW1lbnRpb25lZCByZXN1bHRzIHdlcmUgb2J0YWluZWQsIHN1Y2ggdGhhdCB0aGUgY29ycmVz cG9uZGluZw0KPiAgIG1lYXN1cmVtZW50cyBjYW4gYmUgcmVwcm9kdWNlZCBieSBvdGhlciBtZW1i ZXJzIG9mIHRoZSBjb21tdW5pdHkuDQo+DQo+DQo+DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNz aW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KPg0KPg0KPg0K Pg0KPi0tIA0KPkZlcm5hbmRvIEdvbnQNCj5lLW1haWw6IGZlcm5hbmRvQGdvbnQuY29tLmFyIHx8 IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KPlBHUCBGaW5nZXJwcmludDogNzgwOSA4NEY1IDMyMkUg NDVDNyBGMUM5IDM5NDUgOTZFRSBBOUVGIEQwNzYgRkZGMQ0KPg0KPg0KPg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBsaXN0 DQo+djZvcHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQoNCg== From nobody Sun Mar 15 16:06:55 2015 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 EE04A1A1BCD for ; Sun, 15 Mar 2015 16:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 xuq9zzCjQvtm for ; Sun, 15 Mar 2015 16:06:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B381A1BD1 for ; Sun, 15 Mar 2015 16:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=510; q=dns/txt; s=iport; t=1426460805; x=1427670405; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Gpd1y5m+3Zd0gbD6gI/ZQzL5MWrsltK71bnkizyE02g=; b=bk8kl8Ygw8yY12pZvuEXDBGf42D9aYZESQ+wqyTR4+Vp1c1PY7tBwMC/ ExAwkYojBErOTAhdW8N93IvVZNbkb4a0/QKONTFjF/n1TJlfa/vTv3twZ yiakc8ZePY0wLvkw/3l1nqsnMTeHdL8mNmSu4RgpOI2hxXPQB0n5Fe8v7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AsBQBxDwZV/5FdJa1bgwaBLASDCMcDAhx5TAEBAQEBAX2EEAEBBCMRRRACAQgYAgImAgICMBUQAgQBDQWIL6sZmjIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJdoQ+GBsHBIJkgUUBBJA6iWaUFCODbm8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,406,1422921600"; d="scan'208";a="132245797" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 15 Mar 2015 23:06:44 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2FN6iEY031196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Mar 2015 23:06:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.127]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sun, 15 Mar 2015 18:06:44 -0500 From: "Eric Vyncke (evyncke)" To: "Templin, Fred L" , Alexandru Petrescu , Mikael Abrahamsson Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away Thread-Index: AQHQXYmI/tEEujV8sEmwvZWZCWgRBp0arxaAgAA7YYCAAAICAIAAAsiAgAADI4CAA3mCgA== Date: Sun, 15 Mar 2015 23:06:36 +0000 Message-ID: References: <55009B03.3040500@gmail.com> <0D94ED48-094C-4089-A349-48F08E50E8D5@delong.com> <55018706.5040009@gmail.com> <20150312.134133.74704744.sthaug@nethelp.no> <20150312130052.GD54385@Space.Net> <5501914D.8060604@gmail.com> <5502D849.90101@gmail.com> <55030D07.5070306@gmail.com> <2134F8430051B64F815C691A62D9831832E1C8D3@XCH-BLV-504.nw.nos.boeing.com> <5503110B.6080606@gmail.com> <2134F8430051B64F815C691A62D9831832E1C9CC@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E1C9CC@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.61.107.220] Content-Type: text/plain; charset="utf-8" Content-ID: <415F1C386DC62344BC8884145F31B0FD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away 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: Sun, 15 Mar 2015 23:06:48 -0000 T24gMTMvMDMvMTUgMTc6NDMsICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPiB3cm90ZToNCj4NCj5JIGFtIHRoaW5raW5nIG9mIGEgcm91dGVyIHRoYXQgcGlucyBh IEdVQSBvbiBzb21lIHNvcnQgb2YgaW50ZXJuYWwgdmlydHVhbA0KPmludGVyZmFjZSAobGlrZSBh IGxvb3BiYWNrKSBidXQgbGVhdmVzIGFsbCBvZiBpdHMgb3RoZXIgaW50ZXJmYWNlcyBhcyBsaW5r DQo+bG9jYWwgb25seS4gRG8geW91IHNlZSBhIHByb2JsZW0gd2l0aCB0aGF0Pw0KDQoNClNlZSBS RkMgNzQwNCAoaWYgbm90IG1pc3Rha2VuIGJ5IHRoZSByZWZlcmVuY2UgYmVpbmcgb2ZmLWxpbmUg cmlnaHQgbm93KQ0KDQotw6lyaWMNCg0KPg0KDQo= From nobody Sun Mar 15 18:18:46 2015 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 9D1521A1EE8 for ; Sun, 15 Mar 2015 18:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 gww_Af-ZcD9w for ; Sun, 15 Mar 2015 18:18:43 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 2F4531A1EEA for ; Sun, 15 Mar 2015 18:18:43 -0700 (PDT) Received: from port-213-160-6-163.static.qsc.de ([213.160.6.163] helo=[172.20.23.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YXJg0-0004En-1p; Mon, 16 Mar 2015 02:18:40 +0100 Message-ID: <55061ECB.9030602@si6networks.com> Date: Mon, 16 Mar 2015 01:07:39 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" , Fernando Gont , "v6ops@ietf.org" References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 01:18:45 -0000 Hi, Eric, Thanks so much for your feedback! Please find my comments in-line... On 03/16/2015 12:06 AM, Eric Vyncke (evyncke) wrote: > > Beside the very much needed refresh (Summer 2014 is a long time ago): [FWIW, the refresh is in the works... Actually, done, but not yet incorporated such that we could meet the submission cut-off deadline] > - should explain how the range of 'dropped by intermediate AS' is computed? Something else other than what's in Section B.2? > - should specify which kind of fragments were used? If first fragment was > without enough of layer-4 information, then I am happy with 100% drop :-) > (thanks Fernando for your RFC allowing this paranoid behavior :-) ) We will clarify this. FWIW, they were normal/legitimate fragments. > - detecting the dropping AS is really really tricky (look for academic > papers on router aliasing). Any specific one we should be aware of? > Did the test use 'slow testing'? Security > cautious operators are rate-limiting their ICMP generation, so, > testing/scanning too fast could trigger this rate-limiting Yes. Also, when the probe type is != from ICMP, then the final destination would respond (e.g. TCP SYN/ACK or TCP RST), and hence this wouldn't be considered a packet drop. > - at some point of time (probably outside IETF), you should made the 'wall > of shame' public to incentive dropping AS to change behavior Heads-up: I've updated the tools to provide the list of dropping ASes. I guess that the transit ASes could be put in a "wall of shame". However, when it comes to destination ASes, there are more valid reasons to drop EH-enabled packets... > Minor comments: > - as expressed by others, testing Alexa/well-known domains is probably not > giving a realistic view (too many CDN or SLB for those domains) FWIW, we do drop duplicate addresses for the tests. Hence each IPv6 address is measured once (no matter how many domains employ it/them). > - testing from a couple of sites (or from RIPE Atlas going through > residential routers) may bias the output result While this is certainly possible, packet drops are not ocurring at the surce, but rather at transit or destination ASes. Chainging the surce of the probes to different locations seem to agree with this view. > - also testing against 1 million site and weighting google.com on the same > level of vyncke.org is also providing some bias I'd say that both are meaningful measurements, but they represent different things. One ma want t measure the % of sites that support EHs (no matter which site), or a kind of "weighed" measurements, where "popular sites" count more than one. In this case, we were trying to do the former. > - dropping HbH is OK for me, dropping destination header is less, so, > vastly different measurement angles > - unsure how to handle the above though :-) > - I made several quick and dirty tests (www.vyncke.org/sr.php) and I am > way more positive than your outcome. Still wondering why and looking > forward to analyzing this with you :-) Are your results publicly-available? > Finally, I would have hoped to see 100% packet drop for HbH ;-) Same here :-) > Let's talk if not at Troopers, or V6 World Congress then in Dallas ! :-) Yes. :-) > A very much needed piece of work, Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Mar 16 00:07:52 2015 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 A08FA1A1B84 for ; Mon, 16 Mar 2015 00:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 GGhdDAsTCo-7 for ; Mon, 16 Mar 2015 00:07:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336BB1A1A9E for ; Mon, 16 Mar 2015 00:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1556; q=dns/txt; s=iport; t=1426489668; x=1427699268; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sKURykISw3p0SXFJGU4w1PMDehUeOI2AhOAMX7K1Jt8=; b=IXdt4oodjLOd4OqnWktBIZd7li5yC4lVTag88zlpRestTH3mqiYTOpxY uYl4IQtsvy8S8SL9+DoigvbryKjHQR0GhmK04Mo3x36ZAcCMv0evQMnW0 xQCfu3mrLfdCl0SypC8JkPwrw5qikMOhRs5Zo0td5+lRo+7StjhY0V8nl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AvBQA8gAZV/4QNJK1BGoMGUloEgwjBLIV4AhyBBkwBAQEBAQF9hBABAQQjEUMSAgEIDgoCAh8HAgICMBUQAgQBEgmIJkSodZpLAQEBAQEBAQEBAQEBAQEBAQEBGoEhiXaEViKCaIFFBZA6iWaBG4xNEIJVg0cjgjKBPG8BEYEyfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,407,1422921600"; d="scan'208";a="403866603" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 16 Mar 2015 07:07:46 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2G77kim028957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Mar 2015 07:07:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.127]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 02:07:46 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont , Fernando Gont , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) Thread-Index: AQHQWs7PxLq1VIcV1E6/+HsVS3BBAZ0eZj4AgAAyY4CAAIYjAA== Date: Mon, 16 Mar 2015 07:07:44 +0000 Message-ID: References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <55061ECB.9030602@si6networks.com> In-Reply-To: <55061ECB.9030602@si6networks.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.61.163.50] Content-Type: text/plain; charset="utf-8" Content-ID: <273C60F20B531249AD11F34C2992B72C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 07:07:50 -0000 SGVsbG8gRmVybmFuZG8sIA0KDQpUaGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgcmVwbHkuIFNlZSBp bi1saW5lIGZvciByZW1haW5pbmcgY29tbWVudHMvYW5zd2Vycw0KDQpPbiAxNi8wMy8xNSAwMTow NywgIkZlcm5hbmRvIEdvbnQiIDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPg0KPg0K Pj4gLSBzaG91bGQgZXhwbGFpbiBob3cgdGhlIHJhbmdlIG9mICdkcm9wcGVkIGJ5IGludGVybWVk aWF0ZSBBUycgaXMNCj4+Y29tcHV0ZWQ/DQo+DQo+U29tZXRoaW5nIGVsc2Ugb3RoZXIgdGhhbiB3 aGF0J3MgaW4gU2VjdGlvbiBCLjI/DQoNClJlLXJlYWRpbmcgQi4yIHdpdGggZnJlc2ggZXllID0+ IE9LIGl0IGlzIGVub3VnaCB0byB1bmRlcnN0YW5kDQoNCj4+IC0gZGV0ZWN0aW5nIHRoZSBkcm9w cGluZyBBUyBpcyByZWFsbHkgcmVhbGx5IHRyaWNreSAobG9vayBmb3IgYWNhZGVtaWMNCj4+IHBh cGVycyBvbiByb3V0ZXIgYWxpYXNpbmcpLg0KPg0KPkFueSBzcGVjaWZpYyBvbmUgd2Ugc2hvdWxk IGJlIGF3YXJlIG9mPw0KDQpMb29rIGZvciBwYXBlcnMgYXJvdW5kICJBbGlhcyByZXNvbHV0aW9u IiwgdGhlcmUgaXMgZXZlbiBvbmUgYnkgVW5pdmVyc2l0eQ0Kb2YgTWFyeWxhbmQgb24gIlVBdjYi IHdoZXJlIHNwZWNpZmljIElQdjYgdHJpY2tzIHdlcmUgdXNlZC4NCg0KPj4tIEkgbWFkZSBzZXZl cmFsIHF1aWNrIGFuZCBkaXJ0eSB0ZXN0cyAod3d3LnZ5bmNrZS5vcmcvc3IucGhwKSBhbmQgSSBh bQ0KPj4gd2F5IG1vcmUgcG9zaXRpdmUgdGhhbiB5b3VyIG91dGNvbWUuIFN0aWxsIHdvbmRlcmlu ZyB3aHkgYW5kIGxvb2tpbmcNCj4+IGZvcndhcmQgdG8gYW5hbHl6aW5nIHRoaXMgd2l0aCB5b3Ug Oi0pDQo+DQo+QXJlIHlvdXIgcmVzdWx0cyBwdWJsaWNseS1hdmFpbGFibGU/DQoNCk5vLCB0aGV5 IHdlcmUgbW9yZSBhZC1ob2MgYmFzZWQgb24gbG9jYXRpb25zIHdoZXJlIEkgYW0gdHJhdmVsbGlu Zy4uLiBTbywNCm5vdCBlbm91Z2ggc2FtcGxlcyB0byBiZSB3b3J0aCBidXQgdW50aWwgbm93IGlz IHdhcyBhbHdheXMgMTAwJSBzdWNjZXNzDQp3aGVuIG5vIGZpcmV3YWxsIHdoZXJlIGluIHRoZSBw YXRoIChwcm9iYWJseSBhYm91dCA1MCB0ZXN0cyBvbmx5KS4NCg0KLcOpcmljDQoNCj4NCg0K From nobody Mon Mar 16 01:29:32 2015 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 BA2CD1A7020 for ; Mon, 16 Mar 2015 01:29:30 -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 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 PFfVUx_gfTPd for ; Mon, 16 Mar 2015 01:29:29 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CDC1A7021 for ; Mon, 16 Mar 2015 01:29:29 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 904D462C6; Mon, 16 Mar 2015 01:29: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=oEk14LOJ/ZH7AIjj62zj0MxWwSs=; b= GjEEytdcR6Lo0OsCSa2qbMhVA/6eozOA0tnGjkGodJRTL/EUe2lqbHoG9673Aa/G tZMzEyw1T8KV22ZcVZM9PJsI6d4mOxTxX49vZRWX/uhe4wzmznigFt4Uwf0XBuIT IIJbQlxEBICPV6N+CAyj0ob4aP+PSoC7jvJiLnUxmwA= 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=OfSpeDZF215t8EgVUP9br+MLj3 iNi752oBY9EmleKMC2PYsx/qcj4QiMn5jyTcwic+m/XPGxbhFI1w38JPWKzMy9Vb 0p7+D+S15Aof75YSFRq7/43XNj4+vKQfy8lYLmAmRwl4jywhzZ7p/RVKkBV8Is08 TD1GWp7EpNTbQmNlE= Received: from gomlefisk.localdomain (unknown [173.38.220.54]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 2CFFA6285; Mon, 16 Mar 2015 01:29:27 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id DDF4740C1B3B; Mon, 16 Mar 2015 09:29:35 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_13D99AF1-A5D3-4CD8-B008-ACCFBB4726C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <55038095.3070109@gmail.com> Date: Mon, 16 Mar 2015 09:29:35 +0100 Message-Id: <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <550212CB.2090306@foobar.org> <55021899.7080908@foobar.org> <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2087) Archived-At: Cc: Silvia Hagen , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 08:29:30 -0000 --Apple-Mail=_13D99AF1-A5D3-4CD8-B008-ACCFBB4726C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > And chip-level hardware designers will explain to you exactly why this > is a painfully expensive thing to do at line speed. This stuff was > designed by software people at the tail end of the 32-bit minicomputer > era, and things looked different to them^H^H^H^Hus than they do to a > 21st century chip designer. that is not how I recall history. I vividly recall a conversation with Steve back in 1998 or 1999 when he = got confronted with this, stated that it was a design feature. extension = headers are designed to be hard to parse in hardware, cause routers = aren=E2=80=99t supposed to be doing that. has anything changed in the last 15-20 years? I didn=E2=80=99t think = there was IETF consensus to modify protocols to be easier on = middleboxes. cheers, Ole --Apple-Mail=_13D99AF1-A5D3-4CD8-B008-ACCFBB4726C4 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 iQEcBAEBCgAGBQJVBpRvAAoJEFuJXizso86gPFYH/3tzWNWtsDG7K44rs7sdkx1g KrQk8alVdsbJLTI9Qv8IyM0rjbAl8grircse0ZkDWTMfgGA1H4vsQ2Y6ox3GVL4G H8pwHNhEs229Wdfuvv04svsHqNu/S2oT1wl/BhsmoA+f1Cgm3RszMFkng6an9/C1 qvcvQHwgj23X7n8MPZ5Bkv1h52RjmcWoK8ip0KcOWpsqsxPf2QAf4jrI30UHaijg AH6Kx1d2597nd12N2QxK+1b4ooeIPG2T+ta4Xlsi0amXTUJmCqNRK6RvBuvV47oN r6zOtmdFH8OyUuLVvkW+NKZCeIzq5XHZhycPckKoD6mDR2lKz5S/PvPU3WWx3so= =tE5C -----END PGP SIGNATURE----- --Apple-Mail=_13D99AF1-A5D3-4CD8-B008-ACCFBB4726C4-- From nobody Mon Mar 16 02:07:35 2015 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 420C41A8035 for ; Mon, 16 Mar 2015 02:07:33 -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 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 ZEVgDmJgb3Wt for ; Mon, 16 Mar 2015 02:07:32 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173411A7D83 for ; Mon, 16 Mar 2015 02:07:32 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 54FA762F5; Mon, 16 Mar 2015 02:07:31 -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=+c8EOfEBnxRRpILkIOih0Q/qqVQ=; b= C02/CH2/HozR2hCG6coE28Jd9aUsTVB8WUtimKnKEy+dif3ff7DNOtB013HgRsCA x1qPN7O4ec4NjUAOU5hoLGVzJpQXyp1pBRFozdBIhW9mX498TGYA5EBFjQmjO8Xt 2M9dtUwrCQvP5FnYDTftany0JzLDWahbEea08LmBRIo= 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=dov0HBcwdh5eJgLPJPoSc5cJ+5 FlRc9ujoc4Wv13zI1huCgqjHuozB1Yn8JxGo6gqvXKAL31ulgSrTIp4DFyYCyLyo eOgf15LeUIGEKmS5OyBvHJE/2T7F6cfhDLX2PpS8pb6b1vgEK2bLbtja6exN3OKU cK1rOkOZw/v2eKHN0= Received: from gomlefisk.localdomain (unknown [173.38.220.54]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id E4D2962E8; Mon, 16 Mar 2015 02:07:30 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 9415B40C26CA; Mon, 16 Mar 2015 10:07:39 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3A7B5218-173C-4374-AEE2-05CBC1FA1A95"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <5502E263.3020905@si6networks.com> Date: Mon, 16 Mar 2015 10:07:38 +0100 Message-Id: <0C862710-C3AF-4C25-9732-67287D1560E6@employees.org> References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <5502E263.3020905@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.2087) Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 09:07:33 -0000 --Apple-Mail=_3A7B5218-173C-4374-AEE2-05CBC1FA1A95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Fernando, >> apart from dropping HBH I would be quite surprised if there were >> any transit AS operators thinking that filtering fragments was >> acceptable for a functioning Internet. let=92s get some more real >> data on what=92s really going on. >=20 > What's (specifically) the data that you're looking for? -- I'm not > objecting, but rather asking so that ew can produce whatever you think > is missing. I=92m looking for data identifying where filtering is done _not_ by = design. and where filtering is done not by the end-points / end-sites (although = that demarcation can be a little blurry, e.g. in case of ISP controlled = CPEs with broken firewalls). cheers, Ole --Apple-Mail=_3A7B5218-173C-4374-AEE2-05CBC1FA1A95 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 iQEcBAEBCgAGBQJVBp1bAAoJEFuJXizso86geScIAI3cHFJXLzJHl4DAglKifAg0 K8DpZd4DglBaekuSZMKt6H7XGTLuUQCZ0WBHMUytvE9H7noGOjvna2DGBT4KiHa+ +GpJJFmX2erlFDPLLSKavb5X7xgI6fWNuS4+DCo/ze/+9kW0eNHORDSxoYKPIle6 TtmLt7BuDKw0dtmBnR32RkAxI+EN3JVLR1Nnmdyho65kRYsQ2ICsCnb+MogXebQM eiIrbTp81NURju4exh0Vx+Of3YgBFsBYsNbw5ZCq/bR5uhIC3K5L3Drwel521JmI N1r7B6qW4J4UtytN3EQSRvoZ+SCr946Ps900MT7uki8m4PNCgfnq8c9DE8El6Go= =gaLT -----END PGP SIGNATURE----- --Apple-Mail=_3A7B5218-173C-4374-AEE2-05CBC1FA1A95-- From nobody Mon Mar 16 02:15:34 2015 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 DD7FF1A7D83 for ; Mon, 16 Mar 2015 02:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YVxtijzF85mV for ; Mon, 16 Mar 2015 02:15:31 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 5EFCD1A1B51 for ; Mon, 16 Mar 2015 02:15:30 -0700 (PDT) Received: (qmail 42981 invoked from network); 16 Mar 2015 09:15:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Mar 2015 09:15:28 -0000 Date: Mon, 16 Mar 2015 10:15:28 +0100 (CET) Message-Id: <20150316.101528.74709844.sthaug@nethelp.no> To: otroan@employees.org From: sthaug@nethelp.no In-Reply-To: <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-2 Content-Transfer-Encoding: 7bit Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 09:15:33 -0000 > > And chip-level hardware designers will explain to you exactly why this > > is a painfully expensive thing to do at line speed. This stuff was > > designed by software people at the tail end of the 32-bit minicomputer > > era, and things looked different to them^H^H^H^Hus than they do to a > > 21st century chip designer. > > that is not how I recall history. > I vividly recall a conversation with Steve back in 1998 or 1999 when he got confronted with this, stated that it was a design feature. extension headers are designed to be hard to parse in hardware, cause routers aren$,1ry(Bt supposed to be doing that. Looking at it from an operational point of view, as far as I can see my routers have two options: - Either they can skip past (in hardware) IPv6 headers until they reach the relevant upper layer header (UDP, TCP, ICMP etc). This may or may not imply full IPv6 header parsing. - Or they have to drop the packet. This of course also implies that the size of the IPv6 headers must be compatible with how far my routers can peek into the packet. Steinar Haug, AS 2116 From nobody Mon Mar 16 02:20:22 2015 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 E903A1A8547 for ; Mon, 16 Mar 2015 02:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Ihk_m3lCXZlS for ; Mon, 16 Mar 2015 02:20:19 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (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 1C2741A7034 for ; Mon, 16 Mar 2015 02:20:19 -0700 (PDT) Received: by pagr17 with SMTP id r17so59569143pag.0 for ; Mon, 16 Mar 2015 02:20:18 -0700 (PDT) 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-type; bh=pULnEVrfdlFgxeNskmzDS9JCoSGDgcJO1k/fy/LwPBw=; b=Itz1KhMelUai1Mgvj5PDuwx42wT54ZrpIurbTml/LxfWLLu32+Mu0UcY/fMHyB3jyx bMOE3kJ0Pth5TkXoYe8KK9fJNgxLmq1EcgDjok49aYUXWjv+eN819sU5wrC40zuHg6kI MsnQ5zJcIMb4IB4CHFA4f9DKzUagHdR2qPAbN0DKTLuWLUAnhoiYhM6kw/ANzeGGg35Z xellRm9fs/7kp4gzao5eqLEJ3QcUAu6nH1V8CeKFPdfdQNA+CcMq/8l+jRW7S+0geGeM 3DIefK2lTZOewmEze+rvun6zx7Ia3H7KV9kGA1QbcX2vHIN7cGFS6Bd3+YEE/6rhILlf 7TAw== X-Gm-Message-State: ALoCoQnxbqXRHoUz9GqiePdJG+c/XfDa2RjwHz/+hHW3Kvte4yP+SnyakyTS2c24TdcSr61m9BSp MIME-Version: 1.0 X-Received: by 10.66.141.11 with SMTP id rk11mr51735293pab.29.1426497618559; Mon, 16 Mar 2015 02:20:18 -0700 (PDT) Received: by 10.70.138.36 with HTTP; Mon, 16 Mar 2015 02:20:18 -0700 (PDT) X-Originating-IP: [2001:67c:2e8:13:2d29:7ba6:2899:30e2] In-Reply-To: <20150316.101528.74709844.sthaug@nethelp.no> References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> Date: Mon, 16 Mar 2015 10:20:18 +0100 Message-ID: From: George Michaelson To: otroan@employees.org Content-Type: multipart/alternative; boundary=001a11c39a9ed3da9a0511645ba2 Archived-At: Cc: "" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 09:20:22 -0000 --001a11c39a9ed3da9a0511645ba2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole, the average diameter in AS hops is 4. There's two origin-as, and approximately 2 intermediate AS. That means that 50% of the average AS path *is* the origin, where filtering happens. Either my origin, our your origin. You're hunting for a small amount of middle filter with a huge problem of edge filter surely? On Mon, Mar 16, 2015 at 10:15 AM, wrote: > > > And chip-level hardware designers will explain to you exactly why thi= s > > > is a painfully expensive thing to do at line speed. This stuff was > > > designed by software people at the tail end of the 32-bit minicompute= r > > > era, and things looked different to them^H^H^H^Hus than they do to a > > > 21st century chip designer. > > > > that is not how I recall history. > > I vividly recall a conversation with Steve back in 1998 or 1999 when he > got confronted with this, stated that it was a design feature. extension > headers are designed to be hard to parse in hardware, cause routers > aren=EF=BF=BD1ryt supposed to be doing that. > > Looking at it from an operational point of view, as far as I can see > my routers have two options: > > - Either they can skip past (in hardware) IPv6 headers until they > reach the relevant upper layer header (UDP, TCP, ICMP etc). This may > or may not imply full IPv6 header parsing. > > - Or they have to drop the packet. > > This of course also implies that the size of the IPv6 headers must be > compatible with how far my routers can peek into the packet. > > Steinar Haug, AS 2116 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c39a9ed3da9a0511645ba2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ole, the average diameter in AS hops is 4. There's two= origin-as, and approximately 2 intermediate AS.

That me= ans that 50% of the average AS path *is* the origin, where filtering happen= s. Either my origin, our your origin.

You're h= unting for a small amount of middle filter with a huge problem of edge filt= er surely?



On Mon, Mar 16, 2015 at 10:15 AM, <sth= aug@nethelp.no> wrote:
> > And chip-level hardware designers will explain to yo= u exactly why this
> > is a painfully expensive thing to do at line speed. This stuff wa= s
> > designed by software people at the tail end of the 32-bit minicom= puter
> > era, and things looked different to them^H^H^H^Hus than they do t= o a
> > 21st century chip designer.
>
> that is not how I recall history.
> I vividly recall a conversation with Steve back in 1998 or 1999= when he got confronted with this, stated that it was a design feature. ext= ension headers are designed to be hard to parse in hardware, cause routers = aren=EF=BF=BD1ryt supposed to be doing that.

Looking at it from an operational point of view, as far as I can see
my routers have two options:

- Either they can skip past (in hardware) IPv6 headers until they
reach the relevant upper layer header (UDP, TCP, ICMP etc). This may
or may not imply full IPv6 header parsing.

- Or they have to drop the packet.

This of course also implies that the size of the IPv6 headers must be
compatible with how far my routers can peek into the packet.

Steinar Haug, AS 2116


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


--001a11c39a9ed3da9a0511645ba2-- From nobody Mon Mar 16 04:06:11 2015 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 23D5A1A8707 for ; Mon, 16 Mar 2015 04:06:11 -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 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 AmprkxXEygsQ for ; Mon, 16 Mar 2015 04:06:07 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F2F1A8709 for ; Mon, 16 Mar 2015 04:06:07 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 820FA6315; Mon, 16 Mar 2015 04:06:05 -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=Gaeg9fiOiQ+oyar2lUIrXDaYY6w=; b= flcoE0M6mj/+qgiyDk37kAvJSwRHtP27ingvnSj02ecM73N8qYe/6ghVNyd4P3/i TZUVxcGfXaDLSN6GWxgdddp8aNTo0twV2sZLCA0LA+yJQFLpMbSnyQ8EaOZ22yf8 fbyyLT0v8Hq+QPDY4U/EjyRe5FLgEXcyBPgr6hrRg+I= 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=refqqtJ/gPXM07Jnw0BomIEJAG h1/MHW+lXPrvudm2P6w6dNOS5O+KUlvk3sgjLVaF+FZ6KAxZBZKociZwKEnNfADj c3OfXHa0I+k4QH21zDcePqgSX0B3F6RuZzf/2AGdFLHizaIVcGdLXuIS0gOmyETA +eyiZXVBnlGT7mGv4= Received: from gomlefisk.localdomain (unknown [173.38.220.54]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id CB9AF6312; Mon, 16 Mar 2015 04:06:04 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 2F32C40C36EB; Mon, 16 Mar 2015 12:06:02 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7E367C77-C319-4D61-B893-BE963EE7B96C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: Date: Mon, 16 Mar 2015 12:06:01 +0100 Message-Id: <9D7562B2-559C-4532-9080-6C92CBCBB584@employees.org> References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> To: George Michaelson X-Mailer: Apple Mail (2.2087) Archived-At: Cc: "" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 11:06:11 -0000 --Apple-Mail=_7E367C77-C319-4D61-B893-BE963EE7B96C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Ole, the average diameter in AS hops is 4. There's two origin-as, and = approximately 2 intermediate AS. >=20 > That means that 50% of the average AS path *is* the origin, where = filtering happens. Either my origin, our your origin. >=20 > You're hunting for a small amount of middle filter with a huge problem = of edge filter surely? possibly. I would be hunting for places where filtering is done and = where it isn=E2=80=99t a conscious policy to do so. I could certainly imagine services like e.g. google where they know = exactly the service profile and MTU, and would filter accordingly. = identifying services like that doesn=E2=80=99t appear very interesting. = we=E2=80=99re not going to change their mind anyway (nor do I think it = is the IETF=E2=80=99s business to do so). I think you=E2=80=99re right in pointing out that AS level is not the = right granularity. e.g. as a home user I=E2=80=99d like to find out if my ISP filters, or = if my ISP run CPE filters, or random transit provider filters. cheers, Ole >=20 >=20 >=20 > On Mon, Mar 16, 2015 at 10:15 AM, wrote: > > > And chip-level hardware designers will explain to you exactly why = this > > > is a painfully expensive thing to do at line speed. This stuff was > > > designed by software people at the tail end of the 32-bit = minicomputer > > > era, and things looked different to them^H^H^H^Hus than they do to = a > > > 21st century chip designer. > > > > that is not how I recall history. > > I vividly recall a conversation with Steve back in 1998 or 1999 when = he got confronted with this, stated that it was a design feature. = extension headers are designed to be hard to parse in hardware, cause = routers aren=EF=BF=BD1ryt supposed to be doing that. >=20 > Looking at it from an operational point of view, as far as I can see > my routers have two options: >=20 > - Either they can skip past (in hardware) IPv6 headers until they > reach the relevant upper layer header (UDP, TCP, ICMP etc). This may > or may not imply full IPv6 header parsing. >=20 > - Or they have to drop the packet. >=20 > This of course also implies that the size of the IPv6 headers must be > compatible with how far my routers can peek into the packet. >=20 > Steinar Haug, AS 2116 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 --Apple-Mail=_7E367C77-C319-4D61-B893-BE963EE7B96C 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 iQEcBAEBCgAGBQJVBrkZAAoJEFuJXizso86gvTQH/3ky9qqc0f2bcEKi8qKs1UMv Tv4DeoevbahOzYzMNGNozPxuPV1xOAjzJmrMPBdy6LZRRFOLrLP4udq1PDRq/86B qR66r7RZ5C8NSuhju7IojrfYU04c6paQCIxilS1wBo61XIM607KmAdGOjiV+xY+9 lT+OnfhUSIITcyer12j5CSSTQ/GElBk9V5qxIWpDAUbMVkT8jhelD9Ju+zUlWqW3 n1CBFLpq9+kj0o3EoEyJQDoFKw5dibtkG9KXKkUqrY2ndWBMJxHzhKnsO4NhMJOQ PsXrobgnvHKTSqeI8xpAnkk9u893wTxOZqyk+PZz1oTubJjZd/Bj6ejZUMyYgio= =JePP -----END PGP SIGNATURE----- --Apple-Mail=_7E367C77-C319-4D61-B893-BE963EE7B96C-- From nobody Mon Mar 16 04:07:32 2015 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 E55081A007C for ; Mon, 16 Mar 2015 04:07:30 -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 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 4wUxMrzuP1Ah for ; Mon, 16 Mar 2015 04:07:25 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D612D1A0092 for ; Mon, 16 Mar 2015 04:07:24 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id D821562E8; Mon, 16 Mar 2015 04:07:23 -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=mA49wTW7lZTufrU4IjuAtTRMbYU=; b= YTw65YvgfMcbkLq88oDjZCoKRMN7bV/xW2iZEHno3EwJ+7MdQwt2dE7YVqnhisfL 2fUoseox38v9Alxq4ztTzpNP66Y5hFn8hJeEEzkHKFsE3SaL12y8qkXW2zlfn293 CorRUuOtIIlBzXlXPVODi57E9yX29eCxKh/VxUMJu4U= 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=UbEBbXoTUYPjdKzwNehQRaFl9z VZPr6EHBe5Q6YB3olGJqIKF/xLriXX5hkUuzVCL4LVdnhqtJon2pDMMGobdJ1d7i 4cWXHe6Rj8f2EkBRiG370sQy9RRiaSB05rymb3+//DoyMosuKkYSvcXRK3WvdKce LUKnLDb7848zmRpvI= Received: from gomlefisk.localdomain (unknown [173.38.220.54]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 6640162AD; Mon, 16 Mar 2015 04:07:23 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 25BA740C3775; Mon, 16 Mar 2015 12:07:17 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2C9E8383-64A4-4849-9AEB-0717F58F652C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <20150316.101528.74709844.sthaug@nethelp.no> Date: Mon, 16 Mar 2015 12:07:16 +0100 Message-Id: References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.2087) Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 11:07:31 -0000 --Apple-Mail=_2C9E8383-64A4-4849-9AEB-0717F58F652C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>> And chip-level hardware designers will explain to you exactly why = this >>> is a painfully expensive thing to do at line speed. This stuff was >>> designed by software people at the tail end of the 32-bit = minicomputer >>> era, and things looked different to them^H^H^H^Hus than they do to a >>> 21st century chip designer. >>=20 >> that is not how I recall history. >> I vividly recall a conversation with Steve back in 1998 or 1999 when = he got confronted with this, stated that it was a design feature. = extension headers are designed to be hard to parse in hardware, cause = routers aren=EF=BF=BD$,1ryt supposed to be doing that. >=20 > Looking at it from an operational point of view, as far as I can see > my routers have two options: >=20 > - Either they can skip past (in hardware) IPv6 headers until they > reach the relevant upper layer header (UDP, TCP, ICMP etc). This may > or may not imply full IPv6 header parsing. >=20 > - Or they have to drop the packet. >=20 > This of course also implies that the size of the IPv6 headers must be > compatible with how far my routers can peek into the packet. why would you want your routers to look deeply into _my_ packets? cheers, Ole --Apple-Mail=_2C9E8383-64A4-4849-9AEB-0717F58F652C 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 iQEcBAEBCgAGBQJVBrllAAoJEFuJXizso86gmRgIANUGVKXjJaz8SWUI2KWdXm73 NQgWIcPpKnW2pdF1rYuZJV2Xd3d3JWJcWFte+rsb5uHnXAz9JUd3R9O4/5kBIAPM YF8juQQl/rM6oQ+CHrRHdnQz4rdovIqXZ4etlLlPnf2mdzR13QEKXZIKU8P65VB2 Ij4mANYKzDrYfRIIysdyLHCpGsK5XZpS9hKXniA0rL37If+00N3uv2pMLTPaFvg9 W0Wgga3a/rHRuJkFao8bzDVE+dXbbcJAEJ/VGyNCtVKT1GjGasEKtnL00M4N/v5H WQN1fWIahPqRNIrN8voeI2FmpGdihFmxf5BwS32W+RN4lDixBRezgem7uX5O7Nw= =IgnC -----END PGP SIGNATURE----- --Apple-Mail=_2C9E8383-64A4-4849-9AEB-0717F58F652C-- From nobody Mon Mar 16 05:59:39 2015 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 4B42C1A8718 for ; Mon, 16 Mar 2015 05:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 di5VOs73yxEi for ; Mon, 16 Mar 2015 05:59:36 -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 52BE71A03A8 for ; Mon, 16 Mar 2015 05:59:36 -0700 (PDT) Received: from mb-aye.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 t2GCxKvY007538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Mar 2015 12:59:21 GMT (envelope-from joelja@bogus.com) Message-ID: <5506D3A3.4070500@bogus.com> Date: Mon, 16 Mar 2015 05:59:15 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Ole Troan , sthaug@nethelp.no References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tUjoSwkhp4awX0ddbQDQ3dgfnNQCWAiM8" Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 12:59:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tUjoSwkhp4awX0ddbQDQ3dgfnNQCWAiM8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/16/15 4:07 AM, Ole Troan wrote: >>>> And chip-level hardware designers will explain to you exactly why th= is >>>> is a painfully expensive thing to do at line speed. This stuff was >>>> designed by software people at the tail end of the 32-bit minicomput= er >>>> era, and things looked different to them^H^H^H^Hus than they do to a= >>>> 21st century chip designer. >>> >>> that is not how I recall history. >>> I vividly recall a conversation with Steve back in 1998 or 1999 when = he got confronted with this, stated that it was a design feature. extensi= on headers are designed to be hard to parse in hardware, cause routers ar= en=EF=BF=BD$,1ryt supposed to be doing that. >> >> Looking at it from an operational point of view, as far as I can see >> my routers have two options: >> >> - Either they can skip past (in hardware) IPv6 headers until they >> reach the relevant upper layer header (UDP, TCP, ICMP etc). This may >> or may not imply full IPv6 header parsing. >> >> - Or they have to drop the packet. >> >> This of course also implies that the size of the IPv6 headers must be >> compatible with how far my routers can peek into the packet. >=20 > why would you want your routers to look deeply into _my_ packets? same reason as in v4: There's not enough entropy in the ip header for hashing Application of l4 acls means finding the header. > cheers, > Ole >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --tUjoSwkhp4awX0ddbQDQ3dgfnNQCWAiM8 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUG06MACgkQ8AA1q7Z/VrIH3QCfTx7TpKRRKovu3VWdsJShcwyJ bcMAoIwLDzSU/qaIQFDxfXGOnoSNgB4W =+cUo -----END PGP SIGNATURE----- --tUjoSwkhp4awX0ddbQDQ3dgfnNQCWAiM8-- From nobody Mon Mar 16 06:40:46 2015 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 DAD971A8755 for ; Mon, 16 Mar 2015 06:40:44 -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 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 EugyeZTmezyW for ; Mon, 16 Mar 2015 06:40:43 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5141A874E for ; Mon, 16 Mar 2015 06:40:43 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id CBD9E6175; Mon, 16 Mar 2015 06:40:41 -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=aOpDqau00kMoiMDt4wOBmpQQGik=; b= Xt9EPe4i8cbDPYtSHQOLNDtda+gzakdsKXK4zEdxBXe52xaEjh2hXaIXa4T3le3K xQhRsTw+TSwRVlHvcX/t1Lh7AYLFNT52rM+GDynXOfoHyDH/v3VEMq9CYi9qHwI+ Avx37a7qyjpIr3Qg6/kyWLSMkaFtHxm1hWNKkviHqlA= 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=Z8t3Zar+v4VuHA2Pxt62hh+Mz7 j0aWGx57LYm6viUAQVU0ubXEbvf7b/YXdJvwsm3QdJz+xOE40P9+YTJnXc9LfKp5 3zOLFURXy6nYvhDjxP4VgsnvLBozsIx6j+h+Rv+ndJCE9aYyAeG3OuNRfvpoCq5j PNO3CrWWAkMZrTuL8= Received: from gomlefisk.localdomain (unknown [173.38.220.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 7F9C56146; Mon, 16 Mar 2015 06:40:41 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 1ADA240C5813; Mon, 16 Mar 2015 14:40:39 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BD71DDD0-48D3-4398-B280-4AE7B518BCA2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <5506D3A3.4070500@bogus.com> Date: Mon, 16 Mar 2015 14:40:38 +0100 Message-Id: <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506D3A3.4070500@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.2087) Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 13:40:45 -0000 --Apple-Mail=_BD71DDD0-48D3-4398-B280-4AE7B518BCA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joel, >>>>> And chip-level hardware designers will explain to you exactly why = this >>>>> is a painfully expensive thing to do at line speed. This stuff was >>>>> designed by software people at the tail end of the 32-bit = minicomputer >>>>> era, and things looked different to them^H^H^H^Hus than they do to = a >>>>> 21st century chip designer. >>>>=20 >>>> that is not how I recall history. >>>> I vividly recall a conversation with Steve back in 1998 or 1999 = when he got confronted with this, stated that it was a design feature. = extension headers are designed to be hard to parse in hardware, cause = routers aren=EF=BF=BD$,1ryt supposed to be doing that. >>>=20 >>> Looking at it from an operational point of view, as far as I can see >>> my routers have two options: >>>=20 >>> - Either they can skip past (in hardware) IPv6 headers until they >>> reach the relevant upper layer header (UDP, TCP, ICMP etc). This may >>> or may not imply full IPv6 header parsing. >>>=20 >>> - Or they have to drop the packet. >>>=20 >>> This of course also implies that the size of the IPv6 headers must = be >>> compatible with how far my routers can peek into the packet. >>=20 >> why would you want your routers to look deeply into _my_ packets? >=20 > same reason as in v4: >=20 > There's not enough entropy in the ip header for hashing if it is for ECMP then I think Steinar=E2=80=99s measure were a little = brutal. > Application of l4 acls means finding the header. yes, but I wouldn=E2=80=99t expect my packets to be subject to L4 ACLs = in the middle of the network. are you saying there is equipment out there that tries to do ECMP, fails = to find the 5 tuple and drops? cheers, Ole --Apple-Mail=_BD71DDD0-48D3-4398-B280-4AE7B518BCA2 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 iQEcBAEBCgAGBQJVBt1WAAoJEFuJXizso86giUMH/3zutI6OkKwFpTcpALk/wlDj qqNl/H3m2l+dDXuaATdemu0QjKNnKbjitBHYQpPt1A5UwX+y7svpYRalJQk+E7+q mHMuJCMeXy6gSC6GACVxiMb14i2fsDWc23sVLrhfLDIeQFIbzLPWc07OsFLasjZ/ UOnqotabw6a8sgyJn0b3BjpZ03la4cgU8CxvNbda3zvSnZH3YhLHwnONRzERqRZU 4ggevEMOjOrBqIKqKnmJmiW1QVlR7381ylmLnUgVBKhYwWOE3lBDB7afz43K58+o xPUyv3HBkfUljCxRYLLPkwNBfw/dI236oIUB8TtW+bYzQPF9xVEKbeIdRQAc73U= =zpCx -----END PGP SIGNATURE----- --Apple-Mail=_BD71DDD0-48D3-4398-B280-4AE7B518BCA2-- From nobody Mon Mar 16 06:53:27 2015 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 E3CA71A8755 for ; Mon, 16 Mar 2015 06:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 T178lWivNlYY for ; Mon, 16 Mar 2015 06:53:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 D78831A8714 for ; Mon, 16 Mar 2015 06:53:23 -0700 (PDT) Received: from [2a02:8071:f00:10:e5d5:62bc:5144:6ad3] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YXVSL-0007FA-0M; Mon, 16 Mar 2015 14:53:21 +0100 Message-ID: <5506BF1A.5050303@si6networks.com> Date: Mon, 16 Mar 2015 12:31:38 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan , sthaug@nethelp.no References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 13:53:26 -0000 On 03/16/2015 12:07 PM, Ole Troan wrote: >> >> - Or they have to drop the packet. >> >> This of course also implies that the size of the IPv6 headers >> must be compatible with how far my routers can peek into the >> packet. > > why would you want your routers to look deeply into _my_ packets? You're assuming that between source and destination there are only RFC1812-like IPv6 routers. But devices enforcing ACLs, firewalls, load-balancers and the like usually end up having to look into your packets. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Mar 16 06:55:28 2015 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 37FDC1A876B for ; Mon, 16 Mar 2015 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 u32NE89LdYbC for ; Mon, 16 Mar 2015 06:55:23 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.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 77EB01A8764 for ; Mon, 16 Mar 2015 06:55:22 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 2D1F2DA0207; Mon, 16 Mar 2015 13:55:22 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 16 Mar 2015 06:55:21 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5506BF1A.5050303@si6networks.com> Date: Mon, 16 Mar 2015 09:54:46 -0400 Content-Transfer-Encoding: 7bit Message-ID: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506BF1A.5050303@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 13:55:25 -0000 On Mar 16, 2015, at 7:31 AM, Fernando Gont wrote: > You're assuming that between source and destination there are only > RFC1812-like IPv6 routers. But devices enforcing ACLs, firewalls, > load-balancers and the like usually end up having to look into your > packets. Why on earth would an ISP enforce ACLs? From nobody Mon Mar 16 06:57:48 2015 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 7E6DA1A8755 for ; Mon, 16 Mar 2015 06:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 rCyzNTIGcQXt for ; Mon, 16 Mar 2015 06:57:45 -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 9C10B1A8758 for ; Mon, 16 Mar 2015 06:57:44 -0700 (PDT) Received: from mb-aye.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 t2GDvcY2008276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Mar 2015 13:57:38 GMT (envelope-from joelja@bogus.com) Message-ID: <5506E14C.8040803@bogus.com> Date: Mon, 16 Mar 2015 06:57:32 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Ole Troan References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506D3A3.4070500@bogus.com> <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> In-Reply-To: <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L5TK0RGqbNWPhMID1vu7ENUj6BnKcVSfg" Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 13:57:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L5TK0RGqbNWPhMID1vu7ENUj6BnKcVSfg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/16/15 6:40 AM, Ole Troan wrote: > Joel, >=20 >>>>>> And chip-level hardware designers will explain to you exactly why = this >>>>>> is a painfully expensive thing to do at line speed. This stuff was= >>>>>> designed by software people at the tail end of the 32-bit minicomp= uter >>>>>> era, and things looked different to them^H^H^H^Hus than they do to= a >>>>>> 21st century chip designer. >>>>> >>>>> that is not how I recall history. >>>>> I vividly recall a conversation with Steve back in 1998 or 1999 whe= n he got confronted with this, stated that it was a design feature. exten= sion headers are designed to be hard to parse in hardware, cause routers = aren=EF=BF=BD$,1ryt supposed to be doing that. >>>> >>>> Looking at it from an operational point of view, as far as I can see= >>>> my routers have two options: >>>> >>>> - Either they can skip past (in hardware) IPv6 headers until they >>>> reach the relevant upper layer header (UDP, TCP, ICMP etc). This may= >>>> or may not imply full IPv6 header parsing. >>>> >>>> - Or they have to drop the packet. >>>> >>>> This of course also implies that the size of the IPv6 headers must b= e >>>> compatible with how far my routers can peek into the packet. >>> >>> why would you want your routers to look deeply into _my_ packets? >> >> same reason as in v4: >> >> There's not enough entropy in the ip header for hashing >=20 > if it is for ECMP then I think Steinar=E2=80=99s measure were a little = brutal. >=20 >> Application of l4 acls means finding the header. >=20 > yes, but I wouldn=E2=80=99t expect my packets to be subject to L4 ACLs = in the middle of the network. If you reason about a network, and the doesn't include the existence of acls on the edges then your model is pretty bad. > are you saying there is equipment out there that tries to do ECMP, fail= s to find the 5 tuple and drops? While I would expect all sorts of abberant behavior from a failure to hash like all those flows groomed onto one link I would not expect drops from a router. a load balancer on the other hand absolutely. > cheers, > Ole >=20 --L5TK0RGqbNWPhMID1vu7ENUj6BnKcVSfg 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUG4U0ACgkQ8AA1q7Z/VrK9qQCfcN6SBkh39HNoB2i2ff36oMnQ 71EAn0ueQc/kXWwMKxISBxqp+HvQRrnl =+Zjg -----END PGP SIGNATURE----- --L5TK0RGqbNWPhMID1vu7ENUj6BnKcVSfg-- From nobody Mon Mar 16 07:01:14 2015 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 24DED1A8756 for ; Mon, 16 Mar 2015 07:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 4iUtu-HpuXxW for ; Mon, 16 Mar 2015 07:01:12 -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 E16231A8758 for ; Mon, 16 Mar 2015 07:01:11 -0700 (PDT) Received: from mb-aye.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 t2GE16bh008308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Mar 2015 14:01:07 GMT (envelope-from joelja@bogus.com) Message-ID: <5506E21D.80000@bogus.com> Date: Mon, 16 Mar 2015 07:01:01 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Ted Lemon , Fernando Gont References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506BF1A.5050303@si6networks.com> <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> In-Reply-To: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H0V0GCQK48LrIjjsccOEhlgbafXRvapUL" Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 14:01:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H0V0GCQK48LrIjjsccOEhlgbafXRvapUL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/16/15 6:54 AM, Ted Lemon wrote: > On Mar 16, 2015, at 7:31 AM, Fernando Gont wrot= e: >> You're assuming that between source and destination there are only >> RFC1812-like IPv6 routers. But devices enforcing ACLs, firewalls, >> load-balancers and the like usually end up having to look into your >> packets. >=20 > Why on earth would an ISP enforce ACLs? Lets live in the real world shall we? http://customer.comcast.com/help-and-support/internet/email-port-25-no-lo= nger-supported/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --H0V0GCQK48LrIjjsccOEhlgbafXRvapUL 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUG4h0ACgkQ8AA1q7Z/VrKhtwCfUuFdoDyCC9hYwlxJ/G/Waj1I s5IAoIwNaAFkwptQK+JzB6cPzavsKC1/ =/Pgf -----END PGP SIGNATURE----- --H0V0GCQK48LrIjjsccOEhlgbafXRvapUL-- From nobody Mon Mar 16 07:05:57 2015 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 D8C8D1A876E for ; Mon, 16 Mar 2015 07:05:49 -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 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 NmlEYp1D3ubN for ; Mon, 16 Mar 2015 07:05:43 -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 92EA01A87A7 for ; Mon, 16 Mar 2015 07:05:20 -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.1/8.14.9) with ESMTPSA id t2GE564M001825 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 14:05:06 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <5506E311.4090201@foobar.org> Date: Mon, 16 Mar 2015 14:05:05 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan , joel jaeggli References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506D3A3.4070500@bogus.com> <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> In-Reply-To: <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 14:05:51 -0000 On 16/03/2015 13:40, Ole Troan wrote: > yes, but I wouldn’t expect my packets to be subject to L4 ACLs in the > middle of the network. There are many legitimate reasons to have l4 ACLs in the core. Joel pointed out iACLs. I'll point out Flowspec and router control plane policing / RE firewalling rules. > yes, but I wouldn’t expect my packets to be subject to L4 ACLs in the > middle of the network. are you saying there is equipment out there that > tries to do ECMP, fails to find the 5 tuple and drops? no, much worse. it tries to do ECMP, fails to find a functional n-tuple, then jams all the traffic down the same bundle member, overloads that link and causes apparently arbitrary third party packet loss. Nick From nobody Mon Mar 16 07:07:54 2015 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 1163B1A877B for ; Mon, 16 Mar 2015 07:07:43 -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 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 K3_fuihR1lNN for ; Mon, 16 Mar 2015 07:07:40 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F28D1A876B for ; Mon, 16 Mar 2015 07:07:36 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 665CE6312; Mon, 16 Mar 2015 07:07:35 -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=1p/bEW2Bx/0cfO4DY60UIVVCTo0=; b= m+F9BoFb3lHTCiIRcp6u1takJHi2OnDnRVfZC+t42CDBONyRica/MKZIkZ+ev7ln oeqj3tbSJTSk/VgytCJbAyOGrT3VJBTHnPD4ILYzu+xkwMluXrc+VZxaGxnPySIk xNazXpCt7AodiZBVe1/yvL1UqWFf9tGG+bRQxdKzSTU= 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=hUnExJ7qDCKeY9EW1TI+arV8go Hkx9Jh56GM47qJ1PF1F4v26oKZWy2S36YQLoyaHeQFPF+h/lBO6eCr16AmRWcuU0 04aMXeFugNZf+4QIFlSfKO0xCm8L1RjY2q+UIxfDuk5FC3SBn7wSPKyJLcCO2DLa pdQSqWLZz5S2K04So= Received: from gomlefisk.localdomain (unknown [173.38.220.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 02DE162C6; Mon, 16 Mar 2015 07:07:35 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 353B840C5DF5; Mon, 16 Mar 2015 15:07:32 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E79894C4-3C1F-41A8-AD2E-62237122C256"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <5506E14C.8040803@bogus.com> Date: Mon, 16 Mar 2015 15:07:31 +0100 Message-Id: References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506D3A3.4070500@bogus.com> <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> <5506E14C.8040803@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.2087) Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 14:07:43 -0000 --Apple-Mail=_E79894C4-3C1F-41A8-AD2E-62237122C256 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joel, >>> same reason as in v4: >>>=20 >>> There's not enough entropy in the ip header for hashing >>=20 >> if it is for ECMP then I think Steinar=E2=80=99s measure were a = little brutal. >>=20 >>> Application of l4 acls means finding the header. >>=20 >> yes, but I wouldn=E2=80=99t expect my packets to be subject to L4 = ACLs in the middle of the network. >=20 > If you reason about a network, and the doesn't include the existence = of > acls on the edges then your model is pretty bad. if you have followed the thread, I=E2=80=99m assuming there is network = policy applied close to the two endpoints. there seemed to be indication that there might be filtering done outside = of the administrative domains of the two endpoints, I would be = interested in knowing and understanding more about that. I=E2=80=99m also assuming that whatever e.g. cisco IT does with their = firewalls isn=E2=80=99t something the IETF can do anything about. >=20 >> are you saying there is equipment out there that tries to do ECMP, = fails to find the 5 tuple and drops? >=20 > While I would expect all sorts of abberant behavior from a failure to > hash like all those flows groomed onto one link I would not expect = drops > from a router. a load balancer on the other hand absolutely. right, but load balancers are in my view a part of the =E2=80=9Cservice=E2= =80=9D. and I=E2=80=99m not particularly concerned about those not = letting through any other packets than those that are part of the = service. (which seems to be a large part of Fernando=E2=80=99s tests). cheers, Ole --Apple-Mail=_E79894C4-3C1F-41A8-AD2E-62237122C256 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 iQEcBAEBCgAGBQJVBuOjAAoJEFuJXizso86gEQEH/1bdu6JRYtHssr+xqSVrPkOO lH56m1LBJOP7/kl8iTEAIMicapdas1M6dnovP7jZP+UEUZJYXSVdfARJRpA5a1pb LGogeTjntws5pg7uWJCmBT55tVL4bxkvbUEhneDf/JHRarF2e/n+DLTV9Mf0AHQK Bb1KqmFhqQW1592XntgHAj2f8SnImXIHuT+YfDDdDOrJBu+cRMjn3sddQuHYNTO0 YJFeIHwpSuuVpZwNBZ3/rno//ACrHm4h+2gekhPEKLCYKzu1QnBymsCtUEXVD29Y LnMxbygNietTmL836N9h8VIORFmUfdwevtbuvy14kCZIsSnMLuoec7oLLzSJLMA= =Kdw5 -----END PGP SIGNATURE----- --Apple-Mail=_E79894C4-3C1F-41A8-AD2E-62237122C256-- From nobody Mon Mar 16 07:19:31 2015 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 C7B521A875B for ; Mon, 16 Mar 2015 07:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 8kq9vv4Jgv_I for ; Mon, 16 Mar 2015 07:19:29 -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 6EB5B1A8758 for ; Mon, 16 Mar 2015 07:19:29 -0700 (PDT) Received: from mb-aye.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 t2GEIKE1008465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Mar 2015 14:18:21 GMT (envelope-from joelja@bogus.com) Message-ID: <5506E627.70909@bogus.com> Date: Mon, 16 Mar 2015 07:18:15 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Ole Troan References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506D3A3.4070500@bogus.com> <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> <5506E14C.8040803@bogus.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4uv5PJkWmINtPFsLEAJSTX60jN0C0rLF2" Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 14:19:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4uv5PJkWmINtPFsLEAJSTX60jN0C0rLF2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/16/15 7:07 AM, Ole Troan wrote: > Joel, >=20 >>>> same reason as in v4: >>>>=20 >>>> There's not enough entropy in the ip header for hashing >>>=20 >>> if it is for ECMP then I think Steinar=E2=80=99s measure were a littl= e >>> brutal. >>>=20 >>>> Application of l4 acls means finding the header. >>>=20 >>> yes, but I wouldn=E2=80=99t expect my packets to be subject to L4 ACL= s in >>> the middle of the network. >>=20 >> If you reason about a network, and the doesn't include the >> existence of acls on the edges then your model is pretty bad. >=20 > if you have followed the thread, I=E2=80=99m assuming there is network = policy > applied close to the two endpoints. there seemed to be indication > that there might be filtering done outside of the administrative > domains of the two endpoints, I would be interested in knowing and > understanding more about that. You definition of close to the endpoints and mine may vary, there are certainly L4 acls applied in residential ISPs, datacenter network operators and even transit ISPs at places other than ingress from the customer for reasons of manageability convenience or scalability. Anyone who has employed flowspec either in their own network or at the behest of a customer has probobaly installed an l4 acl someplace other than the customer edge. > I=E2=80=99m also assuming that whatever e.g. cisco IT does with their > firewalls isn=E2=80=99t something the IETF can do anything about. >=20 >>=20 >>> are you saying there is equipment out there that tries to do >>> ECMP, fails to find the 5 tuple and drops? >>=20 >> While I would expect all sorts of abberant behavior from a failure >> to hash like all those flows groomed onto one link I would not >> expect drops from a router. a load balancer on the other hand >> absolutely. >=20 > right, but load balancers are in my view a part of the =E2=80=9Cservice= =E2=80=9D. > and I=E2=80=99m not particularly concerned about those not letting thro= ugh > any other packets than those that are part of the service. (which > seems to be a large part of Fernando=E2=80=99s tests). >=20 > cheers, Ole >=20 --4uv5PJkWmINtPFsLEAJSTX60jN0C0rLF2 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUG5icACgkQ8AA1q7Z/VrKDOgCfQugmmE63udiTUeDNdzmzGxhl WqQAn3HytAXJEmu7QGHQ3w21fs2ppmmI =5US6 -----END PGP SIGNATURE----- --4uv5PJkWmINtPFsLEAJSTX60jN0C0rLF2-- From nobody Mon Mar 16 07:23:04 2015 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 B1CAA1A8793 for ; Mon, 16 Mar 2015 07:23:02 -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 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_SpkCbanSib for ; Mon, 16 Mar 2015 07:23:00 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E101A875B for ; Mon, 16 Mar 2015 07:23:00 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 9442D62C6; Mon, 16 Mar 2015 07:22:59 -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=bs5LmAUOkQ/lEua8omadEgBX+tQ=; b= Q4t8v0/oKmty1hzZmTyUIfm1h9HU01dxWKpW1t4Ui+GOlUiaEGs8UrcXvJ2XD9y7 8JJcjt2MA19sar7djhBybfrNb9V6rMeDD3Lp6hSlR7RL0JJ5EWixMA+PSWXJssV6 0NPxh2wsY9CWLfYK8kCGtP4sJhfzykL6D4awVt947xE= 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=FThta89DU2ypG9Bb1Ur+bhXX9g SVB+MraEzVNJKBjF+XtzSLAoTnSHY42uRO2JHre8o8QjDccPkBRCCSEE4RyA89rM ZSDla/VTOFA22I0B7QOx7QeiRPRt9UtVn4ulfGeL2uLKjeJ/ch7QIJy4SL0Ykrpt 0cTXxUXIk4j/kFfNk= Received: from gomlefisk.localdomain (unknown [173.38.220.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 2B43A62AD; Mon, 16 Mar 2015 07:22:59 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 753BB40C6385; Mon, 16 Mar 2015 15:22:56 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E949A640-EF36-4B3E-BDF8-7CF1A06E7C67"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Ole Troan In-Reply-To: <5506E627.70909@bogus.com> Date: Mon, 16 Mar 2015 15:22:55 +0100 Message-Id: References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506D3A3.4070500@bogus.com> <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> <5506E14C.8040803@bogus.com> <5506E627.70909@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.2087) Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 14:23:02 -0000 --Apple-Mail=_E949A640-EF36-4B3E-BDF8-7CF1A06E7C67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joel, > Anyone who has employed flowspec either in their own network or at the > behest of a customer has probobaly installed an l4 acl someplace other > than the customer edge. I would be interested in identifying the other cases, not the =E2=80=9Cat = the behest of a customer=E2=80=9D case. the IETF shouldn=E2=80=99t = prohibit people from breaking their Internet connection. ;-) cheers, Ole --Apple-Mail=_E949A640-EF36-4B3E-BDF8-7CF1A06E7C67 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 iQEcBAEBCgAGBQJVBudAAAoJEFuJXizso86gCXsH/2vrKHx52rRLGdxBVH7apyRt wAp4vHmrC4DM6vpzCQF+Zw1Es4zYAHrtBYEeQPTsz/tUKd6IbV01DuA9yivDT3jp IfAf6sLlse7v6qHFL4TowEwR+MPIxFQJZrqE2oPw6s+ufVtofOZHoKam4Wk9C0zM I4CqJHUZqnIO2gcPOjMliHXiqG1pJBM9cDAHyK8RFFO5Sk086OCl3zDrDwc07++K zJrsgo2zFHGtX4TlP2Hq+0KaOK1WRTcAaZ+jdoVG7vrTiKOSzW97QZoeB15KCpjM FH2afdF1P5+h63EV7sjdojsJDnyxRxcbErQJFAkj62PC5QBZhI9lkXUpr44/Et0= =Pmwf -----END PGP SIGNATURE----- --Apple-Mail=_E949A640-EF36-4B3E-BDF8-7CF1A06E7C67-- From nobody Mon Mar 16 07:31:29 2015 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 35B431A87A8 for ; Mon, 16 Mar 2015 07:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 wAvpR8QOWVdz for ; Mon, 16 Mar 2015 07:31:26 -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 247251A877D for ; Mon, 16 Mar 2015 07:31:26 -0700 (PDT) Received: from mb-aye.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 t2GEVH3g008591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Mar 2015 14:31:17 GMT (envelope-from joelja@bogus.com) Message-ID: <5506E92F.3010706@bogus.com> Date: Mon, 16 Mar 2015 07:31:11 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Ole Troan References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506D3A3.4070500@bogus.com> <72A5AE9B-E98B-4B8C-9B09-649FD7D3E2B3@employees.org> <5506E14C.8040803@bogus.com> <5506E627.70909@bogus.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wNw7ag4f3h2IsRWsPT03P9Xv8gRDqRjug" Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 14:31:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wNw7ag4f3h2IsRWsPT03P9Xv8gRDqRjug Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/16/15 7:22 AM, Ole Troan wrote: > Joel, >=20 >> Anyone who has employed flowspec either in their own network or at >> the behest of a customer has probobaly installed an l4 acl >> someplace other than the customer edge. >=20 > I would be interested in identifying the other cases, not the =E2=80=9C= at the > behest of a customer=E2=80=9D case. the IETF shouldn=E2=80=99t prohibit= people from > breaking their Internet connection. ;-) If you have to match on a particular header for a source or destination prefix and you can't find it, the baby goes out with the bathwater. > cheers, Ole >=20 --wNw7ag4f3h2IsRWsPT03P9Xv8gRDqRjug 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUG6S8ACgkQ8AA1q7Z/VrIMHACeOhrmB+8/K8ZLA5EptD8NJYOn VqoAnA2IRvlvG2GtCBfyzmh69BP/lJg6 =1BGp -----END PGP SIGNATURE----- --wNw7ag4f3h2IsRWsPT03P9Xv8gRDqRjug-- From nobody Mon Mar 16 08:23:58 2015 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 43B251A885A for ; Mon, 16 Mar 2015 08:23:57 -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 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 XERxOOLLZEFt for ; Mon, 16 Mar 2015 08:23:54 -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 7CF8F1A8854 for ; Mon, 16 Mar 2015 08:23:54 -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.1/8.14.9) with ESMTPSA id t2GFNjZG003490 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 15:23:46 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <5506F580.3000607@foobar.org> Date: Mon, 16 Mar 2015 15:23:44 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: joel jaeggli , Ted Lemon , Fernando Gont References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506BF1A.5050303@si6networks.com> <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> In-Reply-To: <5506E21D.80000@bogus.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 15:23:57 -0000 On 16/03/2015 14:01, joel jaeggli wrote: > On 3/16/15 6:54 AM, Ted Lemon wrote: >> On Mar 16, 2015, at 7:31 AM, Fernando Gont wrote: >>> You're assuming that between source and destination there are only >>> RFC1812-like IPv6 routers. But devices enforcing ACLs, firewalls, >>> load-balancers and the like usually end up having to look into your >>> packets. >> >> Why on earth would an ISP enforce ACLs? > > Lets live in the real world shall we? > > http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/ All right... all right... but apart from infrastructure ACLs, DDoS management, working ECMP and other hash-based load-balancing implementations, customer requests for filtering, implementation of edge-to-core customer sanitisation filters and route-processor protection, what do we need functional ipv6 L4 packet for??!? Nick From nobody Mon Mar 16 09:37:40 2015 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 E2F091A88C4 for ; Mon, 16 Mar 2015 09:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 WYh2VgNEAlPk for ; Mon, 16 Mar 2015 09:37:36 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.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 3EEC11A88C1 for ; Mon, 16 Mar 2015 09:37:36 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id A42EDDA0210; Mon, 16 Mar 2015 16:37:35 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 16 Mar 2015 09:37:30 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5506E21D.80000@bogus.com> Date: Mon, 16 Mar 2015 12:36:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506BF1A.5050303@si6networks.com> <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: silvia.hagen@sunny.ch, Fernando Gont , v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 16:37:39 -0000 On Mar 16, 2015, at 10:01 AM, joel jaeggli wrote: >> Why on earth would an ISP enforce ACLs? > Lets live in the real world shall we? > = http://customer.comcast.com/help-and-support/internet/email-port-25-no-lon= ger-supported/ Ah, so the reason that an ISP would enforce ACLs is because of a = protocol with a lousy security model that is only fixable (and even = then, not very) with the help of firewalls. Fair enough--I had = developed a blind spot about this issue because it's been broken for so = long and we've been reflexively avoiding the brokenness for so long. But essentially what's happening here is that we are seeing a design = flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we should = stop reflexively working around this problem and seriously figure out = how fix it, so that twenty years from now we no longer need a broken = layer 3. From nobody Mon Mar 16 10:19:29 2015 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 720DC1A88EB for ; Mon, 16 Mar 2015 10:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Erqj4fNQLMw9 for ; Mon, 16 Mar 2015 10:19:26 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id C354A1A878E for ; Mon, 16 Mar 2015 10:19:25 -0700 (PDT) Received: (qmail 58528 invoked from network); 16 Mar 2015 17:19:23 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Mar 2015 17:19:23 -0000 Date: Mon, 16 Mar 2015 18:19:23 +0100 (CET) Message-Id: <20150316.181923.74694044.sthaug@nethelp.no> To: Ted.Lemon@nominum.com From: sthaug@nethelp.no In-Reply-To: <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: silvia.hagen@sunny.ch, v6ops@ietf.org, fernando@gont.com.ar, fgont@si6networks.com Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 17:19:28 -0000 > > Lets live in the real world shall we? > > http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/ > > Ah, so the reason that an ISP would enforce ACLs is because of a protocol with a lousy security model that is only fixable (and even then, not very) with the help of firewalls. Fair enough--I had developed a blind spot about this issue because it's been broken for so long and we've been reflexively avoiding the brokenness for so long. > > But essentially what's happening here is that we are seeing a design flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we should stop reflexively working around this problem and seriously figure out how fix it, so that twenty years from now we no longer need a broken layer 3. I'm all for that. However, I cannot afford to wait 20 years for a fix to the problems. My priorities, as I see them: 1. Protect my network. 2. Within reason, protect my customers. 3. Move traffic to and from my customers, in a semi-optimal way. You'll notice that the free-flowing IPv4/IPv6 traffic some people here seem to want is *not* priority number one. In the current Internet environment, "protect my network" is likely to stay on top for the foreseeable future. If that means ACLs and similar tools at other places in the network than just the edges - so be it. Steinar Haug, AS 2116 From nobody Mon Mar 16 10:36:01 2015 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 CE60E1A8920 for ; Mon, 16 Mar 2015 10:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 CA-ovG9VNoP3 for ; Mon, 16 Mar 2015 10:35:57 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 708D31A891D for ; Mon, 16 Mar 2015 10:35:49 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so43669914wib.0 for ; Mon, 16 Mar 2015 10:35:48 -0700 (PDT) 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-type :content-transfer-encoding; bh=r8Ye86lalsD92IWQvp67E1raiGCQXBIpvAJo/3K0twk=; b=Ne/xIF/3Qs8oeUlCjNFDLa1FUfePytyTCToLtHFrpOWU2pjUzXoJkoYcPD5FXQDnYn FPMGeH6xIvsZ47hlQtPSQb9CNaQkLFJswQnlokkAFts9NTGo+aLRxsUxofA2uxSPZJjE +6VCkR/rjF08zM7r2YCrO6jZoEoxJiuXymAWjK78Riz6mO3H4Px0eSOyxKSonaXVaLi2 xevlcZ1/SUj+WOq6vZOksmp2UX4ym52JWMsS5U7TWIfC5IuatDuAzsGuf99EzVDoCpAo LuJP6UWbrzgO9bUtyiXIf8Ys6yHquSMyp3Xq4fGTmSfw78IDHVSngQWA/ccyCIBTIVuM KBlQ== X-Gm-Message-State: ALoCoQke4geX12VzXNXIVafQ3Oi9gOXIkx9feb+IwtOJMbP6DcM4Y/G4OqPv8HDBHpA8+Ur+mD0b MIME-Version: 1.0 X-Received: by 10.180.85.70 with SMTP id f6mr110354420wiz.22.1426527348163; Mon, 16 Mar 2015 10:35:48 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Mon, 16 Mar 2015 10:35:47 -0700 (PDT) In-Reply-To: <20150316.181923.74694044.sthaug@nethelp.no> References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> Date: Mon, 16 Mar 2015 18:35:47 +0100 Message-ID: From: Warren Kumari To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: silvia.hagen@sunny.ch, Fernando Gont , IPv6 Operations , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 17:35:59 -0000 On Mon, Mar 16, 2015 at 6:19 PM, wrote: >> > Lets live in the real world shall we? >> > http://customer.comcast.com/help-and-support/internet/email-port-25-no= -longer-supported/ >> >> Ah, so the reason that an ISP would enforce ACLs is because of a protoco= l with a lousy security model that is only fixable (and even then, not very= ) with the help of firewalls. Fair enough--I had developed a blind spot a= bout this issue because it's been broken for so long and we've been reflexi= vely avoiding the brokenness for so long. >> >> But essentially what's happening here is that we are seeing a design fla= w at layer 7 forcing brokenness at layer 3. Oops. Maybe we should stop = reflexively working around this problem and seriously figure out how fix it= , so that twenty years from now we no longer need a broken layer 3. > > I'm all for that. However, I cannot afford to wait 20 years for a fix > to the problems. My priorities, as I see them: > > 1. Protect my network. > 2. Within reason, protect my customers. > 3. Move traffic to and from my customers, in a semi-optimal way. > > You'll notice that the free-flowing IPv4/IPv6 traffic some people here > seem to want is *not* priority number one. See: Why Operators Filter Fragments and What It Implies draft-taylor-v6ops-fragdrop-02 https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 We keep threatening to bring this back from the dead -- perhaps we'll finally do so... W > > In the current Internet environment, "protect my network" is likely to > stay on top for the foreseeable future. If that means ACLs and similar > tools at other places in the network than just the edges - so be it. > > Steinar Haug, AS 2116 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Mar 16 10:39:30 2015 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 568381A1B86 for ; Mon, 16 Mar 2015 10:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 cyyxp_lNH6Jw for ; Mon, 16 Mar 2015 10:39:28 -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 EBC941A1B6E for ; Mon, 16 Mar 2015 10:39:27 -0700 (PDT) Received: from mb-aye.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 t2GHdIGv009732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Mar 2015 17:39:19 GMT (envelope-from joelja@bogus.com) Message-ID: <55071541.7070802@bogus.com> Date: Mon, 16 Mar 2015 10:39:13 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Ted Lemon References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506BF1A.5050303@si6networks.com> <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> In-Reply-To: <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3q8pM3s0e6x3SNIn4axK1lMa6hToDVqAr" Archived-At: Cc: silvia.hagen@sunny.ch, Fernando Gont , v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 17:39:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3q8pM3s0e6x3SNIn4axK1lMa6hToDVqAr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/16/15 9:36 AM, Ted Lemon wrote: > On Mar 16, 2015, at 10:01 AM, joel jaeggli wrote: >>> Why on earth would an ISP enforce ACLs? >> Lets live in the real world shall we?=20 >> http://customer.comcast.com/help-and-support/internet/email-port-25-no= -longer-supported/ > >>=20 > Ah, so the reason that an ISP would enforce ACLs is because of a > protocol with a lousy security model that is only fixable (and even > then, not very) with the help of firewalls. Fair enough--I had > developed a blind spot about this issue because it's been broken for > so long and we've been reflexively avoiding the brokenness for so > long. >=20 > But essentially what's happening here is that we are seeing a design > flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we > should stop reflexively working around this problem and seriously > figure out how fix it, so that twenty years from now we no longer > need a broken layer 3. Maybe, by I don't dictate the business logic of consumer ISPs and neither does the IETF. I do however appreciate when operators make good faith efforts to deal with attractive nuisances that are otherwise negative externalities for the rest of the internet. I do consider that if the situation gets better their behavior may change= =2E >=20 --3q8pM3s0e6x3SNIn4axK1lMa6hToDVqAr 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUHFUEACgkQ8AA1q7Z/VrJ7rQCeNl1xtf6GDL1cBNgV1X4G2YVz qRMAoITeLYeDcehS1KtSQFmnEJw8ybJi =tZwV -----END PGP SIGNATURE----- --3q8pM3s0e6x3SNIn4axK1lMa6hToDVqAr-- From nobody Mon Mar 16 11:10:43 2015 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 794FE1A89A1 for ; Mon, 16 Mar 2015 11:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 wfMaXZ8LxcfV for ; Mon, 16 Mar 2015 11:10:34 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.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 DB52E1A89B9 for ; Mon, 16 Mar 2015 11:10:33 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 8ACE9DA0212; Mon, 16 Mar 2015 18:10:33 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 16 Mar 2015 11:10:33 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <55071541.7070802@bogus.com> Date: Mon, 16 Mar 2015 14:09:55 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> <20150316.101528.74709844.sthaug@nethelp.no> <5506BF1A.5050303@si6networks.com> <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <55071541.7070802@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: silvia.hagen@sunny.ch, Fernando Gont , v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 18:10:35 -0000 On Mar 16, 2015, at 1:39 PM, joel jaeggli wrote: > Maybe, by I don't dictate the business logic of consumer ISPs and > neither does the IETF. I do however appreciate when operators make = good > faith efforts to deal with attractive nuisances that are otherwise > negative externalities for the rest of the internet. No argument here. > I do consider that if the situation gets better their behavior may = change. Yup, that was my point. I guess a pretty obvious point, but I hadn't = really thought of it that way until reading your previous reply. From nobody Mon Mar 16 11:15:52 2015 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 299541A89BB for ; Mon, 16 Mar 2015 11:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Hl60K-Svfi9T for ; Mon, 16 Mar 2015 11:15:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C299B1A89AF for ; Mon, 16 Mar 2015 11:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2051; q=dns/txt; s=iport; t=1426529749; x=1427739349; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4KNnK9voFnqI9wby8A6NJtvNtyMYhIRjZWAD8UVBr7k=; b=NWDY0jd8ewaThPVAOeLIopzP2ov0UH3gi8Rk665ds8OwwSbQ7oAV95hf 8GNH6uxcBW/VU4vypp9CJGIU7krjZoz7j0eHu34naUDPJQq/6zFY7wn6L pGuBsOXgzaV4SadupE2kOO67D5WAYhpxHBwcupqpCPQTS6/A86ir4yXcf A=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQBUHQdV/4wNJK1bgwaBLATKawKBNUwBAQEBAQF9hA8BAQEDAXkFCwIBCA4KLjIlAgQBDQUOiBkIxzoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeEcQeDF4EWAQSQOoFogS+GT5QUI4IygTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,410,1422921600"; d="asc'?scan'208";a="132510322" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 16 Mar 2015 18:15:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2GIFmjA019192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Mar 2015 18:15:48 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 13:15:47 -0500 From: "Fred Baker (fred)" To: James Woodyatt , Iljitsch van Beijnum , MARCELO BAGNULO BRAUN , "Philip Matthews" Thread-Topic: [v6ops] Stateful NAT64: Strange translation of ICMPv4 error source addresses Thread-Index: AQHQYBU5qa2uG0F5n0eJAFqqSTri0Q== Date: Mon, 16 Mar 2015 18:15:47 +0000 Message-ID: <89D5A5DC-B83A-4DB8-A563-20D07101164D@cisco.com> References: <20150313103615.1380aeb1@echo.ms.redpill-linpro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.122] Content-Type: multipart/signed; boundary="Apple-Mail=_BFA9749E-12B3-425A-B800-C5CB0B11B622"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org" , IPv6 Ops WG , Tore Anderson , "jool@nic.mx" Subject: Re: [v6ops] Stateful NAT64: Strange translation of ICMPv4 error source addresses 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, 16 Mar 2015 18:15:51 -0000 --Apple-Mail=_BFA9749E-12B3-425A-B800-C5CB0B11B622 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 13, 2015, at 10:42 AM, James Woodyatt wrote: >=20 > On Fri, Mar 13, 2015 at 2:36 AM, Tore Anderson wrote: >=20 >> Stateful NAT64 (RFC6146) requires that whenever an ICMPv4 error is >> received from a router in the IPv4 network, the (IPv4-converted) IPv6 >> source address of the translated ICMPv6 error must be set to the >> (IPv4-converted) address of the destination address in the embedded >> ICMPv4 payload, i.e., the original destination of the packet causing >> the ICMPv4 error. I find this rather counter-intuitive - I would = expect >> the (IPv4-converted) address of the IPv4 router originating the = ICMPv4 >> error to be used instead. Is my reading of RFC6146 faulty, or if not, >> is this truly the intented behaviour (why?), or is an erratum = warranted? >=20 > For what it's worth, I would find this counter-intuitive too, and I'd = be surprised if this is really the intended behavior. Hopefully, the = authors of the RFC will respond. Putting the authors of RFC 6146 on the thread explicitly. --Apple-Mail=_BFA9749E-12B3-425A-B800-C5CB0B11B622 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 iQEVAwUBVQcd0Z9ieig10VPpAQKSDwgAjL1Boehg5DcEViY+r545IsXQt5jg9ExI JrOI3MUBd31aTOhioDHS9bzRPoPQjuo4SFmxAPwVaBCH7nl5QeZjKhoAj7scARqB G5yNNxXdQL6LXcFsrPr+v9MxmHPbsoSff+fYytd8YzMXlDmeZ94fTojSroQ4ky8Q Rv77WPl95rGoDXsfh9DS5POIChZaAS8cS2C0Uc4iWRTOqKohk4vCcQL+pCQ1ldTY kjG+ZrKsRmAGFVsUFvcumk7708zfVPBsGcclfq8UmXim+HNylvReY7ndXRcLj3vs lKbml17OC+U9bVmtQF0bqCzX8tSjI4oPhcPeHkIhR0NiIPQSL9BHYw== =5719 -----END PGP SIGNATURE----- --Apple-Mail=_BFA9749E-12B3-425A-B800-C5CB0B11B622-- From nobody Mon Mar 16 12:14:37 2015 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 2A5C51A8AAE for ; Mon, 16 Mar 2015 12:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 KmliB5mPEexM for ; Mon, 16 Mar 2015 12:14:34 -0700 (PDT) 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 AE5C81A8AB4 for ; Mon, 16 Mar 2015 12:14:34 -0700 (PDT) Received: by pagr17 with SMTP id r17so73123778pag.0 for ; Mon, 16 Mar 2015 12:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xNNh2DvgbCtcsIju4oUnHIUy0H6pOzWSkgRh8CV8/SI=; b=gVAEGwM5UZ99Ysnqyl8dbNX9TBizx5UX+XymV3oTesEyG7jeutzmn+rsoOX8+tI6jm kiTqE1bZlLDzf6tehokFYTBcm1xIkysC3foPEX2K0KeC63eykPMhyIs0mfKOAyZur695 k3GwGLUA+sQ6IGIPKHbZqVxsFK3RBOfRl4e5llznRcz6GA77J24ABCV42n1G31TuQMTy GhO2/bz7toG0vNk/TruI4isA07EbfLdhufWBc6yOe64YcrTQ/oiTP8OC/2WOM19KBlSB BPjRUzDSfoVdExmzINw1lLV0V5WQYztFy2A0VYwlSPjfqhaTczR3TuNa0IqcoaBYxzwl IQSw== X-Received: by 10.66.101.106 with SMTP id ff10mr144085789pab.103.1426533274418; Mon, 16 Mar 2015 12:14:34 -0700 (PDT) Received: from ?IPv6:2406:e007:50da:1:28cc:dc4c:9703:6781? ([2406:e007:50da:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id mb4sm18553574pdb.41.2015.03.16.12.14.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 12:14:33 -0700 (PDT) Message-ID: <55072B97.7010902@gmail.com> Date: Tue, 17 Mar 2015 08:14:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ole Troan References: <20150309053609.23108.65862.idtracker@ietfa.amsl.com> <54FE4416.60601@gont.com.ar> <1BBB5D05-CC92-4888-A9DD-5E90CF1C8473@employees.org> <55019C0C.2050102@foobar.org> <8559E316-267E-4FA9-8473-E99C788DD93F@employees.org> <55020214.60607@foobar.org> <550205D5.3020504@gmail.com> <2A1AF4A8-B923-4200-9A6C-4406729D167F@employees.org> <550212CB.2090306@foobar.org> <55021899.7080908@foobar.org> <5502E584.1080204@gont.com.ar> <55038095.3070109@gmail.com> <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> In-Reply-To: <417A7F9A-08D4-4269-B94C-817EF62FA7F3@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Silvia Hagen , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 16 Mar 2015 19:14:36 -0000 On 16/03/2015 21:29, Ole Troan wrote: > Brian, >=20 >> And chip-level hardware designers will explain to you exactly why this= >> is a painfully expensive thing to do at line speed. This stuff was >> designed by software people at the tail end of the 32-bit minicomputer= >> era, and things looked different to them^H^H^H^Hus than they do to a >> 21st century chip designer. >=20 > that is not how I recall history. > I vividly recall a conversation with Steve back in 1998 or 1999 when he= got confronted with this, stated that it was a design feature. extension= headers are designed to be hard to parse in hardware, cause routers aren= =E2=80=99t supposed to be doing that. That's true too: Steve's position was that middleboxes are evil and there= fore should not be considered during the design. So it wasn't a consideration,= whereas convenient parsing on a VAX was. The point is, the resulting desi= gn is very *inconvenient* for hardware protocol engines. Brian >=20 > has anything changed in the last 15-20 years? I didn=E2=80=99t think th= ere was IETF consensus to modify protocols to be easier on middleboxes. >=20 > cheers, > Ole >=20 From nobody Mon Mar 16 17:57:52 2015 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 38D971ACD97 for ; Mon, 16 Mar 2015 17:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.535 X-Spam-Level: ** X-Spam-Status: No, score=2.535 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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_REPLYTO=0.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 jQ04sv-sUWuk for ; Mon, 16 Mar 2015 17:57:50 -0700 (PDT) Received: from nm46-vm8.bullet.mail.gq1.yahoo.com (nm46-vm8.bullet.mail.gq1.yahoo.com [67.195.87.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C481A1BEC for ; Mon, 16 Mar 2015 17:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1426553869; bh=wMI42NC+Js1vArellkceQbx65aUn+pwtNCwSkvgazXk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=MSJMFoyhkC4IWIKdcfFGap5VRVK/OmZS39xsLE9CoXZciQFdLgapO8LBiSkYbF+5o+iM98h6Zehqdds8Xlol008ySR11l2qfeRVnZmXPFfhvDiNnBZa96SRud5KHFUMFohNud70nIeEYlb6lGDKdm/M26ReTTyZCRDWdG78wB8A/AACwbS8wiRY0NDXjbaZFrS3o6erdmS/G/A4AGSb7IuDVsFC6xu3ASmz4AbX9BLBDhdlOGCLwDxKyL2h2Qap3GSrPnXAqF+wv76uvykwxJNmq+ulHdn6X44PzqqULG1Wpdb6O8V3c9YhOYGDhLKYExg45tPxaIVe6kK/yLUYWCQ== Received: from [127.0.0.1] by nm46.bullet.mail.gq1.yahoo.com with NNFMP; 17 Mar 2015 00:57:49 -0000 Received: from [98.137.12.175] by nm46.bullet.mail.gq1.yahoo.com with NNFMP; 17 Mar 2015 00:54:48 -0000 Received: from [66.196.81.173] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 17 Mar 2015 00:54:48 -0000 Received: from [98.139.212.217] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 00:54:47 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 00:54:47 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 954207.77270.bm@omp1026.mail.bf1.yahoo.com X-YMail-OSG: wfwRuEQVM1kdCU1JRe2KsgYAyiZdGljoN_5MerVnZIac7KGDMT6KsEtXSMmQapw AABWhY9jNEtBM5ZJhB8qb9ervCDxxBOsB4Ryn95z8OfvkqACZYITKZtapxL2_dKw0TrH4d4TCj0m CzfwVhDeHPZDGv5bPtqc7GtspsulCeR1a0folaeG5sCpRXtWg4unGLXu9FKJ1myeYg11bzuBhPzA XpiTQ6Z3KxKNkdy3qbnCo0j1lEJR8MaYHIbGO4s4XGcnz8iEqDp3AO4qz_RvpOfZv_DUUwtceZwu hTJtAjJO8IRYsXLX_OCguXfU079mrVzpr3_Y7vwPXm6Vy0XcnOtxddr_AU9ZeK1cFvZzMn.GE79e LNukMu1jnwKyNsO8_FUqghM8qR2gdiAxTDC0J1nE0uJdTr6GVtiBUggzsXdXclvtHTYBAYKvIvUu 2pxxnG5Dq0uMtDBSr7EguwxkjHLi1rzPcFr5kc_yr5hajqwrAfa1b7XlgYdQg8JT0n3D3B1tjPOc 5HKfuD2.n9M3oxh8PP0sLe44QwaOUxf8fTvnpCe.LhGgNzlN35cppNYnfq_JZ Received: by 66.196.80.115; Tue, 17 Mar 2015 00:54:47 +0000 Date: Tue, 17 Mar 2015 00:54:41 +0000 (UTC) From: Mark ZZZ Smith To: Nick Hilliard , Gert Doering Message-ID: <1645755951.1004066.1426553681927.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <5503265E.1060201@foobar.org> References: <5503265E.1060201@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 00:57:51 -0000 So the reason I care about it and I think it is important to resolve is that the only significant reason I can think of to deploy link-local only links/interfaces is for security reasons. The address conservation reason to deploy unnumbered IPv4 links doesn't apply in IPv6. If people are deploying link-local only links exclusively for security reasons, then I think it is important that the security properties of them are clear and obvious. Accurate naming of them, and having a different name to similarly configured links in IPv4 (because they are different), would help avoid the sorts of security issues that pop up when people put in place security measures that don't behave exactly how they expect. Regards, Mark. ________________________________ From: Nick Hilliard To: Mark ZZZ Smith ; Gert Doering Cc: "v6ops@ietf.org" Sent: Saturday, 14 March 2015, 5:03 Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? On 12/03/2015 23:43, Mark ZZZ Smith wrote: > If you don't ensure clarity and accuracy, simple misunderstandings can > have catastrophic consequences : For sure, yes. I'm just suggesting that 70 emails to discuss this topic so far (13 emails in the original thread and 57 emails so far in this thread) is bike-shedding. / So the reason I care about it and I think it is important to resolve is that the only significant reason I can think of to deploy link-local only links/interfaces is for security reasons. The address conservation reason to deploy unnumbered IPv4 links doesn't apply in IPv6. / If people are deploying link-local only links exclusively for security reasons, then I think it is important that the security properties of them are clear and obvious. Accurate naming of them, and having a different name to similarly configured links in IPv4 (because they are different), would help avoid the sorts of security vulnerabilities that can occur when people put in place security measures that don't behave exactly how they expect. / Regards, Mark. Nick From nobody Tue Mar 17 06:52:50 2015 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 3187F1A1A29 for ; Tue, 17 Mar 2015 06:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 k_leLssrzKJa for ; Tue, 17 Mar 2015 06:52:47 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051B51A1A27 for ; Tue, 17 Mar 2015 06:52:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CC2B8A1; Tue, 17 Mar 2015 14:52:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1426600364; bh=XlWebaDaCckdoC8yqwN17IjHBbKwtOqu7c9/OmP1S4s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=0/8txWD0p26zn587O2tdYnIYpP4IQVBo3nfr9PGaG7r05xCSIux67gifbgVgWF8HW IckziWxPBz2VZ+E+f0bQPXtbiWzFo3YkBWJvYEPfX4zh2ESi8LvhZt+oNHe0YmAlmb Q7FfpuajTxJjz6H1FGH1FAFZqFMre7fAEt+P/AbQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C28FF9F; Tue, 17 Mar 2015 14:52:44 +0100 (CET) Date: Tue, 17 Mar 2015 14:52:44 +0100 (CET) From: Mikael Abrahamsson To: sthaug@nethelp.no In-Reply-To: <20150316.181923.74694044.sthaug@nethelp.no> Message-ID: References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: silvia.hagen@sunny.ch, fgont@si6networks.com, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 17 Mar 2015 13:52:49 -0000 On Mon, 16 Mar 2015, sthaug@nethelp.no wrote: >>> Lets live in the real world shall we? >>> http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/ >> >> Ah, so the reason that an ISP would enforce ACLs is because of a protocol with a lousy security model that is only fixable (and even then, not very) with the help of firewalls. Fair enough--I had developed a blind spot about this issue because it's been broken for so long and we've been reflexively avoiding the brokenness for so long. >> >> But essentially what's happening here is that we are seeing a design flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we should stop reflexively working around this problem and seriously figure out how fix it, so that twenty years from now we no longer need a broken layer 3. > > I'm all for that. However, I cannot afford to wait 20 years for a fix > to the problems. My priorities, as I see them: > > 1. Protect my network. > 2. Within reason, protect my customers. > 3. Move traffic to and from my customers, in a semi-optimal way. Please also add 4. "Protect the Internet from your customers". This is something too many miss. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Mar 17 07:11:24 2015 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 443611A1A62 for ; Tue, 17 Mar 2015 07:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3] 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 3Q1wKLH30Xc4 for ; Tue, 17 Mar 2015 07:11:19 -0700 (PDT) Received: from Mail.Yoyodyne.COM (Mail.Yoyodyne.com [69.36.251.10]) by ietfa.amsl.com (Postfix) with SMTP id 423461A1A5B for ; Tue, 17 Mar 2015 07:11:19 -0700 (PDT) Received: from [IPv6:2a02:8071:f00:10:2871:d8de:13e:1cc1] ([2a02:8071:f00:10:2871:d8de:13e:1cc1]) by Mail.Yoyodyne.COM via Internet for (and others); Tue, 17 Mar 2015 07:11:09 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: Date: Tue, 17 Mar 2015 07:10:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1510) Archived-At: Cc: silvia.hagen@sunny.ch, fgont@si6networks.com, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 17 Mar 2015 14:11:23 -0000 On Mar 17, 2015, at 6:52 AM, Mikael Abrahamsson = wrote: > On Mon, 16 Mar 2015, sthaug@nethelp.no wrote: >=20 >>>> Lets live in the real world shall we? >>>> = http://customer.comcast.com/help-and-support/internet/email-port-25-no-lon= ger-supported/ >>>=20 >>> Ah, so the reason that an ISP would enforce ACLs is because of a = protocol with a lousy security model that is only fixable (and even = then, not very) with the help of firewalls. Fair enough--I had = developed a blind spot about this issue because it's been broken for so = long and we've been reflexively avoiding the brokenness for so long. >>>=20 >>> But essentially what's happening here is that we are seeing a design = flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we should = stop reflexively working around this problem and seriously figure out = how fix it, so that twenty years from now we no longer need a broken = layer 3. >>=20 >> I'm all for that. However, I cannot afford to wait 20 years for a fix >> to the problems. My priorities, as I see them: >>=20 >> 1. Protect my network. >> 2. Within reason, protect my customers. >> 3. Move traffic to and from my customers, in a semi-optimal way. >=20 > Please also add 4. "Protect the Internet from your customers". This is = something too many miss. I for one am really glad that we are getting operational reality input. = Thank you. FWIW, I'm sitting next to Fernando at a security conference = we are both at and I had offered to help with this draft. This was a few months ago. = What I see is that we are in need of some additional measurements and = that will happen. I would love to see some added input on this list in how = to improve measurements rather than the criticism of just how current = measurements have been done. Collectively gathering operational realities is a good = thing for added input on how to deal with EHs. And FWIW, I am not in = favor of deprecating EHs since that is too drastic but we as a community have to = understand where they are practically used and where they are dropped = for reasons that some deem as necessary. - merike From nobody Tue Mar 17 09:26:55 2015 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 3015D1A8775 for ; Tue, 17 Mar 2015 09:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-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 G0igcYWIyLe7 for ; Tue, 17 Mar 2015 09:26:52 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 9F4121A8776 for ; Tue, 17 Mar 2015 09:26:28 -0700 (PDT) Received: from [2a02:8071:f00:10:5107:582c:4aeb:8ee] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YXuK1-000788-N5; Tue, 17 Mar 2015 17:26:25 +0100 Message-ID: <55085545.4070607@si6networks.com> Date: Tue, 17 Mar 2015 17:24:37 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 17 Mar 2015 16:26:54 -0000 Folks, Since the question as been asked, hereby I'm providing a heads-up about our finding regarding transit ASes that are filtering IPv6 EH-enabled packets. -- sme folks my be willing to double-check with the relevant people, and possibly inquire the reasoning behind the filtering decision. Here we are just consider "best-case scenarios" (please see draft-gont-ipv6-ehs-in-real-world for a definition of what we mean by that): * Folks filtering packets with Dest Options EHs AS 2119 (TELENOR-NEXTEL Telenor Norge AS,NO) AS 286 (KPN KPN International / KPN Eurorings,NL) AS 3356 (LEVEL3 - Level 3 Communications, Inc.,US) * Folks filtering packets with HBH EHs: (0.31%): AS 174 (COGENT-174 - Cogent Communications,US) (1.89%): AS 286 (KPN KPN International / KPN Eurorings,NL) (1.13%): AS 1273 (CW Cable and Wireless Worldwide plc,GB) (14.42%): AS 1299 (TELIANET TeliaSonera International Carrier,SE) (0.31%): AS 1764 (NEXTLAYER-AS next layer Telekommunikationsdienstleistungs- GmbH,AT) (0.38%): AS 3257 (TINET-BACKBONE Tinet SpA,DE) (81.50%): AS 3356 (LEVEL3 - Level 3 Communications, Inc.,US) (0.31%): AS 5588 (GTSCE T-Mobile Czech Republic a.s.,CZ) (0.31%): AS 6695 (DECIX-AS DE-CIX Management GmbH,DE) (0.94%): AS 8218 (NEO-ASN Neo Telecoms S.A.S.,FR) (0.31%): AS 8447 (TELEKOM-AT A1 Telekom Austria AG,AT) (0.31%): AS 8767 (MNET-AS M-net Telekommunikations GmbH, Germany,DE) (0.31%): AS 9063 (SAARGATE-AS VSE NET GmbH,DE) (0.19%): AS 12389 (ROSTELECOM-AS OJSC Rostelecom,RU) (0.19%): AS 16086 (DNA DNA Oy,FI) (0.63%): AS 20676 (QSC-1 QSC AG,DE) (0.19%): AS 29470 (RETNNET-AS CJSC _RetnNet_,RU) (0.19%): AS 34984 (TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR) (0.31%): AS 36623 (HGTLD - VeriSign Global Registry Services,US) * Folks filtering Fragments AS 6939 (HURRICANE - Hurricane Electric, Inc.,US) AS 34779 (T-2-AS T-2, d.o.o.,SI) FWIW, this post should not be considered a "wall of shame", but, if anything, a "wall of reality". Thanks! Cheers, -- 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 17 09:48:52 2015 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 8409A1A875B for ; Tue, 17 Mar 2015 09:48:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 6ZNdW6W2J0FH for ; Tue, 17 Mar 2015 09:48:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0079E1A1B4B for ; Tue, 17 Mar 2015 09:48:48 -0700 (PDT) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 17 Mar 2015 16:48:48 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0099.004; Tue, 17 Mar 2015 16:48:47 +0000 From: "Metzler, Dan J" To: Fernando Gont , "v6ops@ietf.org" Thread-Topic: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets Thread-Index: AQHQYM9AfziUBPtQPkKsF1+LV32tQ50g3inA Date: Tue, 17 Mar 2015 16:48:47 +0000 Message-ID: References: <55085545.4070607@si6networks.com> In-Reply-To: <55085545.4070607@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:0:e50:1001:88da:a74c:f548:c727] authentication-results: si6networks.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(252514010)(377454003)(41574002)(13464003)(51704005)(2501003)(15975445007)(77096005)(86362001)(99286002)(33656002)(2950100001)(92566002)(76576001)(19580395003)(88552001)(2900100001)(89122001)(19580405001)(102836002)(46102003)(87936001)(2656002)(106116001)(75432002)(90282001)(76176999)(54356999)(50986999)(62966003)(107886001)(77156002)(40100003)(122556002)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001010); SRVR:CO2PR04MB587; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB587; x-forefront-prvs: 0518EEFB48 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2015 16:48:47.3825 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB587 Archived-At: Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 17 Mar 2015 16:48:51 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: Tuesday, March 17, 2015 11:25 AM > To: v6ops@ietf.org > Subject: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets >=20 > Folks, >=20 > Since the question as been asked, hereby I'm providing a heads-up about o= ur > finding regarding transit ASes that are filtering IPv6 EH-enabled packets= . -- sme > folks my be willing to double-check with the relevant people, and possibl= y > inquire the reasoning behind the filtering decision. >=20 > Here we are just consider "best-case scenarios" (please see draft-gont-ip= v6- > ehs-in-real-world for a definition of what we mean by that): >=20 > * Folks filtering packets with Dest Options EHs >=20 > AS 2119 (TELENOR-NEXTEL Telenor Norge AS,NO) > AS 286 (KPN KPN International / KPN Eurorings,NL) > AS 3356 (LEVEL3 - Level 3 Communications, Inc.,US) >=20 >=20 > * Folks filtering packets with HBH EHs: > (0.31%): AS 174 (COGENT-174 - Cogent Communications,US) > (1.89%): AS 286 (KPN KPN International / KPN Eurorings,NL) > (1.13%): AS 1273 (CW Cable and Wireless Worldwide plc,GB) > (14.42%): AS 1299 (TELIANET TeliaSonera International Carrier,SE) > (0.31%): AS 1764 (NEXTLAYER-AS next layer > Telekommunikationsdienstleistungs- GmbH,AT) > (0.38%): AS 3257 (TINET-BACKBONE Tinet SpA,DE) > (81.50%): AS 3356 (LEVEL3 - Level 3 Communications, Inc.,US) > (0.31%): AS 5588 (GTSCE T-Mobile Czech Republic a.s.,CZ) > (0.31%): AS 6695 (DECIX-AS DE-CIX Management GmbH,DE) > (0.94%): AS 8218 (NEO-ASN Neo Telecoms S.A.S.,FR) > (0.31%): AS 8447 (TELEKOM-AT A1 Telekom Austria AG,AT) > (0.31%): AS 8767 (MNET-AS M-net Telekommunikations GmbH, > Germany,DE) > (0.31%): AS 9063 (SAARGATE-AS VSE NET GmbH,DE) > (0.19%): AS 12389 (ROSTELECOM-AS OJSC Rostelecom,RU) > (0.19%): AS 16086 (DNA DNA Oy,FI) > (0.63%): AS 20676 (QSC-1 QSC AG,DE) > (0.19%): AS 29470 (RETNNET-AS CJSC _RetnNet_,RU) > (0.19%): AS 34984 (TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR) > (0.31%): AS 36623 (HGTLD - VeriSign Global Registry Services,US) >=20 >=20 > * Folks filtering Fragments >=20 > AS 6939 (HURRICANE - Hurricane Electric, Inc.,US) AS 34779 (T-2-AS T-2= , > d.o.o.,SI) >=20 >=20 > FWIW, this post should not be considered a "wall of shame", but, if anyth= ing, a > "wall of reality". Just an observation: Nobody will ever do anything to remove themselves from a, "wall of reality"= . They might if it is a public "wall of shame". Personally I think a larger discussion needs to be had about whether it is = appropriate to be filtering traffic, (read high level packet inspection) in= the "middle" of the internet, or not. If that is an expectation, then the= design needs to accommodate that. If the expectation is that packet filtering should not be done in the "midd= le" of the internet, then this is a "wall of shame", and that is the "reali= ty" of it. It seems like we keep having the same argument over and over, sometimes. >=20 > Thanks! >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Mar 17 10:31:55 2015 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 525ED1A87C9 for ; Tue, 17 Mar 2015 10:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HRn2EbCCTzDp for ; Tue, 17 Mar 2015 10:31:52 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 9BE001A87E3 for ; Tue, 17 Mar 2015 10:31:51 -0700 (PDT) Received: (qmail 96277 invoked from network); 17 Mar 2015 17:31:49 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Mar 2015 17:31:49 -0000 Date: Tue, 17 Mar 2015 18:31:49 +0100 (CET) Message-Id: <20150317.183149.74660986.sthaug@nethelp.no> To: dan-metzler@uiowa.edu From: sthaug@nethelp.no In-Reply-To: References: <55085545.4070607@si6networks.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: fgont@si6networks.com, v6ops@ietf.org Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 17 Mar 2015 17:31:54 -0000 > If the expectation is that packet filtering should not be done in the "middle" of the internet, then this is a "wall of shame", and that is the "reality" of it. Possibly not appropriate to v6ops - but just to inject some IPv4 perspective into the current discussion, we filter several of the following types of IPv4 traffic at our borders: - Ongoing attack IP sources. - Spoofed traffic sourced from our own IP addresses. - Source routed packets. - Tiny fragments (RFC 1858). - DNS queries to our resolvers. In addition to the above, there are several other groups of traffic that we significantly rate limit at our borders. Filtering is most certainly *not* limited to IPv6 EHs. Steinar Haug, AS 2116 From nobody Tue Mar 17 12:31:05 2015 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 1BDCD1A88A5 for ; Tue, 17 Mar 2015 12:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 rDtsUU6fGior for ; Tue, 17 Mar 2015 12:31:03 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 7777D1A8899 for ; Tue, 17 Mar 2015 12:31:03 -0700 (PDT) Received: by padcy3 with SMTP id cy3so18207083pad.3 for ; Tue, 17 Mar 2015 12:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YVFJt41NSzc0WB+Kr5Eq9nOCLwCJe25XDLLBHgQMHC8=; b=eUVTCB/7sYrY4Wrze1M3E2N5oUlsSwii1noluqXccYUDPMuchyIIcHL+XRgIOmv0DF DJ1shhCnZC6QukrXenGbS0lvCwz1EyD6CILNF9gS6f208DdQQBa7vzG2biJnQrshtZoJ Mv2nDICHfxxxmrrmRdPQiRCiwqfKcnVHY90BMHWryk4M+maqVPgvPkcyIjHwCr5Cc+yN eYPSqrUKCOt2LBnzRoUSboqEXolT+mJr/hVighHF28HJCV6tU2B1O0p/eq1hDYlD/Vf6 SD4R2lQrrquHs9/+9DMCI4ah+rGppGEu0CZ8VI2pypWG7osYH7jfC2/yFEEC7Ultk5hS Jjqw== X-Received: by 10.66.136.48 with SMTP id px16mr117442860pab.89.1426620663140; Tue, 17 Mar 2015 12:31:03 -0700 (PDT) Received: from ?IPv6:2406:e007:690c:1:28cc:dc4c:9703:6781? ([2406:e007:690c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ft11sm2599043pdb.65.2015.03.17.12.30.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 12:31:01 -0700 (PDT) Message-ID: <550880F6.10908@gmail.com> Date: Wed, 18 Mar 2015 08:31:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Metzler, Dan J" , Fernando Gont , "v6ops@ietf.org" References: <55085545.4070607@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 17 Mar 2015 19:31:05 -0000 On 18/03/2015 05:48, Metzler, Dan J wrote: > > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont >> Sent: Tuesday, March 17, 2015 11:25 AM >> To: v6ops@ietf.org >> Subject: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets >> >> Folks, >> >> Since the question as been asked, hereby I'm providing a heads-up about our >> finding regarding transit ASes that are filtering IPv6 EH-enabled packets. -- sme >> folks my be willing to double-check with the relevant people, and possibly >> inquire the reasoning behind the filtering decision. >> >> Here we are just consider "best-case scenarios" (please see draft-gont-ipv6- >> ehs-in-real-world for a definition of what we mean by that): >> >> * Folks filtering packets with Dest Options EHs ... >> >> * Folks filtering packets with HBH EHs: ... >> >> * Folks filtering Fragments >> ... >> >> >> FWIW, this post should not be considered a "wall of shame", but, if anything, a >> "wall of reality". > > Just an observation: > Nobody will ever do anything to remove themselves from a, "wall of reality". They might if it is a public "wall of shame". > Personally I think a larger discussion needs to be had about whether it is appropriate to be filtering traffic, (read high level packet inspection) in the "middle" of the internet, or not. If that is an expectation, then the design needs to accommodate that. I think before that point, there's more analysis needed. I thought up various possible scenarios for the above "filters", times three because there are three classes of header: 1. I am filtering these packets because I think they are evil. 2. I am filtering these packets because my box does that by default. 3. I am filtering these packets because my box does that by design. 4. I am filtering these packets because they make my box go slow. 5. I am filtering these packets because they break my ECMP. 6. Oh, am I filtering those? 7. What's an extension header? Brian > > If the expectation is that packet filtering should not be done in the "middle" of the internet, then this is a "wall of shame", and that is the "reality" of it. > > It seems like we keep having the same argument over and over, sometimes. > >> >> Thanks! >> >> Cheers, >> -- >> 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 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Mar 17 16:14:47 2015 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 45B0A1A1BA7 for ; Tue, 17 Mar 2015 16:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Gh8aOnbJ6MSn for ; Tue, 17 Mar 2015 16:14:45 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0A41A1B95 for ; Tue, 17 Mar 2015 16:14:45 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 68D631FCAC0; Tue, 17 Mar 2015 23:14:41 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E2BEE160067; Tue, 17 Mar 2015 23:21:47 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-175-41.carlnfd1.nsw.optusnet.com.au [211.30.175.41]) by zmx1.isc.org (Postfix) with ESMTPSA id 72B0016005B; Tue, 17 Mar 2015 23:21:47 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2ED232B6F709; Wed, 18 Mar 2015 10:14:40 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <55085545.4070607@si6networks.com> <550880F6.10908@gmail.com> In-reply-to: Your message of "Wed, 18 Mar 2015 08:31:02 +1300." <550880F6.10908@gmail.com> Date: Wed, 18 Mar 2015 10:14:39 +1100 Message-Id: <20150317231440.2ED232B6F709@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 17 Mar 2015 23:14:47 -0000 Yet HE passes fragmented IPv6 to me down their tunnels so I would suspect a configuration error / bad hardware / bad defaults rather than a deliberate action to block fragmented traffic. 10:11:16.500396 IP6 2001:470:1f00:820:1cef:4d27:1e8a:d270.57814 > 2001:4f8:0:2::19.domain: 2586+ [1au] ANY? isc.org. (36) 10:11:16.943513 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:1cef:4d27:1e8a:d270: frag (0|1232) domain > 57814: 2586*- 27/0/13 RRSIG, SPF, RRSIG, RRSIG, DNSKEY, DNSKEY, RRSIG[|domain] 10:11:16.943865 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:1cef:4d27:1e8a:d270: frag (1232|1232) 10:11:16.944107 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:1cef:4d27:1e8a:d270: frag (2464|888) Mark In message <550880F6.10908@gmail.com>, Brian E Carpenter writes: > On 18/03/2015 05:48, Metzler, Dan J wrote: > > > > > >> -----Original Message----- > >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont > >> Sent: Tuesday, March 17, 2015 11:25 AM > >> To: v6ops@ietf.org > >> Subject: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets > >> > >> Folks, > >> > >> Since the question as been asked, hereby I'm providing a heads-up about ou > r > >> finding regarding transit ASes that are filtering IPv6 EH-enabled packets. > -- sme > >> folks my be willing to double-check with the relevant people, and possibly > >> inquire the reasoning behind the filtering decision. > >> > >> Here we are just consider "best-case scenarios" (please see draft-gont-ipv > 6- > >> ehs-in-real-world for a definition of what we mean by that): > >> > >> * Folks filtering packets with Dest Options EHs > ... > >> > >> * Folks filtering packets with HBH EHs: > ... > >> > >> * Folks filtering Fragments > >> > ... > >> > >> > >> FWIW, this post should not be considered a "wall of shame", but, if anythi > ng, a > >> "wall of reality". > > > > Just an observation: > > Nobody will ever do anything to remove themselves from a, "wall of reality" > . They might if it is a public "wall of shame". > > Personally I think a larger discussion needs to be had about whether it is > appropriate to be filtering traffic, (read high level packet inspection) in t > he "middle" of the internet, or not. If that is an expectation, then the des > ign needs to accommodate that. > > I think before that point, there's more analysis needed. I thought up > various possible scenarios for the above "filters", times three because > there are three classes of header: > > 1. I am filtering these packets because I think they are evil. > 2. I am filtering these packets because my box does that by default. > 3. I am filtering these packets because my box does that by design. > 4. I am filtering these packets because they make my box go slow. > 5. I am filtering these packets because they break my ECMP. > 6. Oh, am I filtering those? > 7. What's an extension header? > > Brian > > > > > If the expectation is that packet filtering should not be done in the "midd > le" of the internet, then this is a "wall of shame", and that is the "reality > " of it. > > > > It seems like we keep having the same argument over and over, sometimes. > > > >> > >> Thanks! > >> > >> Cheers, > >> -- > >> 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 > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Mar 17 16:27:44 2015 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 F41DD1A1BCF for ; Tue, 17 Mar 2015 16:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 BlkBgI53rsFz for ; Tue, 17 Mar 2015 16:27:41 -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 CCE8F1A1BA9 for ; Tue, 17 Mar 2015 16:27:40 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t2HNRban044223 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2015 23:27:38 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <5508B868.4020204@foobar.org> Date: Tue, 17 Mar 2015 23:27:36 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark Andrews , Brian E Carpenter References: <55085545.4070607@si6networks.com> <550880F6.10908@gmail.com> <20150317231440.2ED232B6F709@rock.dv.isc.org> In-Reply-To: <20150317231440.2ED232B6F709@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 17 Mar 2015 23:27:43 -0000 On 17/03/2015 23:14, Mark Andrews wrote: > Yet HE passes fragmented IPv6 to me down their tunnels so I would > suspect a configuration error / bad hardware / bad defaults rather > than a deliberate action to block fragmented traffic. given HE's high level of clue about ipv6, I would suspect that this is deliberate and that HE have what they would consider to be sound technical reasons for dropping ipv6 fragments. Nick From nobody Tue Mar 17 16:43:25 2015 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 33C651A1BCF for ; Tue, 17 Mar 2015 16:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Mdd2hIay3F-q for ; Tue, 17 Mar 2015 16:43:20 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BC61A1BDE for ; Tue, 17 Mar 2015 16:43:20 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id A94C43493EF; Tue, 17 Mar 2015 23:43:16 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B5B34160067; Tue, 17 Mar 2015 23:50:23 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-175-41.carlnfd1.nsw.optusnet.com.au [211.30.175.41]) by zmx1.isc.org (Postfix) with ESMTPSA id 7EC8C16005B; Tue, 17 Mar 2015 23:50:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E7B862B6FAB0; Wed, 18 Mar 2015 10:43:19 +1100 (EST) To: Nick Hilliard From: Mark Andrews References: <55085545.4070607@si6networks.com> <550880F6.10908@gmail.com> <20150317231440.2ED232B6F709@rock.dv.isc.org> <5508B868.4020204@foobar.org> In-reply-to: Your message of "Tue, 17 Mar 2015 23:27:36 -0000." <5508B868.4020204@foobar.org> Date: Wed, 18 Mar 2015 10:43:18 +1100 Message-Id: <20150317234319.E7B862B6FAB0@rock.dv.isc.org> Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 17 Mar 2015 23:43:24 -0000 In message <5508B868.4020204@foobar.org>, Nick Hilliard writes: > On 17/03/2015 23:14, Mark Andrews wrote: > > Yet HE passes fragmented IPv6 to me down their tunnels so I would > > suspect a configuration error / bad hardware / bad defaults rather > > than a deliberate action to block fragmented traffic. > > given HE's high level of clue about ipv6, I would suspect that this is > deliberate and that HE have what they would consider to be sound technical > reasons for dropping ipv6 fragments. > > Nick The only way to answer this is to ask HE. Since I don't have any evidence those that have the evidence should do the asking. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Mar 18 01:21:21 2015 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 905201A1ADA for ; Wed, 18 Mar 2015 01:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GqrZGlcucQJ3 for ; Wed, 18 Mar 2015 01:21:19 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id C89141A066B for ; Wed, 18 Mar 2015 01:21:18 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id D4AF513F40B1; Wed, 18 Mar 2015 02:21:17 -0600 (MDT) X-Spam-ASN: Received: from [192.168.1.135] (unknown [96.53.15.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id CB88613F400D for ; Wed, 18 Mar 2015 02:21:16 -0600 (MDT) Message-ID: <55093573.7060709@iridiumlinux.org> Date: Wed, 18 Mar 2015 02:21:07 -0600 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5503265E.1060201@foobar.org> <1645755951.1004066.1426553681927.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1645755951.1004066.1426553681927.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000504050609060607010401" Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 18 Mar 2015 08:21:20 -0000 This is a cryptographically signed message in MIME format. --------------ms000504050609060607010401 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable They will need publicly routable numbers on a management network anyway, most likely. Private-use addresses are a horrible security mechanism when you have firewalls and authentication to work with. One reason I might do it is so that I don't have to request (and pay fees for) additional allocations I don't really need. On 16/03/2015 18:54, Mark ZZZ Smith wrote: > So the reason I care about it and I think it is important to resolve is= that the only significant reason I can think of to deploy link-local onl= y links/interfaces is for security reasons. The address conservation reas= on to deploy unnumbered IPv4 links doesn't apply in IPv6. > > If people are deploying link-local only links exclusively for security = reasons, then I think it is important that the security properties of the= m are clear and obvious. Accurate naming of them, and having a different = name to similarly configured links in IPv4 (because they are different), = would help avoid the sorts of security issues that pop up when people put= in place security measures that don't behave exactly how they expect. > > Regards, > Mark. > > > > ________________________________ > From: Nick Hilliard > To: Mark ZZZ Smith ; Gert Doering =20 > Cc: "v6ops@ietf.org" =20 > Sent: Saturday, 14 March 2015, 5:03 > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? > > > On 12/03/2015 23:43, Mark ZZZ Smith wrote: >> If you don't ensure clarity and accuracy, simple misunderstandings can= >> have catastrophic consequences : > For sure, yes. I'm just suggesting that 70 emails to discuss this topi= c so > far (13 emails in the original thread and 57 emails so far in this thre= ad) > is bike-shedding. > > > > / So the reason I care about it and I think it is important to resolve = is that the only significant reason I can think of to deploy link-local o= nly links/interfaces is for security reasons. The address conservation re= ason to deploy unnumbered IPv4 links doesn't apply in IPv6. > > / If people are deploying link-local only links exclusively for securit= y reasons, then I think it is important that the security properties of t= hem are clear and obvious. Accurate naming of them, and having a differen= t name to similarly configured links in IPv4 (because they are different)= , would help avoid the sorts of security vulnerabilities that can occur w= hen people put in place security measures that don't behave exactly how t= hey expect. > > / Regards, > Mark. > > > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------ms000504050609060607010401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICNVIwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMzA2MjAxNzE3NTha Fw0xNTA2MjExODIxNDFaMHkxCzAJBgNVBAYTAkNBMRAwDgYDVQQIEwdBbGJlcnRhMRAwDgYD VQQHEwdDYWxnYXJ5MR4wHAYDVQQDExVGYWxjb24gRGFya3N0YXIgTW9tb3QxJjAkBgkqhkiG 9w0BCQEWF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAxXTJbSY0rw4+Q/er78YCHZOoIjCcYmEvk5CnO7NxHpIH/jbWQa//6wBY3eLr PX8bbG5c3ACGgrdjkP2SYQ+j4hdG7cOq+mLu0xIIEpwc4mIMBujlOOkabF1rHhf1lR8Vu05v 6wBRmOGfPjt9DensP5cKCn2hmWjWzymtu4M6tX9PylMJ2EBl+8oYigwde8W/72L1o7hbeGeR lYYSFEMVjCAeTxh6ItBGsUsu45CaxOAGpviPim4dUce6JBULaY8WAuGBYsSHyjIQVrxBfBQt 7mplOEeSicJQ0OG5b8p+IxBYviR7B+GJFtM1rJe16FfNR8QRKsZWp+DpPmFzO7/t3QIDAQAB o4IC3TCCAtkwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBSk4cfjJtHGA2MHBl57yq9p4oXB4TAfBgNVHSMEGDAWgBSu VYNv7DHKufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYWxjb25AaXJpZGl1bWxpbnV4Lm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB AIes2lmV2V9vJ2jVpWsKESGdAP2zbFYRoISNzfqrI2ZtMOYtK88vux7X/i97rAQN+U/4/+h8 /nAI2ohvhO1SZV04HKbJHBAZNbv9z+fj9UeNgGnYffcfDTHAidZnivsS/rPyUgOqzjGBl+HN giLqKSn8PIFGazc7Rg0H1ZDbjvcVdiPcO3xdhBRsiHbZ3sn/ni24L9B9oKmvpGqkvHUvgZ28 o+4xyoDQZjalTS5OHV4piRmTJfObKT86ptl0dE6VZ/ImWUPea9enEd83gnYz+dAE7Nhrn7Eo VpI8o5A4oPdR7+XsQuiouC3TSdPf3BE+3I1OPvrUapRII/oz05WQsaIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgI1UjAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMTgwODIx MDdaMCMGCSqGSIb3DQEJBDEWBBQ6H4gmUSLh4wp8n3sAMTegd8N4vjBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICNVIwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAjVS MA0GCSqGSIb3DQEBAQUABIIBALkdJsmlpBGf4AhCyPxifJNhi/LT0EvWsGHGrwBLQZYMfNVw fLIN9zyj1zqvGcJ6q6hhQE99KvhZrf+zL5mRm6MubSN4C3X4DtJ2WL98DlnYIoe+Tzf4EkBn Ic57u13SOeNJCR0ZAWqhOO9QJNBsX7EgavMSNLkQ+DStg4ebBCZy+dvl8BUa1BzcO17x1V4K +8ie4P+TIToDMluY+dG3UHLahyxAc3tJXAfUkwJ0Bx+iq8f22OYYzW7AhulS0C4ct25axESb saKCjw46Msjn2bs1Fn2thoQuTFVJUW0RZPzl15nmZGal7nVgwl1NBM6onz+W6Os4Cnhj4EhH 8rE8FyoAAAAAAAA= --------------ms000504050609060607010401-- From nobody Wed Mar 18 02:20:41 2015 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 042B21A8028 for ; Wed, 18 Mar 2015 02:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HKo5A06B6lNA for ; Wed, 18 Mar 2015 02:20:35 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F781A1A4F for ; Wed, 18 Mar 2015 02:20:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A915CA1; Wed, 18 Mar 2015 10:20:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1426670431; bh=o5nBASetBo4CCPYmsuod71k1SQTfW7TxBkxIuBby1GM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ULoM3+82+3ueSyeJsKyoDQjgeDzqyvBagJb3hEuZP0H8fCTi6SvQAx09/PTbd/pxi lOltvpzLFfWonkjaX5eA2Sd4ebsBga0ElAS7gup+v8A9wB/UkdJnxTieFgwxkywuEf T6+URJ2DOxkkp0QymdlIBmel2L7MFlZw84RU7wb8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9CEE89F; Wed, 18 Mar 2015 10:20:31 +0100 (CET) Date: Wed, 18 Mar 2015 10:20:31 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <55085545.4070607@si6networks.com> Message-ID: References: <55085545.4070607@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 18 Mar 2015 09:20:40 -0000 On Tue, 17 Mar 2015, Fernando Gont wrote: > our finding regarding transit ASes that are filtering IPv6 EH-enabled > packets. -- sme folks my be willing to double-check with the relevant Again, I want to object to using the term "filtering". "Filtering" for me implies intent. They might be dropping EH packets without intending to do so, because they are simply unaware that their chosen platform does this. Same thing with fragments. Or do you have indications that this is being done intentionally? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Mar 18 02:46:39 2015 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 CACB91A017C for ; Wed, 18 Mar 2015 02:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 M15QJxQuTcYu for ; Wed, 18 Mar 2015 02:46:36 -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 8E9EF1A0103 for ; Wed, 18 Mar 2015 02:46:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2I9kYcW010545 for ; Wed, 18 Mar 2015 10:46:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3277A205C2E for ; Wed, 18 Mar 2015 10:47:07 +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 2AC502019AA for ; Wed, 18 Mar 2015 10:47:07 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2I9kXUf029912 for ; Wed, 18 Mar 2015 10:46:34 +0100 Message-ID: <55094979.9060705@gmail.com> Date: Wed, 18 Mar 2015 10:46:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5503265E.1060201@foobar.org> <1645755951.1004066.1426553681927.JavaMail.yahoo@mail.yahoo.com> <55093573.7060709@iridiumlinux.org> In-Reply-To: <55093573.7060709@iridiumlinux.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 18 Mar 2015 09:46:39 -0000 Le 18/03/2015 09:21, Falcon Darkstar Momot a écrit : > They will need publicly routable numbers on a management network anyway, These could be ULAs instead. A network is presumably managed from within that network. Alex > most likely. Private-use addresses are a horrible security mechanism > when you have firewalls and authentication to work with. > > One reason I might do it is so that I don't have to request (and pay > fees for) additional allocations I don't really need. > > On 16/03/2015 18:54, Mark ZZZ Smith wrote: >> So the reason I care about it and I think it is important to resolve is that the only significant reason I can think of to deploy link-local only links/interfaces is for security reasons. The address conservation reason to deploy unnumbered IPv4 links doesn't apply in IPv6. >> >> If people are deploying link-local only links exclusively for security reasons, then I think it is important that the security properties of them are clear and obvious. Accurate naming of them, and having a different name to similarly configured links in IPv4 (because they are different), would help avoid the sorts of security issues that pop up when people put in place security measures that don't behave exactly how they expect. >> >> Regards, >> Mark. >> >> >> >> ________________________________ >> From: Nick Hilliard >> To: Mark ZZZ Smith ; Gert Doering >> Cc: "v6ops@ietf.org" >> Sent: Saturday, 14 March 2015, 5:03 >> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >> >> >> On 12/03/2015 23:43, Mark ZZZ Smith wrote: >>> If you don't ensure clarity and accuracy, simple misunderstandings can >>> have catastrophic consequences : >> For sure, yes. I'm just suggesting that 70 emails to discuss this topic so >> far (13 emails in the original thread and 57 emails so far in this thread) >> is bike-shedding. >> >> >> >> / So the reason I care about it and I think it is important to resolve is that the only significant reason I can think of to deploy link-local only links/interfaces is for security reasons. The address conservation reason to deploy unnumbered IPv4 links doesn't apply in IPv6. >> >> / If people are deploying link-local only links exclusively for security reasons, then I think it is important that the security properties of them are clear and obvious. Accurate naming of them, and having a different name to similarly configured links in IPv4 (because they are different), would help avoid the sorts of security vulnerabilities that can occur when people put in place security measures that don't behave exactly how they expect. >> >> / Regards, >> Mark. >> >> >> >> Nick >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 19 14:27:17 2015 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 16EFA1A88A5 for ; Thu, 19 Mar 2015 14:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 tqvsWJTCUfTr for ; Thu, 19 Mar 2015 14:27:11 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c: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 EEF851A1B92 for ; Thu, 19 Mar 2015 14:27:10 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so1714418wib.0 for ; Thu, 19 Mar 2015 14:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Zab9twaF4B2zLkcyq80GRkJqtL1nC/60xcdxUQyT1no=; b=bgH6qP9LRx1Z7fyIdsrP76mYb4WVqdL4dfJDOyDQWZRY3A+Ob0LcPSPChO4XG4k4oL ZiZiJiQygTHQgKXUOtpCENjnIrurCTGsnJz5f8rA313lpA8gW1P/k+QGcYIG8ed2diuf y5xBhn7/ogjcW9gDFbO9HXlqcmAiXVvq1gMIjGpU+cT1uDpPnvGSGFzdQ5Cjs6++T1La myqdZOYEXdGkT+dGZg6fZBYdeqnIvNgJTzexq2gYKXpmWsrj6i2ozp0wUqTsJvfYrH6P RAlrFCMLd7LU+9HGE69pCuFhP2IvS9PvsCeJjp5flhw9W0U7s+UXBKVLpeIM4oSooc5N PBuw== MIME-Version: 1.0 X-Received: by 10.194.89.195 with SMTP id bq3mr132700579wjb.123.1426800429746; Thu, 19 Mar 2015 14:27:09 -0700 (PDT) Received: by 10.194.164.2 with HTTP; Thu, 19 Mar 2015 14:27:09 -0700 (PDT) Date: Thu, 19 Mar 2015 14:27:09 -0700 Message-ID: From: Ca By To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=089e010d833cc7d1b50511aadc91 Archived-At: Subject: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 19 Mar 2015 21:27:16 -0000 --089e010d833cc7d1b50511aadc91 Content-Type: text/plain; charset=UTF-8 Hi Folks, The point of this message is to discuss the use of IPv4 literals and how this use requires transition solutions such as MAP, DS-Lite, and 464XLAT -- all of which provide local IPv4 socket support to the host. If the primary operating environment of the host is the "internet", and the "web" is a highly valuable part of the that operating environment, then local IPv4 socket support is still required. Specifically, this note builds the case that NAT64/DNS64 alone is still (at this time) not a sufficient solution for consumer Internet access by creating an IPv6-only network as described in https://tools.ietf.org/html/rfc6144#section-2.1 Empirically, it is commonly know that IPv4 addresses are used on the Internet, despite the guidance in RFC1958 ( https://tools.ietf.org/html/rfc1958#section-4). One common example is enterprise VPN services. Quantitatively, it is easy to generate information about how frequently IPv4 address literals are used on the web. Several years ago, draft-wing-behave-http-ip-address-literals-02 shared a simple method to gathering the data and reported that 2.38% of the top 1 million web pages have IPv4 literals in their homepage. I re-ran a similar test this week that yielded 1.39% of the top 1 million web pages having IPv4 literals. My test, like Dan's, only looks at the HTML on the home page and thus under-counts literals in deeper links or loaded via CSS, XML, or Javascript. Through other manual testing i have seen catastrophic failure in Amazon's video streaming service with them passing literals in XML. Facebook passes IPv4 literals in Javascript, but is not impacting the page load. I posted IPv4 literals found in the HTML homepage of these 2,220 of the top 100,000 Alexa domains here https://sites.google.com/site/tmoipv6/ipv4literals My conclusion is that it is not feasible for a network operator to deploy a purely IPv6-only socket solution. As has been previously explored, about 20% of the apps in the Google and Apple "app store" cannot function on IPv6-only + NAT64/DNS64. Even if these "app stores" were policed to force all applications to be Address Family agnostic, it is not possible to police the world wide web or enterprise VPN or SIP Phones. Any network operator that attempt to do this would have to accept at least 1.39% failure to the total web and perhaps accept failure to some major services (like Amazon streaming). I believe we are beyond the point of blaming the world for using IPv4 literals / referrals. We just need to be realistic that internet service requires IPv4 sockets, and thus RFC6144 #2.1 is not today a consumer grade service. A wild guess is that it this situation will not meaningfully improve (risk reduced to ~0) for 10+ years. Thoughts? CB --089e010d833cc7d1b50511aadc91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks,

The point of this message is = to discuss the use of IPv4 literals and how this use requires transition so= lutions such as MAP, DS-Lite, and 464XLAT -- all of which provide local IPv= 4 socket support to the host.=C2=A0 If the primary operating environment of= the host is the "internet", and the "web" is a highly = valuable part of the that operating environment, then local IPv4 socket sup= port is still required.

Specifically, this note bu= ilds the case that NAT64/DNS64 alone is still (at this time) not a sufficie= nt solution for consumer Internet access by creating an IPv6-only network a= s described in=C2=A0https://tools.ietf.org/html/rfc6144#section-2.1<= /div>

Empirically, it is commonly know that IPv4 address= es are used on the Internet, despite the guidance in RFC1958 (https://tool= s.ietf.org/html/rfc1958#section-4).=C2=A0 One common example is enterpr= ise VPN services.

Quantitatively, it is easy to ge= nerate information about how frequently IPv4 address literals are used on t= he web.

Several years ago, draft-wing-behave-= http-ip-address-literals-02 shared a simple method to gathering the data an= d reported that 2.38% of the top 1 million web pages have IPv4 literals in = their homepage.=C2=A0 I re-ran a similar test this week that yielded 1.39% = of the top 1 million web pages having IPv4 literals. =C2=A0 My test, like D= an's, only looks at the HTML on the home page and thus under-counts lit= erals in deeper links or loaded via CSS, XML, or Javascript.=C2=A0

Through other manual testing =C2=A0i have seen catastrophi= c failure in Amazon's video streaming service with them passing literal= s in XML.=C2=A0 Facebook passes IPv4 literals in Javascript, but is not imp= acting the page load.

I posted IPv4 literals found= in the HTML homepage of these 2,220 of the top 100,000 Alexa domains here= =C2=A0https://sites.google.com/site/tmoipv6/ipv4literals

My conclusion is that it is not feasible for a network ope= rator to deploy a purely IPv6-only socket solution.=C2=A0 As has been previ= ously explored, about 20% of the apps in the Google and Apple "app sto= re" cannot function on IPv6-only + NAT64/DNS64.=C2=A0 Even if these &q= uot;app stores" were policed to force all applications to be Address F= amily agnostic, it is not possible to police the world wide web or enterpri= se VPN or SIP Phones.=C2=A0 Any network operator that attempt to do this wo= uld have to accept at least 1.39% failure to the total web and perhaps acce= pt failure to some major services (like Amazon streaming).

I believe we are beyond the point of blaming the world for using I= Pv4 literals / referrals.=C2=A0 We just need to be realistic that internet = service requires IPv4 sockets, and thus RFC6144 #2.1 is not today a consume= r grade service.=C2=A0 A wild guess is that it this situation will not mean= ingfully improve (risk reduced to ~0) for 10+ years. =C2=A0

<= /div>
Thoughts?

CB

<= /div> --089e010d833cc7d1b50511aadc91-- From nobody Thu Mar 19 16:50:37 2015 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 606FF1A00EA for ; Thu, 19 Mar 2015 16:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.911 X-Spam-Level: X-Spam-Status: No, score=-113.911 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_37=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 jVFC-YKB6jZN for ; Thu, 19 Mar 2015 16:50:34 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A931A0007 for ; Thu, 19 Mar 2015 16:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6359; q=dns/txt; s=iport; t=1426809034; x=1428018634; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JpamqQPRjHd83KyFp+5+Cz5XjAZ+Fx1zYdHcAGV9RK0=; b=Gzm4wzWdPfJ/7jdgjqJTJAA+p+Tl3fNFSJEY0mIn4k7IclKu5YM3vY4R 96N961cZbR6nPymCxug/V4eInkdgs/LmPgEo2cA1y73rNBY4tKpGKNm/T 8fYiVH0TrMtjwG2HPbAnPzKmndxnlXeE2BYnWQv7LV6xFda3bko/kiUNR A=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQB3YAtV/5RdJa1cgwZSWgSDCckbAoFATAEBAQEBAX2EDwEBAQMBIyQyBQsCAQgOCiMHAgIhESUCBA4FDg2IAAMJCLIjhRaROQ2FMQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLF4JEgi0HgmgvgRYFkEyBaYExhQeBTI4ChiYiggIFFxSBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,433,1422921600"; d="asc'?scan'208";a="133682415" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 19 Mar 2015 23:50:33 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2JNoXs2006026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 23:50:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 18:50:33 -0500 From: "Fred Baker (fred)" To: Ca By Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AQHQYp98neMUqIFM3UWKOHw0TbKROg== Date: Thu, 19 Mar 2015 23:50:32 +0000 Message-ID: <4CCA85A4-6A8B-439A-B083-D5C0358C2775@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.122] Content-Type: multipart/signed; boundary="Apple-Mail=_A7681CA5-7651-44CC-B36B-330C4158AEC0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 19 Mar 2015 23:50:36 -0000 --Apple-Mail=_A7681CA5-7651-44CC-B36B-330C4158AEC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 19, 2015, at 2:27 PM, Ca By wrote: >=20 > My conclusion is that it is not feasible for a network operator to = deploy a purely IPv6-only socket solution. As has been previously = explored, about 20% of the apps in the Google and Apple "app store" = cannot function on IPv6-only + NAT64/DNS64. Even if these "app stores" = were policed to force all applications to be Address Family agnostic, it = is not possible to police the world wide web or enterprise VPN or SIP = Phones. Any network operator that attempt to do this would have to = accept at least 1.39% failure to the total web and perhaps accept = failure to some major services (like Amazon streaming). >=20 > I believe we are beyond the point of blaming the world for using IPv4 = literals / referrals. We just need to be realistic that internet = service requires IPv4 sockets, and thus RFC6144 #2.1 is not today a = consumer grade service. A wild guess is that it this situation will not = meaningfully improve (risk reduced to ~0) for 10+ years. I guess my question is what you would recommend. This comes across as = "give up on the transition; it will never happen." I=E2=80=99d like to = believe that there is in fact a way we can make it happen. How do we get = there? One approach would be that we simply let it happen, and folks who deploy = IPv4 address literals eventually see market fall-off correlated with = IPv6 growth. At some point, that becomes a forcing mechanism. It=E2=80=99s= not a tenable one now, however. draft-osamu-v6ops-ipv4-literal-in-url comments on this in detail and = makes a proposal. In addition: draft-ietf-sunset4-gapanalysis-05.txt 7. IPv4 Address Literals IPv4 addresses are often used as resource locators. For example, it is common to encounter URLs containing IPv4 address literals on web sites [I-D.wing-behave-http-ip-address-literals]. IPv4 address literals may be published on media other than web sites, and may appear in various forms other than URLs. For the operating systems which exhibit the behavior described in [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an increase in the broadcast ARP traffic, which may be undesirable. PROBLEM 14: IPv6-only hosts are unable to access resources identified by IPv4 address literals. [I-D.wing-behave-http-ip-address-literals] Wing, D., "Coping with IP Address Literals in HTTP URIs with IPv6/IPv4 Translators", draft-wing-behave-http-ip- address-literals-02 (work in progress), March 2010. draft-ietf-v6ops-mobile-device-profile-20.txt The use of address family dependent APIs (Application Programming Interfaces) or hard-coded IPv4 address literals may lead to broken applications when IPv6 connectivity is in use. As such, means to minimize broken applications when the cellular host is attached to an IPv6-only network should be encouraged. Particularly, (1) name resolution libraries (e.g., [RFC3596]) must support both IPv4 and IPv6; (2) applications must be independent of the underlying IP address family; (3) and applications relying upon Uniform Resource Identifiers (URIs) must follow [RFC3986] and its updates. Note, some IETF specifications (e.g., SIP [RFC3261]) contains broken IPv6 ABNF and rules to compare URIs with embedded IPv6 addresses; fixes (e.g., [RFC5954]) must be used instead. draft-ietf-xmpp-6122bis-19.txt jid =3D [ localpart "@" ] domainpart [ "/" resourcepart ] localpart =3D 1*1023(userbyte) ; ; a "userbyte" is a byte used to represent a ; UTF-8 encoded Unicode code point that can be ; contained in a string that conforms to the ; "UsernameCaseMapped" profile of the PRECIS ; IdentifierClass ; domainpart =3D IP-literal / IPv4address / ifqdn ; ; the "IPv4address" and "IP-literal" rules are ; defined in RFC 3986, and the first-match-wins ; (a.k.a. "greedy") algorithm described therein ; applies to the matching process ; ; note well that reuse of the IP-literal rule from ; RFC 3986 implies that IPv6 addresses are enclosed ; in square brackets (i.e., beginning with '[' and ; ending with ']') ; ifqdn =3D 1*1023(domainbyte) ; ; a "domainbyte" is a byte used to represent a ; UTF-8 encoded Unicode code point that can be ; contained in a string that conforms to RFC 5890 ; resourcepart =3D 1*1023(resourcebyte) ; ; an "opaquebyte" is a byte used to represent a ; UTF-8 encoded Unicode code point that can be ; contained in a string that conforms to the ; "OpaqueString" profile of the PRECIS ; FreeformClass ; --Apple-Mail=_A7681CA5-7651-44CC-B36B-330C4158AEC0 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 iQEVAwUBVQtgD59ieig10VPpAQJkMwgAjHqSJzyqUq/wrWrDAeV6I9RZyK5yq7zM /Mpl8U8zyXslWfdiRUbfSxFAn1iP6BNWO/hEh22R56+RsbFAcGoSw7jhkKBItzzJ ObOj33ZDvR/W7jHjhycTbrNz4iSOh9dbVWzLpA80uyXjiwvuElwsaWpdRX87sIxz /T0v4r0JtBw9Vp3w1MtDMTtPeM6rFZN6yYMPPec2lRrR1kRUYY5BAo3M/yc+tdw2 MwXj/u5BA5i1V3AvEsqgFiY5t4y2rKkTqbQg8LLV1qApxy055WIibHLxNsBGNHCp /TJRitjh46JVEGCj1+55K6BCww967+oCdqwt/8EqwDzfD5CTtP+c1Q== =RCaD -----END PGP SIGNATURE----- --Apple-Mail=_A7681CA5-7651-44CC-B36B-330C4158AEC0-- From nobody Thu Mar 19 16:50:50 2015 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 920191A00EA for ; Thu, 19 Mar 2015 16:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 v3gDfjgV1T-H for ; Thu, 19 Mar 2015 16:50:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724331A0104 for ; Thu, 19 Mar 2015 16:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1662; q=dns/txt; s=iport; t=1426809039; x=1428018639; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TONnnqEwMP+bBXj5vZJGwKz1Uq9wKboNW4U+IBlx6Ag=; b=FFIrU5AukyoYbDAEEAexHun4DWUU6JZ/FStK0Lg7ayKxOreGx4Vcenzu p5cgV5B6c7Iijdvp4pSThD5V/bXvA1YHsLkALhiE6BwBW9EAWEE1nfIRo F/K3GhVYxoPi34srRO6fWlUoqsyGOzQWzKtnnmHHc+iVoibeqNIj7VVgA c=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQA6YAtV/4sNJK1cgwaBLATMJAKBQEwBAQEBAQF9hA8BAQEDAXkFCwIBCBguMiUCBAENBQ6IGQjOLwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLF4RxB4MXgRYBBJBMgWmBMYZTlCgig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,433,1422921600"; d="asc'?scan'208";a="402004665" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2015 23:50:38 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2JNob7o023966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 23:50:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 18:50:37 -0500 From: "Fred Baker (fred)" To: Nick Hilliard , Mark Andrews Thread-Topic: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets Thread-Index: AQHQYp9/1usCOLZB2Uui1XFvdk9cEA== Date: Thu, 19 Mar 2015 23:50:36 +0000 Message-ID: <9DA03A00-604A-4673-A8FC-E4BBE670270E@cisco.com> References: <55085545.4070607@si6networks.com> <550880F6.10908@gmail.com> <20150317231440.2ED232B6F709@rock.dv.isc.org> <5508B868.4020204@foobar.org> In-Reply-To: <5508B868.4020204@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.122] Content-Type: multipart/signed; boundary="Apple-Mail=_921F87AC-A1BB-4450-A086-C453FCA67EDB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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, 19 Mar 2015 23:50:45 -0000 --Apple-Mail=_921F87AC-A1BB-4450-A086-C453FCA67EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 17, 2015, at 4:27 PM, Nick Hilliard wrote: >=20 > On 17/03/2015 23:14, Mark Andrews wrote: >> Yet HE passes fragmented IPv6 to me down their tunnels so I would >> suspect a configuration error / bad hardware / bad defaults rather >> than a deliberate action to block fragmented traffic. >=20 > given HE's high level of clue about ipv6, I would suspect that this is > deliberate and that HE have what they would consider to be sound = technical > reasons for dropping ipv6 fragments. >=20 > Nick I think something got lost in translation there. Mark is saying that he = receives fragments from HE, and Nick thinks they are dropping fragments. --Apple-Mail=_921F87AC-A1BB-4450-A086-C453FCA67EDB 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 iQEVAwUBVQtgqZ9ieig10VPpAQK/XQf/bniXet9q4chJe8qPaj+fA2JpJp0a3i2M pe/00A1SKcx8sb8+QeXVahwXyt3mHoSsANEEw8rtPDpspgRbNcPuLvNYSIuy5QKQ 7P8pc3iMNBK2uOLJSe1ZZQHpbAlE3KgpuqWERav/r4If92JMi/MA0gdhSnogBseM LcQW5bCaOReFMtC6Xt0e7nmzh6WwwDeMdZZXgP7n+Pf0chmJtf8XBxKXR5ovXTTt PWGHuMgSjtyD71T3DO0xBiDLVVBJ+0/q6pFbusf1Q0ezKvr2fhmEvL8Rv25b1obG 5c/c+lBWH/elKPlm6uljLqPViLLw3+w0ORVVqJxgWBSg6sH7bIqUxw== =+gRj -----END PGP SIGNATURE----- --Apple-Mail=_921F87AC-A1BB-4450-A086-C453FCA67EDB-- From nobody Thu Mar 19 22:42:07 2015 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 A3F491B2BF7 for ; Thu, 19 Mar 2015 22:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8npo1W53dGVc for ; Thu, 19 Mar 2015 22:42:03 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791B51B2BFD for ; Thu, 19 Mar 2015 22:42:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D313CA1; Fri, 20 Mar 2015 06:42:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1426830120; bh=3p21a4atUEUkRjnnZb3bH4kMvji2cJevGR70ddCTHoE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=J9OVcJzI4wPYv6l1FqQAZQNECTzgqk1IJwu5HDmypar1a/WdoFvrsyzyBJlln3Ufe 0lvOoitfONXTndXclom2FLGez4U5VP4iu4w54cigjQKiTvfNzKes5a4sLDJEj+1F9D 7Sx2IVvNe/PrfXnLTn/Jpg8RkYDU7kA71ae5Pzdc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CA99F9F; Fri, 20 Mar 2015 06:42:00 +0100 (CET) Date: Fri, 20 Mar 2015 06:42:00 +0100 (CET) From: Mikael Abrahamsson To: Ca By In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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: Fri, 20 Mar 2015 05:42:05 -0000 On Thu, 19 Mar 2015, Ca By wrote: > My conclusion is that it is not feasible for a network operator to deploy a > purely IPv6-only socket solution. As has been previously explored, about I agree, it isn't now. And this is the same as with most APIs, it takes a long time to deprecate old APIs. I believe it'll take at least 10-20 years before "open" operating systems will start to deprecate the old IPv4 APIs. Until then, the operating system will have to implement functions like 464XLAT to work around this situation. It's not good, but I'd say this is pretty typical transition problem. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Mar 20 03:25:49 2015 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 8C3871B2CB2 for ; Fri, 20 Mar 2015 03:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 BOqO5DDkR6My for ; Fri, 20 Mar 2015 03:25: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 9E5A01A0181 for ; Fri, 20 Mar 2015 03:25: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.1/8.14.9) with ESMTPSA id t2KAPec9045593 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2015 10:25:40 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <550BF5A4.3090707@foobar.org> Date: Fri, 20 Mar 2015 10:25:40 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <55085545.4070607@si6networks.com> <550880F6.10908@gmail.com> <20150317231440.2ED232B6F709@rock.dv.isc.org> <5508B868.4020204@foobar.org> <9DA03A00-604A-4673-A8FC-E4BBE670270E@cisco.com> In-Reply-To: <9DA03A00-604A-4673-A8FC-E4BBE670270E@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets 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: Fri, 20 Mar 2015 10:25:48 -0000 On 19/03/2015 23:50, Fred Baker (fred) wrote: > I think something got lost in translation there. Mark is saying that he > receives fragments from HE, and Nick thinks they are dropping > fragments. Fernando made the claim that HE are dropping frags in message-id 55085545.4070607@si6networks.com I should have been more careful to enclose what I said in "If HE are filtering frags, then ..." The data isn't clear. I've run a couple of frag tests from devices which transit through a local HE pop, and there doesn't seem to be a problem. Fernando, can you provide some data to support your claim? Nick From nobody Fri Mar 20 05:22:03 2015 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 DDE2F1B2CE4 for ; Fri, 20 Mar 2015 05:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 XCA-52Ar_X70 for ; Fri, 20 Mar 2015 05:22:00 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 43E141A897B for ; Fri, 20 Mar 2015 05:22:00 -0700 (PDT) Received: by wibg7 with SMTP id g7so143074369wib.1 for ; Fri, 20 Mar 2015 05:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vh+sYschJYpmwVADTrE0FYGB2vqFR9quHJcpoDnK8Bw=; b=HhSuolHZjcbfc3c2h2bM1v0e7an1Ao5Sp6qO+n/pBh1oebsT2Ig3htrMZ86oOJinMB YXPa1rQ27b/RvvDgHd3AS3MllkdaJzLHoxWQSjYtTxjC/fTdGnByREZc80xr0tOOGYq4 z++hYQfoKLrbw/rIBl+A2k4/Qr0p5EN2oyr7VE5q4iuR/loQffhOLUUcaoiMe2IM3Kue DzqO6WcQKG3AaZyhfRTIyr/m/4AP1gkQjLxSpEYtFti+cUn3XyNHXQoxNj3nzNzkqByT HraZcLaoax7uPiPpMA8Ue6RjylFpX92DaCHNwAWjhU/DAZCdDBZ340dsCtwgOMsYeqZG vDNA== X-Received: by 10.180.76.4 with SMTP id g4mr24478466wiw.43.1426854118989; Fri, 20 Mar 2015 05:21:58 -0700 (PDT) Received: from [192.168.1.12] (d75067.upc-d.chello.nl. [213.46.75.67]) by mx.google.com with ESMTPSA id y14sm6133176wjr.39.2015.03.20.05.21.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 05:21:58 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C974AEDA-4439-48AD-B318-90D12A51B1C4 Mime-Version: 1.0 (1.0) From: Ray Hunter X-Mailer: iPad Mail (12D508) In-Reply-To: Date: Fri, 20 Mar 2015 13:21:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: <5E888BC9-03AF-456E-9E12-838B1021F7AA@gmail.com> References: To: Ca By Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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: Fri, 20 Mar 2015 12:22:03 -0000 --Apple-Mail-C974AEDA-4439-48AD-B318-90D12A51B1C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 19 Mar 2015, at 22:27, Ca By wrote: >=20 > Hi Folks, >=20 > The point of this message is to discuss the use of IPv4 literals and how t= his use requires transition solutions such as MAP, DS-Lite, and 464XLAT -- a= ll of which provide local IPv4 socket support to the host. If the primary o= perating environment of the host is the "internet", and the "web" is a highl= y valuable part of the that operating environment, then local IPv4 socket su= pport is still required. >=20 > Specifically, this note builds the case that NAT64/DNS64 alone is still (a= t this time) not a sufficient solution for consumer Internet access by creat= ing an IPv6-only network as described in https://tools.ietf.org/html/rfc6144= #section-2.1 >=20 > Empirically, it is commonly know that IPv4 addresses are used on the Inter= net, despite the guidance in RFC1958 (https://tools.ietf.org/html/rfc1958#se= ction-4). One common example is enterprise VPN services. >=20 > Quantitatively, it is easy to generate information about how frequently IP= v4 address literals are used on the web. >=20 > Several years ago, draft-wing-behave-http-ip-address-literals-02 shared a s= imple method to gathering the data and reported that 2.38% of the top 1 mill= ion web pages have IPv4 literals in their homepage. I re-ran a similar test= this week that yielded 1.39% of the top 1 million web pages having IPv4 lit= erals. My test, like Dan's, only looks at the HTML on the home page and th= us under-counts literals in deeper links or loaded via CSS, XML, or Javascri= pt.=20 >=20 > Through other manual testing i have seen catastrophic failure in Amazon's= video streaming service with them passing literals in XML. Facebook passes= IPv4 literals in Javascript, but is not impacting the page load. >=20 > I posted IPv4 literals found in the HTML homepage of these 2,220 of the to= p 100,000 Alexa domains here https://sites.google.com/site/tmoipv6/ipv4liter= als >=20 > My conclusion is that it is not feasible for a network operator to deploy a= purely IPv6-only socket solution. As has been previously explored, about 2= 0% of the apps in the Google and Apple "app store" cannot function on IPv6-o= nly + NAT64/DNS64. Even if these "app stores" were policed to force all app= lications to be Address Family agnostic, it is not possible to police the wo= rld wide web or enterprise VPN or SIP Phones. Any network operator that att= empt to do this would have to accept at least 1.39% failure to the total web= and perhaps accept failure to some major services (like Amazon streaming). >=20 > I believe we are beyond the point of blaming the world for using IPv4 lite= rals / referrals. We just need to be realistic that internet service requir= es IPv4 sockets, and thus RFC6144 #2.1 is not today a consumer grade service= . A wild guess is that it this situation will not meaningfully improve (ris= k reduced to ~0) for 10+ years. =20 >=20 > Thoughts? >=20 > CB >=20 If all the smart solutions have failed, what about a dumb one? Pipe all IPv4 literal requests using IPv6 transport to a big web proxy at th= e edge of the ISP's IPv6 only cloud. If it's one percent of traffic why isn'= t that feasible? Assuming the host can detect it has no native IPv4 connecti= vity and it can perform automatic proxy discovery over IPv6. It works for mo= st enterprises and most enterprise apps....= --Apple-Mail-C974AEDA-4439-48AD-B318-90D12A51B1C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 19 Mar 2015, at 2= 2:27, Ca By <cb.list6@gmail.com= > wrote:

Hi = Folks,

The point of this message is to discuss the use of= IPv4 literals and how this use requires transition solutions such as MAP, D= S-Lite, and 464XLAT -- all of which provide local IPv4 socket support to the= host.  If the primary operating environment of the host is the "intern= et", and the "web" is a highly valuable part of the that operating environme= nt, then local IPv4 socket support is still required.

Specifically, this note builds the case that NAT64/DNS64 alone is still (= at this time) not a sufficient solution for consumer Internet access by crea= ting an IPv6-only network as described in https://tools.ietf.org/html= /rfc6144#section-2.1

Empirically, it is commonl= y know that IPv4 addresses are used on the Internet, despite the guidance in= RFC1958 (https://tools.ietf.org/html/rfc1958#section-4).  One commo= n example is enterprise VPN services.

Quantitativel= y, it is easy to generate information about how frequently IPv4 address lite= rals are used on the web.

Several years ago, d= raft-wing-behave-http-ip-address-literals-02 shared a simple method to gathe= ring the data and reported that 2.38% of the top 1 million web pages have IP= v4 literals in their homepage.  I re-ran a similar test this week that y= ielded 1.39% of the top 1 million web pages having IPv4 literals.   My t= est, like Dan's, only looks at the HTML on the home page and thus under-coun= ts literals in deeper links or loaded via CSS, XML, or Javascript. 

Through other manual testing  i have seen catastr= ophic failure in Amazon's video streaming service with them passing literals= in XML.  Facebook passes IPv4 literals in Javascript, but is not impac= ting the page load.

I posted IPv4 literals found in= the HTML homepage of these 2,220 of the top 100,000 Alexa domains here = ;https://sites.google.com/site/tmoipv6/ipv4literals

<= /div>
My conclusion is that it is not feasible for a network operator to= deploy a purely IPv6-only socket solution.  As has been previously exp= lored, about 20% of the apps in the Google and Apple "app store" cannot func= tion on IPv6-only + NAT64/DNS64.  Even if these "app stores" were polic= ed to force all applications to be Address Family agnostic, it is not possib= le to police the world wide web or enterprise VPN or SIP Phones.  Any n= etwork operator that attempt to do this would have to accept at least 1.39% f= ailure to the total web and perhaps accept failure to some major services (l= ike Amazon streaming).

I believe we are beyond the p= oint of blaming the world for using IPv4 literals / referrals.  We just= need to be realistic that internet service requires IPv4 sockets, and thus R= FC6144 #2.1 is not today a consumer grade service.  A wild guess is tha= t it this situation will not meaningfully improve (risk reduced to ~0) for 1= 0+ years.  

Thoughts?

CB

If all the smart solutions have failed, what about a dumb= one?

Pipe all IPv4 literal requests using IPv6 transport= to a big web proxy at the edge of the ISP's IPv6 only cloud. If it's one pe= rcent of traffic why isn't that feasible? Assuming the host can detect it ha= s no native IPv4 connectivity and it can perform automatic proxy discovery o= ver IPv6. It works for most enterprises and most enterprise apps....
= --Apple-Mail-C974AEDA-4439-48AD-B318-90D12A51B1C4-- From nobody Fri Mar 20 05:42:41 2015 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 0D8BE1A898D for ; Fri, 20 Mar 2015 05:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ofuMtdD0Fu9P for ; Fri, 20 Mar 2015 05:42:38 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0152B1B2CE0 for ; Fri, 20 Mar 2015 05:42:38 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=52848 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YYwG3-0004Lv-F0; Fri, 20 Mar 2015 13:42:35 +0100 Date: Fri, 20 Mar 2015 13:42:04 +0100 From: Tore Anderson To: Mikael Abrahamsson Message-ID: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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: Fri, 20 Mar 2015 12:42:40 -0000 * Mikael Abrahamsson > Until then, the operating system will have to implement functions > like 464XLAT to work around this situation. It's not good, but I'd say > this is pretty typical transition problem. Yep. Justine Vick from Microsoft held a very interesting presentation at the V6 World Congress on Wednesday about their plans to make one of their buildings IPv6-only. One of the things she had identified a need for was to have a CLAT in the desktop version of Windows. She had already established contact with the relevant teams to try to make that happen (I asked her to add the Windows Server folks to her CC list). Fingers crossed! Once we can translate IPv4 on our network borders/edges and keep the network itself IPv6-only we have way to proceed with the transition. Hopefully it will eventually dawn on the apps and web sites that use of literals or depending on AF_INET sockets isn't particularly smart if they want the optimal performance and functionality. (But if they don't it's no big deal either, they can get the best-effort service level.) Tore From nobody Fri Mar 20 05:59:48 2015 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 6E7731B2CED for ; Fri, 20 Mar 2015 05:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.036 X-Spam-Level: * X-Spam-Status: No, score=1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 31qhISWBYqKO for ; Fri, 20 Mar 2015 05:59:45 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A9B1B2CF0 for ; Fri, 20 Mar 2015 05:59:43 -0700 (PDT) Received: from 10.236.62.138 (EHLO OPE10HT04.tp.gk.corp.tepenet) ([10.236.62.138]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DSB45737; Fri, 20 Mar 2015 13:59:39 +0100 (CET) From: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= To: Ca By , IPv6 Ops WG Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AQHQYot+JPbEs9uqwESBzZsi6hPKXZ0lUeAQ Date: Fri, 20 Mar 2015 12:59:11 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745FB5114@OPE10MB05.tp.gk.corp.tepenet> References: In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.13.107.45] Content-Type: multipart/alternative; boundary="_000_2D29C51862222E49B991EF64EEB0B5B745FB5114OPE10MB05tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.3.20.115722:17:8.129, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __CP_MEDIA_BODY, ECARD_KNOWN_DOMAINS, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_50_70, WEBMAIL_SOURCE, REFERENCES X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0201.550C19BB.02DA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0201.550C19BB.02DA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2eca9daec65e3c3c3a1d95939e6b4202 Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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: Fri, 20 Mar 2015 12:59:47 -0000 --_000_2D29C51862222E49B991EF64EEB0B5B745FB5114OPE10MB05tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIHJlYXNvbiB3aHkgT1BMIGRvIG5vdCB1c2UgRE5TNjQgKGRvbWFpbiDigJxpcHY0 b25seS5hcnBh4oCdIG9ubHkpLCBhbmQgYWxsIGlwdjQgdHJhZmZpYyBnb2VzIHZpYSBDTEFULiBX ZSBhcmUgdHJhbnNpdGlvbmluZyAgdG8gSVB2Ni1vbmx5IG5vdCBvbmx5IHNtYXJ0cGhvbmVzL3Rh YmxldHMgLCBidXQgbW9iaWxlIHJvdXRlcnMgYXMgd2VsbC4NCg0KDQoNClRoZSBzdGFuZGFyZHMg c2hvdWxkIGJlIHJldmlzZWQgd2l0aCBhZGRpdGlvbmFsIHNjZW5hcmlvIC0gIENMQVQvTkFUNjQv RE5TIGZvciBJUHY2LW9ubHkuDQoNCkJSLA0KTWN6DQoNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2EgQnkNClNlbnQ6IFRodXJzZGF5 LCBNYXJjaCAxOSwgMjAxNSAxMDoyNyBQTQ0KVG86IElQdjYgT3BzIFdHDQpTdWJqZWN0OiBbdjZv cHNdIFRoZSBuZWVkIGZvciBsb2NhbC1pcHY0IHNvY2tldCB0cmFuc2l0aW9uIHNvbHV0aW9ucyAt LSBOQVQ2NC9ETlM2NCByZW1haW5zIGluc3VmZmljaWVudA0KDQpIaSBGb2xrcywNCg0KVGhlIHBv aW50IG9mIHRoaXMgbWVzc2FnZSBpcyB0byBkaXNjdXNzIHRoZSB1c2Ugb2YgSVB2NCBsaXRlcmFs cyBhbmQgaG93IHRoaXMgdXNlIHJlcXVpcmVzIHRyYW5zaXRpb24gc29sdXRpb25zIHN1Y2ggYXMg TUFQLCBEUy1MaXRlLCBhbmQgNDY0WExBVCAtLSBhbGwgb2Ygd2hpY2ggcHJvdmlkZSBsb2NhbCBJ UHY0IHNvY2tldCBzdXBwb3J0IHRvIHRoZSBob3N0LiAgSWYgdGhlIHByaW1hcnkgb3BlcmF0aW5n IGVudmlyb25tZW50IG9mIHRoZSBob3N0IGlzIHRoZSAiaW50ZXJuZXQiLCBhbmQgdGhlICJ3ZWIi IGlzIGEgaGlnaGx5IHZhbHVhYmxlIHBhcnQgb2YgdGhlIHRoYXQgb3BlcmF0aW5nIGVudmlyb25t ZW50LCB0aGVuIGxvY2FsIElQdjQgc29ja2V0IHN1cHBvcnQgaXMgc3RpbGwgcmVxdWlyZWQuDQoN ClNwZWNpZmljYWxseSwgdGhpcyBub3RlIGJ1aWxkcyB0aGUgY2FzZSB0aGF0IE5BVDY0L0ROUzY0 IGFsb25lIGlzIHN0aWxsIChhdCB0aGlzIHRpbWUpIG5vdCBhIHN1ZmZpY2llbnQgc29sdXRpb24g Zm9yIGNvbnN1bWVyIEludGVybmV0IGFjY2VzcyBieSBjcmVhdGluZyBhbiBJUHY2LW9ubHkgbmV0 d29yayBhcyBkZXNjcmliZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNDQj c2VjdGlvbi0yLjENCg0KRW1waXJpY2FsbHksIGl0IGlzIGNvbW1vbmx5IGtub3cgdGhhdCBJUHY0 IGFkZHJlc3NlcyBhcmUgdXNlZCBvbiB0aGUgSW50ZXJuZXQsIGRlc3BpdGUgdGhlIGd1aWRhbmNl IGluIFJGQzE5NTggKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMxOTU4I3NlY3Rpb24t NCkuICBPbmUgY29tbW9uIGV4YW1wbGUgaXMgZW50ZXJwcmlzZSBWUE4gc2VydmljZXMuDQoNClF1 YW50aXRhdGl2ZWx5LCBpdCBpcyBlYXN5IHRvIGdlbmVyYXRlIGluZm9ybWF0aW9uIGFib3V0IGhv dyBmcmVxdWVudGx5IElQdjQgYWRkcmVzcyBsaXRlcmFscyBhcmUgdXNlZCBvbiB0aGUgd2ViLg0K DQpTZXZlcmFsIHllYXJzIGFnbywgZHJhZnQtd2luZy1iZWhhdmUtaHR0cC1pcC1hZGRyZXNzLWxp dGVyYWxzLTAyIHNoYXJlZCBhIHNpbXBsZSBtZXRob2QgdG8gZ2F0aGVyaW5nIHRoZSBkYXRhIGFu ZCByZXBvcnRlZCB0aGF0IDIuMzglIG9mIHRoZSB0b3AgMSBtaWxsaW9uIHdlYiBwYWdlcyBoYXZl IElQdjQgbGl0ZXJhbHMgaW4gdGhlaXIgaG9tZXBhZ2UuICBJIHJlLXJhbiBhIHNpbWlsYXIgdGVz dCB0aGlzIHdlZWsgdGhhdCB5aWVsZGVkIDEuMzklIG9mIHRoZSB0b3AgMSBtaWxsaW9uIHdlYiBw YWdlcyBoYXZpbmcgSVB2NCBsaXRlcmFscy4gICBNeSB0ZXN0LCBsaWtlIERhbidzLCBvbmx5IGxv b2tzIGF0IHRoZSBIVE1MIG9uIHRoZSBob21lIHBhZ2UgYW5kIHRodXMgdW5kZXItY291bnRzIGxp dGVyYWxzIGluIGRlZXBlciBsaW5rcyBvciBsb2FkZWQgdmlhIENTUywgWE1MLCBvciBKYXZhc2Ny aXB0Lg0KDQpUaHJvdWdoIG90aGVyIG1hbnVhbCB0ZXN0aW5nICBpIGhhdmUgc2VlbiBjYXRhc3Ry b3BoaWMgZmFpbHVyZSBpbiBBbWF6b24ncyB2aWRlbyBzdHJlYW1pbmcgc2VydmljZSB3aXRoIHRo ZW0gcGFzc2luZyBsaXRlcmFscyBpbiBYTUwuICBGYWNlYm9vayBwYXNzZXMgSVB2NCBsaXRlcmFs cyBpbiBKYXZhc2NyaXB0LCBidXQgaXMgbm90IGltcGFjdGluZyB0aGUgcGFnZSBsb2FkLg0KDQpJ IHBvc3RlZCBJUHY0IGxpdGVyYWxzIGZvdW5kIGluIHRoZSBIVE1MIGhvbWVwYWdlIG9mIHRoZXNl IDIsMjIwIG9mIHRoZSB0b3AgMTAwLDAwMCBBbGV4YSBkb21haW5zIGhlcmUgaHR0cHM6Ly9zaXRl cy5nb29nbGUuY29tL3NpdGUvdG1vaXB2Ni9pcHY0bGl0ZXJhbHMNCg0KTXkgY29uY2x1c2lvbiBp cyB0aGF0IGl0IGlzIG5vdCBmZWFzaWJsZSBmb3IgYSBuZXR3b3JrIG9wZXJhdG9yIHRvIGRlcGxv eSBhIHB1cmVseSBJUHY2LW9ubHkgc29ja2V0IHNvbHV0aW9uLiAgQXMgaGFzIGJlZW4gcHJldmlv dXNseSBleHBsb3JlZCwgYWJvdXQgMjAlIG9mIHRoZSBhcHBzIGluIHRoZSBHb29nbGUgYW5kIEFw cGxlICJhcHAgc3RvcmUiIGNhbm5vdCBmdW5jdGlvbiBvbiBJUHY2LW9ubHkgKyBOQVQ2NC9ETlM2 NC4gIEV2ZW4gaWYgdGhlc2UgImFwcCBzdG9yZXMiIHdlcmUgcG9saWNlZCB0byBmb3JjZSBhbGwg YXBwbGljYXRpb25zIHRvIGJlIEFkZHJlc3MgRmFtaWx5IGFnbm9zdGljLCBpdCBpcyBub3QgcG9z c2libGUgdG8gcG9saWNlIHRoZSB3b3JsZCB3aWRlIHdlYiBvciBlbnRlcnByaXNlIFZQTiBvciBT SVAgUGhvbmVzLiAgQW55IG5ldHdvcmsgb3BlcmF0b3IgdGhhdCBhdHRlbXB0IHRvIGRvIHRoaXMg d291bGQgaGF2ZSB0byBhY2NlcHQgYXQgbGVhc3QgMS4zOSUgZmFpbHVyZSB0byB0aGUgdG90YWwg d2ViIGFuZCBwZXJoYXBzIGFjY2VwdCBmYWlsdXJlIHRvIHNvbWUgbWFqb3Igc2VydmljZXMgKGxp a2UgQW1hem9uIHN0cmVhbWluZykuDQoNCkkgYmVsaWV2ZSB3ZSBhcmUgYmV5b25kIHRoZSBwb2lu dCBvZiBibGFtaW5nIHRoZSB3b3JsZCBmb3IgdXNpbmcgSVB2NCBsaXRlcmFscyAvIHJlZmVycmFs cy4gIFdlIGp1c3QgbmVlZCB0byBiZSByZWFsaXN0aWMgdGhhdCBpbnRlcm5ldCBzZXJ2aWNlIHJl cXVpcmVzIElQdjQgc29ja2V0cywgYW5kIHRodXMgUkZDNjE0NCAjMi4xIGlzIG5vdCB0b2RheSBh IGNvbnN1bWVyIGdyYWRlIHNlcnZpY2UuICBBIHdpbGQgZ3Vlc3MgaXMgdGhhdCBpdCB0aGlzIHNp dHVhdGlvbiB3aWxsIG5vdCBtZWFuaW5nZnVsbHkgaW1wcm92ZSAocmlzayByZWR1Y2VkIHRvIH4w KSBmb3IgMTArIHllYXJzLg0KDQpUaG91Z2h0cz8NCg0KQ0INCg0K --_000_2D29C51862222E49B991EF64EEB0B5B745FB5114OPE10MB05tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZWtzdCBkeW1rYSBabmFrIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uU3R5bHdpYWRvbW9jaWUtbWFpbDE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlRla3N0ZHlta2FabmFrDQoJe21zby1z dHlsZS1uYW1lOiJUZWtzdCBkeW1rYSBabmFrIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlRla3N0IGR5bWthIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6UEw7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44 NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJQTCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoaXMgaXMgYSByZWFzb24gd2h5IE9QTCBkbyBub3QgdXNlIEROUzY0IChk b21haW4g4oCcaXB2NG9ubHkuYXJwYeKAnSBvbmx5KSwgYW5kIGFsbCBpcHY0IHRyYWZmaWMgZ29l cyB2aWEgQ0xBVC4gV2UgYXJlIHRyYW5zaXRpb25pbmcmbmJzcDsmbmJzcDt0bw0KIElQdjYtb25s eSBub3Qgb25seSBzbWFydHBob25lcy90YWJsZXRzICwgYnV0IG1vYmlsZSByb3V0ZXJzIGFzIHdl bGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgc3RhbmRhcmRzIHNob3VsZCBiZSByZXZp c2VkIHdpdGggYWRkaXRpb25hbCBzY2VuYXJpbyAtJm5ic3A7Jm5ic3A7Q0xBVC9OQVQ2NC9ETlMm bmJzcDtmb3IgSVB2Ni1vbmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C Uiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1jejxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DYSBCeTxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMTksIDIwMTUgMTA6MjcgUE08YnI+DQo8Yj5Ubzo8 L2I+IElQdjYgT3BzIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFt2Nm9wc10gVGhlIG5lZWQgZm9y IGxvY2FsLWlwdjQgc29ja2V0IHRyYW5zaXRpb24gc29sdXRpb25zIC0tIE5BVDY0L0ROUzY0IHJl bWFpbnMgaW5zdWZmaWNpZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgRm9sa3MsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgcG9pbnQgb2YgdGhpcyBtZXNzYWdlIGlzIHRvIGRpc2N1c3MgdGhlIHVzZSBvZiBJUHY0IGxp dGVyYWxzIGFuZCBob3cgdGhpcyB1c2UgcmVxdWlyZXMgdHJhbnNpdGlvbiBzb2x1dGlvbnMgc3Vj aCBhcyBNQVAsIERTLUxpdGUsIGFuZCA0NjRYTEFUIC0tIGFsbCBvZiB3aGljaCBwcm92aWRlIGxv Y2FsIElQdjQgc29ja2V0IHN1cHBvcnQgdG8gdGhlIGhvc3QuJm5ic3A7IElmIHRoZSBwcmltYXJ5 IG9wZXJhdGluZyBlbnZpcm9ubWVudA0KIG9mIHRoZSBob3N0IGlzIHRoZSAmcXVvdDtpbnRlcm5l dCZxdW90OywgYW5kIHRoZSAmcXVvdDt3ZWImcXVvdDsgaXMgYSBoaWdobHkgdmFsdWFibGUgcGFy dCBvZiB0aGUgdGhhdCBvcGVyYXRpbmcgZW52aXJvbm1lbnQsIHRoZW4gbG9jYWwgSVB2NCBzb2Nr ZXQgc3VwcG9ydCBpcyBzdGlsbCByZXF1aXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlY2lmaWNhbGx5LCB0aGlzIG5vdGUgYnVpbGRz IHRoZSBjYXNlIHRoYXQgTkFUNjQvRE5TNjQgYWxvbmUgaXMgc3RpbGwgKGF0IHRoaXMgdGltZSkg bm90IGEgc3VmZmljaWVudCBzb2x1dGlvbiBmb3IgY29uc3VtZXIgSW50ZXJuZXQgYWNjZXNzIGJ5 IGNyZWF0aW5nIGFuIElQdjYtb25seSBuZXR3b3JrIGFzIGRlc2NyaWJlZCBpbiZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTQ0I3NlY3Rpb24tMi4xIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNDQjc2VjdGlvbi0y LjE8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkVtcGlyaWNhbGx5LCBpdCBpcyBjb21tb25seSBrbm93IHRoYXQgSVB2NCBhZGRyZXNzZXMg YXJlIHVzZWQgb24gdGhlIEludGVybmV0LCBkZXNwaXRlIHRoZSBndWlkYW5jZSBpbiBSRkMxOTU4 ICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMTk1OCNzZWN0aW9uLTQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMTk1OCNzZWN0 aW9uLTQ8L2E+KS4mbmJzcDsNCiBPbmUgY29tbW9uIGV4YW1wbGUgaXMgZW50ZXJwcmlzZSBWUE4g c2VydmljZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlF1YW50aXRhdGl2ZWx5LCBpdCBpcyBlYXN5IHRvIGdlbmVyYXRlIGluZm9ybWF0aW9u IGFib3V0IGhvdyBmcmVxdWVudGx5IElQdjQgYWRkcmVzcyBsaXRlcmFscyBhcmUgdXNlZCBvbiB0 aGUgd2ViLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2V2ZXJhbCB5ZWFycyBhZ28sIGRyYWZ0LXdpbmctYmVoYXZlLWh0dHAtaXAt YWRkcmVzcy1saXRlcmFscy0wMiBzaGFyZWQgYSBzaW1wbGUgbWV0aG9kIHRvIGdhdGhlcmluZyB0 aGUgZGF0YSBhbmQgcmVwb3J0ZWQgdGhhdCAyLjM4JSBvZiB0aGUgdG9wIDEgbWlsbGlvbiB3ZWIg cGFnZXMgaGF2ZSBJUHY0IGxpdGVyYWxzIGluIHRoZWlyIGhvbWVwYWdlLiZuYnNwOyBJIHJlLXJh biBhIHNpbWlsYXIgdGVzdCB0aGlzIHdlZWsNCiB0aGF0IHlpZWxkZWQgMS4zOSUgb2YgdGhlIHRv cCAxIG1pbGxpb24gd2ViIHBhZ2VzIGhhdmluZyBJUHY0IGxpdGVyYWxzLiAmbmJzcDsgTXkgdGVz dCwgbGlrZSBEYW4ncywgb25seSBsb29rcyBhdCB0aGUgSFRNTCBvbiB0aGUgaG9tZSBwYWdlIGFu ZCB0aHVzIHVuZGVyLWNvdW50cyBsaXRlcmFscyBpbiBkZWVwZXIgbGlua3Mgb3IgbG9hZGVkIHZp YSBDU1MsIFhNTCwgb3IgSmF2YXNjcmlwdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhyb3VnaCBvdGhlciBtYW51YWwgdGVzdGlu ZyAmbmJzcDtpIGhhdmUgc2VlbiBjYXRhc3Ryb3BoaWMgZmFpbHVyZSBpbiBBbWF6b24ncyB2aWRl byBzdHJlYW1pbmcgc2VydmljZSB3aXRoIHRoZW0gcGFzc2luZyBsaXRlcmFscyBpbiBYTUwuJm5i c3A7IEZhY2Vib29rIHBhc3NlcyBJUHY0IGxpdGVyYWxzIGluIEphdmFzY3JpcHQsIGJ1dCBpcyBu b3QgaW1wYWN0aW5nIHRoZSBwYWdlIGxvYWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcG9zdGVkIElQdjQgbGl0ZXJhbHMgZm91bmQgaW4g dGhlIEhUTUwgaG9tZXBhZ2Ugb2YgdGhlc2UgMiwyMjAgb2YgdGhlIHRvcCAxMDAsMDAwIEFsZXhh IGRvbWFpbnMgaGVyZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRl L3Rtb2lwdjYvaXB2NGxpdGVyYWxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zaXRlcy5nb29n bGUuY29tL3NpdGUvdG1vaXB2Ni9pcHY0bGl0ZXJhbHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGNvbmNsdXNpb24gaXMgdGhhdCBp dCBpcyBub3QgZmVhc2libGUgZm9yIGEgbmV0d29yayBvcGVyYXRvciB0byBkZXBsb3kgYSBwdXJl bHkgSVB2Ni1vbmx5IHNvY2tldCBzb2x1dGlvbi4mbmJzcDsgQXMgaGFzIGJlZW4gcHJldmlvdXNs eSBleHBsb3JlZCwgYWJvdXQgMjAlIG9mIHRoZSBhcHBzIGluIHRoZSBHb29nbGUgYW5kIEFwcGxl ICZxdW90O2FwcCBzdG9yZSZxdW90OyBjYW5ub3QgZnVuY3Rpb24gb24gSVB2Ni1vbmx5ICYjNDM7 IE5BVDY0L0ROUzY0LiZuYnNwOw0KIEV2ZW4gaWYgdGhlc2UgJnF1b3Q7YXBwIHN0b3JlcyZxdW90 OyB3ZXJlIHBvbGljZWQgdG8gZm9yY2UgYWxsIGFwcGxpY2F0aW9ucyB0byBiZSBBZGRyZXNzIEZh bWlseSBhZ25vc3RpYywgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHBvbGljZSB0aGUgd29ybGQgd2lk ZSB3ZWIgb3IgZW50ZXJwcmlzZSBWUE4gb3IgU0lQIFBob25lcy4mbmJzcDsgQW55IG5ldHdvcmsg b3BlcmF0b3IgdGhhdCBhdHRlbXB0IHRvIGRvIHRoaXMgd291bGQgaGF2ZSB0byBhY2NlcHQgYXQg bGVhc3QgMS4zOSUNCiBmYWlsdXJlIHRvIHRoZSB0b3RhbCB3ZWIgYW5kIHBlcmhhcHMgYWNjZXB0 IGZhaWx1cmUgdG8gc29tZSBtYWpvciBzZXJ2aWNlcyAobGlrZSBBbWF6b24gc3RyZWFtaW5nKS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBi ZWxpZXZlIHdlIGFyZSBiZXlvbmQgdGhlIHBvaW50IG9mIGJsYW1pbmcgdGhlIHdvcmxkIGZvciB1 c2luZyBJUHY0IGxpdGVyYWxzIC8gcmVmZXJyYWxzLiZuYnNwOyBXZSBqdXN0IG5lZWQgdG8gYmUg cmVhbGlzdGljIHRoYXQgaW50ZXJuZXQgc2VydmljZSByZXF1aXJlcyBJUHY0IHNvY2tldHMsIGFu ZCB0aHVzIFJGQzYxNDQgIzIuMSBpcyBub3QgdG9kYXkgYSBjb25zdW1lciBncmFkZSBzZXJ2aWNl LiZuYnNwOyBBIHdpbGQNCiBndWVzcyBpcyB0aGF0IGl0IHRoaXMgc2l0dWF0aW9uIHdpbGwgbm90 IG1lYW5pbmdmdWxseSBpbXByb3ZlIChyaXNrIHJlZHVjZWQgdG8gfjApIGZvciAxMCYjNDM7IHll YXJzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhvdWdodHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNCPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2D29C51862222E49B991EF64EEB0B5B745FB5114OPE10MB05tpgkco_-- From nobody Fri Mar 20 09:01:24 2015 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 CC76B1ACD5E for ; Fri, 20 Mar 2015 09:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.485 X-Spam-Level: X-Spam-Status: No, score=0.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RCVD_IN_DNSWL_LOW=-0.7, 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 aWU0S-D2w5YA for ; Fri, 20 Mar 2015 09:01:20 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490E11ACD54 for ; Fri, 20 Mar 2015 09:01:20 -0700 (PDT) Received: from 10.236.62.155 (EHLO OPE10HT07.tp.gk.corp.tepenet) ([10.236.62.155]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DSB84377; Fri, 20 Mar 2015 17:01:15 +0100 (CET) From: Kossut Tomasz - Hurt To: Tore Anderson , Mikael Abrahamsson Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AQHQYw3SjkKiJBBaPk2i3LxXcr3q5Z0lanag Date: Fri, 20 Mar 2015 16:01:08 +0000 Message-ID: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> In-Reply-To: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.3.20.145720:17:8.129, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __INT_PROD_COMP, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __FORWARDED_MSG, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1600_1699, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, WEBMAIL_SOURCE, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS, REFERENCES X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0202.550C444B.01A1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0202.550C444B.01A1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2eca9daec65e3c3c3a1d95939e6b4202 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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: Fri, 20 Mar 2015 16:01:23 -0000 CLAT is already in Windowsphone 8.1 - Pere & All thank you very much :) Idea of fancy "IPv6 bulding, house, cavern " is interesting but... I would = suggest to enable IPv6 on key Microsoft content ie. Bing.com, live.com etc.= =20 "Internet is content"=20 Cheers, tk=20 -----Original Message----- From: Tore Anderson [mailto:tore@fud.no]=20 Sent: Friday, March 20, 2015 1:42 PM To: Mikael Abrahamsson Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions --= NAT64/DNS64 remains insufficient * Mikael Abrahamsson > Until then, the operating system will have to implement functions like=20 > 464XLAT to work around this situation. It's not good, but I'd say this=20 > is pretty typical transition problem. Yep. Justine Vick from Microsoft held a very interesting presentation at the V6 World Congress on Wednesday about their plans to make one of their build= ings IPv6-only. One of the things she had identified a need for was to have= a CLAT in the desktop version of Windows. She had already established cont= act with the relevant teams to try to make that happen (I asked her to add = the Windows Server folks to her CC list). Fingers crossed! Once we can translate IPv4 on our network borders/edges and keep the networ= k itself IPv6-only we have way to proceed with the transition. Hopefully it will eventually dawn on the apps and web sites that use of lit= erals or depending on AF_INET sockets isn't particularly smart if they want= the optimal performance and functionality. (But if they don't it's no big = deal either, they can get the best-effort service level.) Tore From nobody Sun Mar 22 12:59:48 2015 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 C73211A1A47 for ; Sun, 22 Mar 2015 12:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 WgWOBLKStHoz for ; Sun, 22 Mar 2015 12:59:44 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 601051A1A32 for ; Sun, 22 Mar 2015 12:59:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [31.133.142.77]) by centos (Coremail) with SMTP id AQAAf3DbpgTMHQ9VGsEcAA--.6474S5; Mon, 23 Mar 2015 03:53:53 +0800 (CST) Message-ID: <550F1F1F.3060703@cernet.edu.cn> Date: Mon, 23 Mar 2015 03:59:27 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kossut Tomasz - Hurt References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010407090202060208020306" X-CM-TRANSID: AQAAf3DbpgTMHQ9VGsEcAA--.6474S5 X-Coremail-Antispam: 1UD129KBjvJXoW7AFyxGF1kXr18ZF4xGrykZrb_yoW8ZF1Upw s8Kr4UKr1DJ34Y93s7ur4xJr909rZ7t3y5GrnxGwn8C398Ja4jgrW8Kw4aka4UWr1rGF1j qrWj9r15A3WUZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUDab7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Jr0_Gr 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6c804VAFz4xC04v7McIj6I8E87Iv67AK xVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rV Aqx4xJMxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAF wI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20x vE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v2 0xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267 AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU11SoJUUUUU== X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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: Sun, 22 Mar 2015 19:59:46 -0000 This is a multi-part message in MIME format. --------------010407090202060208020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kossut Tomasz - Hurt ??: > CLAT is already in Windowsphone 8.1 - Pere & All thank you very much :) > > Idea of fancy "IPv6 bulding, house, cavern " is interesting but... I would suggest to enable IPv6 on key Microsoft content ie. Bing.com, live.com etc. > "Internet is content" > Cheers, > tk > It will be great, if the new versions of all the operating systems can support both the CPE function of MAP-T (stateless NAT64 in the core) and CLAT for 464XLAT (stateful NAT64 in the core). Regards, xing > > -----Original Message----- > From: Tore Anderson [mailto:tore@fud.no] > Sent: Friday, March 20, 2015 1:42 PM > To: Mikael Abrahamsson > Cc: IPv6 Ops WG > Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient > > * Mikael Abrahamsson > > >> Until then, the operating system will have to implement functions like >> 464XLAT to work around this situation. It's not good, but I'd say this >> is pretty typical transition problem. >> > > Yep. > > Justine Vick from Microsoft held a very interesting presentation at the > V6 World Congress on Wednesday about their plans to make one of their buildings IPv6-only. One of the things she had identified a need for was to have a CLAT in the desktop version of Windows. She had already established contact with the relevant teams to try to make that happen (I asked her to add the Windows Server folks to her CC list). Fingers crossed! > > Once we can translate IPv4 on our network borders/edges and keep the network itself IPv6-only we have way to proceed with the transition. > Hopefully it will eventually dawn on the apps and web sites that use of literals or depending on AF_INET sockets isn't particularly smart if they want the optimal performance and functionality. (But if they don't it's no big deal either, they can get the best-effort service level.) > > Tore > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > --------------010407090202060208020306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kossut Tomasz - Hurt 写道: 
CLAT is already in Windowsphone 8.1 - Pere & All thank you very much :)

Idea of fancy "IPv6 bulding, house, cavern " is interesting but... I would suggest to enable IPv6 on key Microsoft content ie. Bing.com, live.com etc. 
"Internet is content" 
Cheers,
tk
It will be great, if the new versions of all the operating systems can support both the CPE function of MAP-T (stateless NAT64 in the core) and CLAT for 464XLAT (stateful NAT64 in the core).

Regards,

xing


-----Original Message-----
From: Tore Anderson [mailto:tore@fud.no] 
Sent: Friday, March 20, 2015 1:42 PM
To: Mikael Abrahamsson
Cc: IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

* Mikael Abrahamsson <swmike@swm.pp.se>

  
Until then, the operating system will have to implement functions like 
464XLAT to work around this situation. It's not good, but I'd say this 
is pretty typical transition problem.
    

Yep.

Justine Vick from Microsoft held a very interesting presentation at the
V6 World Congress on Wednesday about their plans to make one of their buildings IPv6-only. One of the things she had identified a need for was to have a CLAT in the desktop version of Windows. She had already established contact with the relevant teams to try to make that happen (I asked her to add the Windows Server folks to her CC list). Fingers crossed!

Once we can translate IPv4 on our network borders/edges and keep the network itself IPv6-only we have way to proceed with the transition.
Hopefully it will eventually dawn on the apps and web sites that use of literals or depending on AF_INET sockets isn't particularly smart if they want the optimal performance and functionality. (But if they don't it's no big deal either, they can get the best-effort service level.)

Tore


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

--------------010407090202060208020306-- From nobody Mon Mar 23 05:23:29 2015 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 BE7FC1A8894 for ; Mon, 23 Mar 2015 05:23:27 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 8KuYdDZiXeHd for ; Mon, 23 Mar 2015 05:23:26 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (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 DC9FD1A882C for ; Mon, 23 Mar 2015 05:23:25 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so33965532iec.0 for ; Mon, 23 Mar 2015 05:23:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9sNW1CCz9+v65Gw26E3ft5CZo+CfzaHxEs6TMF2alIo=; b=CUow5vo5MDEaJSENlITjvpwfPaAh6JqeqKFD3czO0guhBt6yCJ2J/bRBnFlSE/MgJK GcSJsyp9+djPKHbMetVCY+t1jxgRlhmvQqGDAtz6mUHCYRqLbV0l78jvc2vDiN7pVtl0 dYLMLboh2vP6MDo/9P5EOCOeeRCLtPJ23trVzxDFUdwl7TpcQeYo0oZtiuB1NZcUuM6m hTxQPkz1ON6mp9/a5bwmnYAuYn3tkUo2dIZEVQoJoD5WPtqhyK0DY37JGHKfU0851G6h sgtjnsOfgjXxKYYbBXwvc9hotQvGMmEv6H6iAcwmo6cpSQfVTUzSokT1wDbwB3gOqMyt 9yTQ== X-Gm-Message-State: ALoCoQkKZRSsaXke8AplFD3SHVaLMnaaqfhsaV+Uq1QnC91KpPBsKNVkB6Etrlkf01QWbDYg7gGo X-Received: by 10.42.30.139 with SMTP id v11mr14517292icc.76.1427113405324; Mon, 23 Mar 2015 05:23:25 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local (CPE001319d6e9ab-CM84948c50c950.cpe.net.cable.rogers.com. [99.230.38.79]) by mx.google.com with ESMTPSA id e1sm6342956igl.19.2015.03.23.05.23.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 05:23:24 -0700 (PDT) Message-ID: <551005BD.40501@jvknet.com> Date: Mon, 23 Mar 2015 08:23:25 -0400 From: Victor Kuarsingh User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 23 Mar 2015 12:23:27 -0000 Eric/All, What about the term "administratively unnumbered?" This could be defined as an interface where the network administrator did not specifically number the interface, but does not preclude it from having an address at all (i.e. LL address). regards, Victor K On 2015-03-10 5:15 PM, Eric Vyncke (evyncke) wrote: > Philip > > In the legacy world of IPv4, unnumbered actually means using a global IPv4 > address 'stolen' from another interface. > > In the current world of IPv6, every interface has at least a link-local > address which can be used for IGP and other purposes (see RFC 7404) which > is NOT equivalent (IMHO) to 'unnumbered interface' > > So, I am afraid that you should use another working (albeit cumbersome) > > -éric > > On 10/03/15 15:52, "Philip Matthews" wrote: > >> Just want to get some direct feedback from the WG on the use of the terms >> "unnumbered interface" and "unnumbered link" in IPv6. >> >> Mark Smith, in some comments on the Design Choices draft , has said that >> he prefers the terms "interface with only link-local address" or "link >> with only link-local addresses" instead. See the thread with title "I-D >> Action: draft-ietf-v6ops-design-choices-04.txt". >> >> What does the WG think? Should we use the "unnumbered" terms, or should >> we use just the "... with only link-local address" terms? Is it >> acceptable to mix the two sets of terms? >> >> Philip >> >> >> _______________________________________________ >> 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 23 05:33:39 2015 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 3C6901A88ED for ; Mon, 23 Mar 2015 05:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 pLDi4sbUFoYm for ; Mon, 23 Mar 2015 05:33:37 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.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 01A6B1A88EB for ; Mon, 23 Mar 2015 05:33:37 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id DBB8BDA00B4; Mon, 23 Mar 2015 12:33:36 +0000 (UTC) Received: from [IPv6:2001:67c:1231:998:3c81:40d8:4402:7e06] (31.130.238.225) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 23 Mar 2015 05:33:36 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <551005BD.40501@jvknet.com> Date: Mon, 23 Mar 2015 07:33:33 -0500 Content-Transfer-Encoding: 7bit Message-ID: References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <551005BD.40501@jvknet.com> To: Victor Kuarsingh X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.225] Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 23 Mar 2015 12:33:38 -0000 On Mar 23, 2015, at 7:23 AM, Victor Kuarsingh wrote: > What about the term "administratively unnumbered?" That's a nice compromise, and also has the virtue of sounding good. From nobody Mon Mar 23 09:12:30 2015 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 0B9831A911E for ; Mon, 23 Mar 2015 09:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 v0CAgcFLX5yf for ; Mon, 23 Mar 2015 09:12:27 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (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 D73EB1A8A03 for ; Mon, 23 Mar 2015 09:12:26 -0700 (PDT) Received: by wegp1 with SMTP id p1so141859680weg.1 for ; Mon, 23 Mar 2015 09:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NutygfsoBxja9qPgnpZKymdSpCS7N+dMAR4/Lh6ZyVI=; b=eVckGcakD8d+SCcmR7n2YvtVE3ljSbXlqQM6cRqHM6TAShK5JvK/9rXv0wAMGbl47f eXUMihNMS+x/VuUF7xSSmammk1KYb6kSFk0KSUhkH7JNk7mnjzl9tvMtT7JoELQYY8s6 hamBVp9Voc4lqNQC89dRK4QyykfF0FwpvqkcyuUK+FkKn6eJN5nW8K4IsM6PRJM00Ej9 b7pCpbXaJXepeAJlP08ADeUYpJqHuhNc4DQY4tGxP4D/2kzryk0HkWYi8hAT4QTndoUZ cfNDNuAcckopehXmL7g+4LTZdROrhKxCVXtMa7KZhxtMy3o2XT/3YBPtyf2QMH0TpsrB KYfg== MIME-Version: 1.0 X-Received: by 10.180.82.169 with SMTP id j9mr10573419wiy.40.1427127145618; Mon, 23 Mar 2015 09:12:25 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Mon, 23 Mar 2015 09:12:25 -0700 (PDT) In-Reply-To: <550F1F1F.3060703@cernet.edu.cn> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Mon, 23 Mar 2015 09:12:25 -0700 Message-ID: From: Ca By To: Xing Li Content-Type: multipart/alternative; boundary=f46d0443041e90632b0511f6ee4b Archived-At: Cc: IPv6 Ops WG , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 23 Mar 2015 16:12:29 -0000 --f46d0443041e90632b0511f6ee4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 22, 2015 at 12:59 PM, Xing Li wrote: > Kossut Tomasz - Hurt =E5=86=99=E9=81=93: > > CLAT is already in Windowsphone 8.1 - Pere & All thank you very much :) > > Idea of fancy "IPv6 bulding, house, cavern " is interesting but... I woul= d suggest to enable IPv6 on key Microsoft content ie. Bing.com, live.com et= c. > "Internet is content" > Cheers, > tk > > > It will be great, if the new versions of all the operating systems can > support both the CPE function of MAP-T (stateless NAT64 in the core) and > CLAT for 464XLAT (stateful NAT64 in the core). > > Regards, > > xing > > Xing, I agree. In mobile, Windows Phone and Android both support CLAT. But there is one major mobile OS missing this feature. Perhaps the IETF should give guidance via BCP that an IPv6-only solution that supports IPv4 sockets be supported on hosts CB > -----Original Message----- > From: Tore Anderson [mailto:tore@fud.no ] > Sent: Friday, March 20, 2015 1:42 PM > To: Mikael Abrahamsson > Cc: IPv6 Ops WG > Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions = -- NAT64/DNS64 remains insufficient > > * Mikael Abrahamsson > > Until then, the operating system will have to implement functions like > 464XLAT to work around this situation. It's not good, but I'd say this > is pretty typical transition problem. > > > Yep. > > Justine Vick from Microsoft held a very interesting presentation at the > V6 World Congress on Wednesday about their plans to make one of their bui= ldings IPv6-only. One of the things she had identified a need for was to ha= ve a CLAT in the desktop version of Windows. She had already established co= ntact with the relevant teams to try to make that happen (I asked her to ad= d the Windows Server folks to her CC list). Fingers crossed! > > Once we can translate IPv4 on our network borders/edges and keep the netw= ork itself IPv6-only we have way to proceed with the transition. > Hopefully it will eventually dawn on the apps and web sites that use of l= iterals or depending on AF_INET sockets isn't particularly smart if they wa= nt the optimal performance and functionality. (But if they don't it's no bi= g deal either, they can get the best-effort service level.) > > Tore > > > _______________________________________________ > v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6o= ps > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --f46d0443041e90632b0511f6ee4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 22, 2015 at 12:59 PM, Xing Li <xing@cernet.edu.cn>= wrote:
=20
Kossut Tomasz - Hurt =E5=86=99=E9=81=93: 
CLAT is already in Windowsphone 8.1 - Pere & All thank you very =
much :)

Idea of fancy "IPv6 bulding, house, cavern " is interesting but..=
. I would suggest to enable IPv6 on key Microsoft content ie. Bing.com, live.com etc.=20
"Internet is content"=20
Cheers,
tk=20
It will be great, if the new versions of all the operating systems can support both the CPE function of MAP-T (stateless NAT64 in the core) and CLAT for 464XLAT (stateful NAT64 in the core).

Regards,

xing



Xing,

I agree.=C2=A0 In mobile, Windows Phone and Android bo= th support CLAT.

But there is one major mobile OS = missing this feature.

Perhaps the IETF should give= guidance via BCP that an IPv6-only solution that supports IPv4 sockets be = supported on hosts=C2=A0

CB
-----Original Message-----
From: Tore Anderson [mailt=
o:tore@fud.no]=20
Sent: Friday, March 20, 2015 1:42 PM
To: Mikael Abrahamsson
Cc: IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions --=
 NAT64/DNS64 remains insufficient

* Mikael Abrahamsson =
<swmike@swm.pp.se>

  
Until then, the operating system will have to implement functions =
like=20
464XLAT to work around this situation. It's not good, but I'd say t=
his=20
is pretty typical transition problem.
    
Yep.

Justine Vick from Microsoft held a very interesting presentation at the
V6 World Congress on Wednesday about their plans to make one of their build=
ings IPv6-only. One of the things she had identified a need for was to have=
 a CLAT in the desktop version of Windows. She had already established cont=
act with the relevant teams to try to make that happen (I asked her to add =
the Windows Server folks to her CC list). Fingers crossed!

Once we can translate IPv4 on our network borders/edges and keep the networ=
k itself IPv6-only we have way to proceed with the transition.
Hopefully it will eventually dawn on the apps and web sites that use of lit=
erals or depending on AF_INET sockets isn't particularly smart if they =
want the optimal performance and functionality. (But if they don't it&#=
39;s no big deal either, they can get the best-effort service level.)

Tore


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


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


--f46d0443041e90632b0511f6ee4b-- From nobody Mon Mar 23 10:55:20 2015 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 61AEA1AD063 for ; Mon, 23 Mar 2015 10:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 XrMtSoFS95DY for ; Mon, 23 Mar 2015 10:55:09 -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 C2C6F1AD05F for ; Mon, 23 Mar 2015 10:55:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2NHt5SX021275 for ; Mon, 23 Mar 2015 18:55:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 21BC9202CFC for ; Mon, 23 Mar 2015 18:55:46 +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 1946D202C86 for ; Mon, 23 Mar 2015 18:55:46 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.81]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2NHt3dK027800 for ; Mon, 23 Mar 2015 18:55:04 +0100 Message-ID: <55105376.7090307@gmail.com> Date: Mon, 23 Mar 2015 18:55:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 23 Mar 2015 17:55:11 -0000 Le 23/03/2015 17:12, Ca By a écrit : [...] > Perhaps the IETF should give guidance via BCP that an IPv6-only > solution that supports IPv4 sockets be supported on hosts Updating RFC3542 "Advanced Socket API for IPv6"? Alex > > CB > >> -----Original Message----- From: Tore Anderson >> [mailto:tore@fud.no] Sent: Friday, March 20, 2015 1:42 PM To: >> Mikael Abrahamsson Cc: IPv6 Ops WG Subject: Re: [v6ops] The need >> for local-ipv4 socket transition solutions -- NAT64/DNS64 remains >> insufficient >> >> * Mikael Abrahamsson >> >> >>> Until then, the operating system will have to implement functions >>> like 464XLAT to work around this situation. It's not good, but >>> I'd say this is pretty typical transition problem. >>> >> Yep. >> >> Justine Vick from Microsoft held a very interesting presentation at >> the V6 World Congress on Wednesday about their plans to make one of >> their buildings IPv6-only. One of the things she had identified a >> need for was to have a CLAT in the desktop version of Windows. She >> had already established contact with the relevant teams to try to >> make that happen (I asked her to add the Windows Server folks to >> her CC list). Fingers crossed! >> >> Once we can translate IPv4 on our network borders/edges and keep >> the network itself IPv6-only we have way to proceed with the >> transition. Hopefully it will eventually dawn on the apps and web >> sites that use of literals or depending on AF_INET sockets isn't >> particularly smart if they want the optimal performance and >> functionality. (But if they don't it's no big deal either, they can >> get the best-effort service level.) >> >> Tore >> >> >> _______________________________________________ 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 Mon Mar 23 16:08:22 2015 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 967FD1A0187 for ; Mon, 23 Mar 2015 16:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[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_REPLYTO=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 iv2ILbt3cnux for ; Mon, 23 Mar 2015 16:08:19 -0700 (PDT) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C871A0218 for ; Mon, 23 Mar 2015 16:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1427152086; bh=8PoSBC9oGVI84pVwKr8zaPXjH31d2iFh7jY3hOMiBgQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=tilUxt3e4/AFzGKLED/A60QQsC2oYiGjHa+cbjU4Cprmh8H5ZApsKQHvFx9LAHbM9sWq6pPmRBUrHaruV92i4jcv22kMcaO/+5DN3sjJfCIi7Lz1u2bkw6Pk37ytDxzkXatAqCTiRODsbOuqjNCpbydkujpFJcbTY6LRrguEqIb/rRvH8V7ACvX41+6GTjXgRA+C8lHRmEF9INUQ5rJzpJ1BWSDbbMq7x/n25foShJH9beF0WO7p2EEDe2O6flHLYB66uUqn3Y1FFfLaM75H5DspbTJdUqVLKjIQG+6CauF3p8NdtcTF7oN1ASSlZdrHrwlue+V67VypWEoGNIeB4A== Received: from [66.196.81.171] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 23 Mar 2015 23:08:06 -0000 Received: from [98.139.212.192] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 23 Mar 2015 23:08:06 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 23 Mar 2015 23:08:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 156237.41485.bm@omp1001.mail.bf1.yahoo.com X-YMail-OSG: HUpQYrQVM1mIeBYveou3iKj8TO2bFA.NCGWPBETa5cbcBC7Q0sdNWodYUF.2D7E EnmyKtUAR6ojj2SLQOVC.XANlKLhMQBqcMWfkHbJ5i1gAKhsGK_09_0aWRtSsWQuB6.afP5Pi4XQ ugqJ8IbTNACDNGROrF5owwF9rRgmWARuXrwiX8kDXOT28EYJaTLD_RQxUtQLTW__0ogIxKQezNBt adijPb6C7eR1WpcRgh2OT2jBdbPKhaVP13fZz2SNdsB3wAsHmjUKP6WrMRnfagfnhLgq6qPeNHJb tlCRD_BUEQuVNZVII9rRBJo68y4bCbY.ye5KbAQ3nYokfQVpsbDYBvBDsa0Mv01oPOEeYd1CdYbL z9mrZs7zZzqLS_WJMSVm.8JmyuQHIeHt1ox1bRSXjpHLD28tlfAik8HT_BFCzZ5U_EsF66oz1uHR eKU1IVuZTntBfhEDWrOaYA72eTgNLFnw629gqv3.u9I4WDREUPOvb3ow.E2oCEhR6RxU64CpPFUG QvqTTakHlQ9m.2w5DFA-- Received: by 76.13.26.136; Mon, 23 Mar 2015 23:08:05 +0000 Date: Mon, 23 Mar 2015 23:07:07 +0000 (UTC) From: Mark ZZZ Smith To: Victor Kuarsingh , "v6ops@ietf.org" Message-ID: <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <551005BD.40501@jvknet.com> References: <551005BD.40501@jvknet.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_25820_1379475242.1427152027422" Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 23:08:20 -0000 ------=_Part_25820_1379475242.1427152027422 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I still think 'link-local only' is better, as it is very explicitly saying = what the addressing scheme is. There is no and cannot be any ambiguity.=C2= =A0 I think 'administratively unnumbered' is close to the inverse of that and l= ess descriptive and specific. From: Victor Kuarsingh To: v6ops@ietf.org=20 Sent: Monday, 23 March 2015, 23:23 Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? =20 Eric/All, What about the term "administratively unnumbered?"=C2=A0 This could be=20 defined as an interface where the network administrator did not=20 specifically number the interface, but does not preclude it from having=20 an address at all (i.e. LL address). regards, Victor K On 2015-03-10 5:15 PM, Eric Vyncke (evyncke) wrote: > Philip > > In the legacy world of IPv4, unnumbered actually means using a global IPv= 4 > address 'stolen' from another interface. > > In the current world of IPv6, every interface has at least a link-local > address which can be used for IGP and other purposes (see RFC 7404) which > is NOT equivalent (IMHO) to 'unnumbered interface' > > So, I am afraid that you should use another working (albeit cumbersome) > > -=C3=A9ric > > On 10/03/15 15:52, "Philip Matthews" wrote: > >> Just want to get some direct feedback from the WG on the use of the term= s >> "unnumbered interface" and "unnumbered link" in IPv6. >> >> Mark Smith, in some comments on the Design Choices draft , has said that >> he prefers the terms "interface with only link-local address" or "link >> with only link-local addresses" instead.=C2=A0 See the thread with title= "I-D >> Action: draft-ietf-v6ops-design-choices-04.txt". >> >> What does the WG think?=C2=A0 Should we use the "unnumbered" terms, or s= hould >> we use just the "... with only link-local address" terms?=C2=A0 Is it >> acceptable to mix the two sets of terms? >> >> Philip >> >> >> _______________________________________________ >> 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 ------=_Part_25820_1379475242.1427152027422 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I still think 'link-local only' is better, as it i= s very explicitly saying what the addressing scheme is. There is no and can= not be any ambiguity. 

I think 'administratively unnumbered' is close to the inverse of t= hat and less descriptive and specific.





From= : Victor Kuarsingh <victor@jvknet.com>
To: v6ops@ietf.org
Sent: Monday, 23 March 2015, 23:23
<= b>Subject: Re: [v6ops] Should= we use "unnumbered" in IPv6?

Eric/All,

What about the term "administratively unnumbered?"&nbs= p; This could be
defined as an interface where the netwo= rk administrator did not
specifically number the interfa= ce, but does not preclude it from having
an address at a= ll (i.e. LL address).

regards,

Victor K



On 2015-03-10 5:15 PM, Eric Vyncke (= evyncke) wrote:
> Philip
>
> In the legacy world of IPv4, unnumbered actually means usi= ng a global IPv4
> address 'stolen' from another inter= face.
>
> In the current world of= IPv6, every interface has at least a link-local
> add= ress which can be used for IGP and other purposes (see RFC 7404) which
> is NOT equivalent (IMHO) to 'unnumbered interface'
>
> So, I am afraid that you should us= e another working (albeit cumbersome)
>
> -=C3=A9ric
>
> On 10/03/= 15 15:52, "Philip Matthews" <philip_matthews= @magma.ca> wrote:
>
>> = Just want to get some direct feedback from the WG on the use of the terms>> "unnumbered interface" and "unnumbered link" in I= Pv6.
>>
>> Mark Smith, in s= ome comments on the Design Choices draft , has said that
= >> he prefers the terms "interface with only link-local address" or "= link
>> with only link-local addresses" instead.&nb= sp; See the thread with title "I-D
>> Action: draf= t-ietf-v6ops-design-choices-04.txt".
>>
>> What does the WG think?  Should we use the "unnumbered= " terms, or should
>> we use just the "... with onl= y link-local address" terms?  Is it
>> accepta= ble to mix the two sets of terms?
>>
>> Philip
>>
>>>> _______________________________________________>> v6ops mailing list
>> v6ops@ietf.org
>> https://= www.ietf.org/mailman/listinfo/v6ops



------=_Part_25820_1379475242.1427152027422-- From nobody Mon Mar 23 16:56:54 2015 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 91E9B1A6F34 for ; Mon, 23 Mar 2015 16:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 9x3v7MD9CmFn for ; Mon, 23 Mar 2015 16:56:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5171A7011 for ; Mon, 23 Mar 2015 16:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20002; q=dns/txt; s=iport; t=1427155007; x=1428364607; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LMcdg7dbaYv4bk6Qm7KF2ExA1jGBv8dElISCPpeoD1Q=; b=UgMyzd+9xJJ1TiSYsdr0LIHKagrvTVitB5lsAwi/VDmc7pHaB+yg/xXf +uvD8qp3I8rvD5EQ3qFzZ5OS6BF97s0JwUuUSiTakXFK+rhiTTpxD7vot 9u23xnNetz+HmbrQnGKmpcoGCHTL91KwvltzV7HCeJ5epGNqBuvjKW/Id o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASBQBwpxBV/5pdJa1cgkNDUloEgwzDOQEJhXUCHIETTAEBAQEBAX2EFAEBAQQBAQEgCkEQCwIBCBEEAQEBCh0DAgICJQsUCQgCBAESCIgnDa5LmhABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIshhEQWFwoBgmgvgRYFkE+eGCKBfQUcgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,455,1422921600"; d="scan'208,217";a="406152971" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 23 Mar 2015 23:56:46 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2NNukqn031886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Mar 2015 23:56:46 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 18:56:46 -0500 From: "Hemant Singh (shemant)" To: Mark ZZZ Smith , Victor Kuarsingh , "v6ops@ietf.org" Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQW0JYf2S2+ZRJj0CYzJMkYUm+4p0Wi/qAgBPZpICAALPZgP//uEVQ Date: Mon, 23 Mar 2015 23:56:46 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B891682EBEA@xmb-rcd-x06.cisco.com> References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.143] Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B891682EBEAxmbrcdx06ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 23 Mar 2015 23:56:50 -0000 --_000_75B6FA9F576969419E42BECB86CB1B891682EBEAxmbrcdx06ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIGJ1dCDigJx1bm51bWJlcmVk4oCdIGhhcyBhbHJlYWR5IGJlZW4gTmFja2VkIGJ5IEVy aWNWIGFuZCBvdGhlcnMgaW4gdGhpcyBtYWlsZXIgYmVjYXVzZSB0aGUgaW50ZXJmYWNlIGJvcnJv d3MgdGhlIGxvb3BiYWNrIGludGVyZmFjZeKAmXMgaXB2NiBnbG9iYWwgYWRkcmVzcyB0byBzb3Vy Y2Ugc29tZSBpcHY2IHBhY2tldHMuDQrigJxMaW5rLWxvY2FsIG9ubHnigJ0gZG9lc27igJl0IGxv b2sgZ29vZCB0byBtZSBiZWNhdXNlIHdoYXQgaWYgdGhlIGludGVyZmFjZSBhY3R1YWxseSB0cmll ZCBESENQdjYgb3IgU0xBQUMgZm9yIGEgR1VBIGJ1dCBESENQdjYgYW5kIFNMQUFDIGZhaWxlZD8g ICBUaHVzIOKAnGFkbWluaXN0cmF0aXZlbHnigJ0gc2VlbXMgdG8gYmUga2V5IHNvIHRoYXQgb25l IGlzIGNsZWFyIHRoZSBhZG1pbiBtYW5hZ2luZyB0aGUgaW50ZXJmYWNlIG9uIHRoZSBub2RlIGNv bnNjaW91c2x5IHdhbnRlZCBvbmx5IGEgbGluay1sb2NhbCBhZGRyZXNzIG9uIHRoZSBpbnRlcmZh Y2UuICBXaHkgbm90DQoNCuKAnGFkbWluaXN0cmF0aXZlbHkgbGluay1sb2NhbCBvbmx54oCdLg0K DQpIZW1hbnQNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTWFyayBaWlogU21pdGgNClNlbnQ6IE1vbmRheSwgTWFyY2ggMjMsIDIwMTUg NzowNyBQTQ0KVG86IFZpY3RvciBLdWFyc2luZ2g7IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBTaG91bGQgd2UgdXNlICJ1bm51bWJlcmVkIiBpbiBJUHY2Pw0KDQpJIHN0aWxs IHRoaW5rICdsaW5rLWxvY2FsIG9ubHknIGlzIGJldHRlciwgYXMgaXQgaXMgdmVyeSBleHBsaWNp dGx5IHNheWluZyB3aGF0IHRoZSBhZGRyZXNzaW5nIHNjaGVtZSBpcy4gVGhlcmUgaXMgbm8gYW5k IGNhbm5vdCBiZSBhbnkgYW1iaWd1aXR5Lg0KDQpJIHRoaW5rICdhZG1pbmlzdHJhdGl2ZWx5IHVu bnVtYmVyZWQnIGlzIGNsb3NlIHRvIHRoZSBpbnZlcnNlIG9mIHRoYXQgYW5kIGxlc3MgZGVzY3Jp cHRpdmUgYW5kIHNwZWNpZmljLg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBWaWN0b3IgS3VhcnNpbmdoIDx2aWN0b3JAanZrbmV0LmNvbTxtYWlsdG86 dmljdG9yQGp2a25ldC5jb20+Pg0KVG86IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm Lm9yZz4NClNlbnQ6IE1vbmRheSwgMjMgTWFyY2ggMjAxNSwgMjM6MjMNClN1YmplY3Q6IFJlOiBb djZvcHNdIFNob3VsZCB3ZSB1c2UgInVubnVtYmVyZWQiIGluIElQdjY/DQoNCkVyaWMvQWxsLA0K DQpXaGF0IGFib3V0IHRoZSB0ZXJtICJhZG1pbmlzdHJhdGl2ZWx5IHVubnVtYmVyZWQ/IiAgVGhp cyBjb3VsZCBiZQ0KZGVmaW5lZCBhcyBhbiBpbnRlcmZhY2Ugd2hlcmUgdGhlIG5ldHdvcmsgYWRt aW5pc3RyYXRvciBkaWQgbm90DQpzcGVjaWZpY2FsbHkgbnVtYmVyIHRoZSBpbnRlcmZhY2UsIGJ1 dCBkb2VzIG5vdCBwcmVjbHVkZSBpdCBmcm9tIGhhdmluZw0KYW4gYWRkcmVzcyBhdCBhbGwgKGku ZS4gTEwgYWRkcmVzcykuDQoNCnJlZ2FyZHMsDQoNClZpY3RvciBLDQoNCg0KDQpPbiAyMDE1LTAz LTEwIDU6MTUgUE0sIEVyaWMgVnluY2tlIChldnluY2tlKSB3cm90ZToNCj4gUGhpbGlwDQo+DQo+ IEluIHRoZSBsZWdhY3kgd29ybGQgb2YgSVB2NCwgdW5udW1iZXJlZCBhY3R1YWxseSBtZWFucyB1 c2luZyBhIGdsb2JhbCBJUHY0DQo+IGFkZHJlc3MgJ3N0b2xlbicgZnJvbSBhbm90aGVyIGludGVy ZmFjZS4NCj4NCj4gSW4gdGhlIGN1cnJlbnQgd29ybGQgb2YgSVB2NiwgZXZlcnkgaW50ZXJmYWNl IGhhcyBhdCBsZWFzdCBhIGxpbmstbG9jYWwNCj4gYWRkcmVzcyB3aGljaCBjYW4gYmUgdXNlZCBm b3IgSUdQIGFuZCBvdGhlciBwdXJwb3NlcyAoc2VlIFJGQyA3NDA0KSB3aGljaA0KPiBpcyBOT1Qg ZXF1aXZhbGVudCAoSU1ITykgdG8gJ3VubnVtYmVyZWQgaW50ZXJmYWNlJw0KPg0KPiBTbywgSSBh bSBhZnJhaWQgdGhhdCB5b3Ugc2hvdWxkIHVzZSBhbm90aGVyIHdvcmtpbmcgKGFsYmVpdCBjdW1i ZXJzb21lKQ0KPg0KPiAtw6lyaWMNCj4NCj4gT24gMTAvMDMvMTUgMTU6NTIsICJQaGlsaXAgTWF0 dGhld3MiIDxwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2E8bWFpbHRvOnBoaWxpcF9tYXR0aGV3c0Bt YWdtYS5jYT4+IHdyb3RlOg0KPg0KPj4gSnVzdCB3YW50IHRvIGdldCBzb21lIGRpcmVjdCBmZWVk YmFjayBmcm9tIHRoZSBXRyBvbiB0aGUgdXNlIG9mIHRoZSB0ZXJtcw0KPj4gInVubnVtYmVyZWQg aW50ZXJmYWNlIiBhbmQgInVubnVtYmVyZWQgbGluayIgaW4gSVB2Ni4NCj4+DQo+PiBNYXJrIFNt aXRoLCBpbiBzb21lIGNvbW1lbnRzIG9uIHRoZSBEZXNpZ24gQ2hvaWNlcyBkcmFmdCAsIGhhcyBz YWlkIHRoYXQNCj4+IGhlIHByZWZlcnMgdGhlIHRlcm1zICJpbnRlcmZhY2Ugd2l0aCBvbmx5IGxp bmstbG9jYWwgYWRkcmVzcyIgb3IgImxpbmsNCj4+IHdpdGggb25seSBsaW5rLWxvY2FsIGFkZHJl c3NlcyIgaW5zdGVhZC4gIFNlZSB0aGUgdGhyZWFkIHdpdGggdGl0bGUgIkktRA0KPj4gQWN0aW9u OiBkcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzLTA0LnR4dCIuDQo+Pg0KPj4gV2hhdCBk b2VzIHRoZSBXRyB0aGluaz8gIFNob3VsZCB3ZSB1c2UgdGhlICJ1bm51bWJlcmVkIiB0ZXJtcywg b3Igc2hvdWxkDQo+PiB3ZSB1c2UganVzdCB0aGUgIi4uLiB3aXRoIG9ubHkgbGluay1sb2NhbCBh ZGRyZXNzIiB0ZXJtcz8gIElzIGl0DQo+PiBhY2NlcHRhYmxlIHRvIG1peCB0aGUgdHdvIHNldHMg b2YgdGVybXM/DQo+Pg0KPj4gUGhpbGlwDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2 b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0Bp ZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRv OnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KDQo= --_000_75B6FA9F576969419E42BECB86CB1B891682EBEAxmbrcdx06ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDEx IDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U29ycnksIGJ1dCDigJx1bm51bWJlcmVk 4oCdIGhhcyBhbHJlYWR5IGJlZW4gTmFja2VkIGJ5IEVyaWNWIGFuZCBvdGhlcnMgaW4gdGhpcyBt YWlsZXIgYmVjYXVzZSB0aGUgaW50ZXJmYWNlIGJvcnJvd3MgdGhlIGxvb3BiYWNrIGludGVyZmFj ZeKAmXMgaXB2NiBnbG9iYWwgYWRkcmVzcw0KIHRvIHNvdXJjZSBzb21lIGlwdjYgcGFja2V0cy4m bmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnExpbmstbG9jYWwgb25seeKA nSBkb2VzbuKAmXQgbG9vayBnb29kIHRvIG1lIGJlY2F1c2Ugd2hhdCBpZiB0aGUgaW50ZXJmYWNl IGFjdHVhbGx5IHRyaWVkIERIQ1B2NiBvciBTTEFBQyBmb3IgYSBHVUEgYnV0IERIQ1B2NiBhbmQg U0xBQUMgZmFpbGVkPyZuYnNwOyZuYnNwOyBUaHVzIOKAnGFkbWluaXN0cmF0aXZlbHnigJ0NCiBz ZWVtcyB0byBiZSBrZXkgc28gdGhhdCBvbmUgaXMgY2xlYXIgdGhlIGFkbWluIG1hbmFnaW5nIHRo ZSBpbnRlcmZhY2Ugb24gdGhlIG5vZGUgY29uc2Npb3VzbHkgd2FudGVkIG9ubHkgYSBsaW5rLWxv Y2FsIGFkZHJlc3Mgb24gdGhlIGludGVyZmFjZS4mbmJzcDsgV2h5IG5vdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCc YWRtaW5pc3RyYXRpdmVseSBsaW5rLWxvY2FsIG9ubHnigJ0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZW1hbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmsgWlpaIFNtaXRoPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgTWFyY2ggMjMsIDIwMTUgNzowNyBQTTxicj4NCjxiPlRvOjwvYj4gVmljdG9yIEt1YXJzaW5n aDsgdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gU2hvdWxk IHdlIHVzZSAmcXVvdDt1bm51bWJlcmVkJnF1b3Q7IGluIElQdjY/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI3MTUxMjgwNDEyXzEwMDc4 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkkgc3RpbGwgdGhpbmsgJ2xpbmstbG9jYWwgb25seScgaXMgYmV0 dGVyLCBhcyBpdCBpcyB2ZXJ5IGV4cGxpY2l0bHkgc2F5aW5nIHdoYXQgdGhlIGFkZHJlc3Npbmcg c2NoZW1lIGlzLiBUaGVyZSBpcyBubyBhbmQgY2Fubm90IGJlIGFueSBhbWJpZ3VpdHkuJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQy NzE1MTI4MDQxMl8xMDA3OCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI3MTUxMjgwNDEyXzEwMDc4 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkkgdGhpbmsgJ2FkbWluaXN0cmF0aXZlbHkgdW5udW1iZXJlZCcg aXMgY2xvc2UgdG8gdGhlIGludmVyc2Ugb2YgdGhhdCBhbmQgbGVzcyBkZXNjcmlwdGl2ZSBhbmQg c3BlY2lmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18x Nl8wXzFfMTQyNzE1MTI4MDQxMl8xMDA3OCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI3MTUxMjgw NDEyXzEwMDc4Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjcxNTEyODA0MTJfMTAwNzgiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJ5dWlfM18xNl8wXzFfMTQyNzE1MTI4MDQxMl8xMDA3OCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI3MTUxMjgwNDEy XzEwMDgyIj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI3MTUxMjgwNDEyXzEwMDgxIj4NCjxk aXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI3MTUxMjgwNDEyXzEwMDgwIj4NCjxkaXYgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0 aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiBWaWN0b3IgS3VhcnNpbmdoICZsdDs8YSBocmVmPSJtYWlsdG86dmljdG9y QGp2a25ldC5jb20iPnZpY3RvckBqdmtuZXQuY29tPC9hPiZndDs8YnI+DQo8Yj5Ubzo8L2I+IDxh IGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+IDxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIDIzIE1hcmNoIDIwMTUsIDIzOjIzPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbdjZvcHNdIFNob3VsZCB3ZSB1c2UgJnF1b3Q7dW5udW1iZXJlZCZxdW90OyBpbiBJ UHY2Pzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjcxNTEyODA0MTJfMTA5MDciPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PGJyPg0KRXJpYy9BbGwsPGJyPg0KPGJyPg0KV2hhdCBhYm91dCB0aGUg dGVybSAmcXVvdDthZG1pbmlzdHJhdGl2ZWx5IHVubnVtYmVyZWQ/JnF1b3Q7Jm5ic3A7IFRoaXMg Y291bGQgYmUgPGJyPg0KZGVmaW5lZCBhcyBhbiBpbnRlcmZhY2Ugd2hlcmUgdGhlIG5ldHdvcmsg YWRtaW5pc3RyYXRvciBkaWQgbm90IDxicj4NCnNwZWNpZmljYWxseSBudW1iZXIgdGhlIGludGVy ZmFjZSwgYnV0IGRvZXMgbm90IHByZWNsdWRlIGl0IGZyb20gaGF2aW5nIDxicj4NCmFuIGFkZHJl c3MgYXQgYWxsIChpLmUuIExMIGFkZHJlc3MpLjxicj4NCjxicj4NCnJlZ2FyZHMsPGJyPg0KPGJy Pg0KVmljdG9yIEs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAyMDE1LTAzLTEwIDU6MTUgUE0s IEVyaWMgVnluY2tlIChldnluY2tlKSB3cm90ZTo8YnI+DQomZ3Q7IFBoaWxpcDxicj4NCiZndDs8 YnI+DQomZ3Q7IEluIHRoZSBsZWdhY3kgd29ybGQgb2YgSVB2NCwgdW5udW1iZXJlZCBhY3R1YWxs eSBtZWFucyB1c2luZyBhIGdsb2JhbCBJUHY0PGJyPg0KJmd0OyBhZGRyZXNzICdzdG9sZW4nIGZy b20gYW5vdGhlciBpbnRlcmZhY2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gdGhlIGN1cnJlbnQg d29ybGQgb2YgSVB2NiwgZXZlcnkgaW50ZXJmYWNlIGhhcyBhdCBsZWFzdCBhIGxpbmstbG9jYWw8 YnI+DQomZ3Q7IGFkZHJlc3Mgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIElHUCBhbmQgb3RoZXIgcHVy cG9zZXMgKHNlZSBSRkMgNzQwNCkgd2hpY2g8YnI+DQomZ3Q7IGlzIE5PVCBlcXVpdmFsZW50IChJ TUhPKSB0byAndW5udW1iZXJlZCBpbnRlcmZhY2UnPGJyPg0KJmd0Ozxicj4NCiZndDsgU28sIEkg YW0gYWZyYWlkIHRoYXQgeW91IHNob3VsZCB1c2UgYW5vdGhlciB3b3JraW5nIChhbGJlaXQgY3Vt YmVyc29tZSk8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtw6lyaWM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBP biAxMC8wMy8xNSAxNTo1MiwgJnF1b3Q7UGhpbGlwIE1hdHRoZXdzJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhIj5waGlsaXBfbWF0dGhld3NAbWFnbWEu Y2E8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgSnVzdCB3YW50IHRvIGdl dCBzb21lIGRpcmVjdCBmZWVkYmFjayBmcm9tIHRoZSBXRyBvbiB0aGUgdXNlIG9mIHRoZSB0ZXJt czxicj4NCiZndDsmZ3Q7ICZxdW90O3VubnVtYmVyZWQgaW50ZXJmYWNlJnF1b3Q7IGFuZCAmcXVv dDt1bm51bWJlcmVkIGxpbmsmcXVvdDsgaW4gSVB2Ni48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IE1hcmsgU21pdGgsIGluIHNvbWUgY29tbWVudHMgb24gdGhlIERlc2lnbiBDaG9pY2VzIGRy YWZ0ICwgaGFzIHNhaWQgdGhhdDxicj4NCiZndDsmZ3Q7IGhlIHByZWZlcnMgdGhlIHRlcm1zICZx dW90O2ludGVyZmFjZSB3aXRoIG9ubHkgbGluay1sb2NhbCBhZGRyZXNzJnF1b3Q7IG9yICZxdW90 O2xpbms8YnI+DQomZ3Q7Jmd0OyB3aXRoIG9ubHkgbGluay1sb2NhbCBhZGRyZXNzZXMmcXVvdDsg aW5zdGVhZC4mbmJzcDsgU2VlIHRoZSB0aHJlYWQgd2l0aCB0aXRsZSAmcXVvdDtJLUQ8YnI+DQom Z3Q7Jmd0OyBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMtMDQudHh0JnF1 b3Q7Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2hhdCBkb2VzIHRoZSBXRyB0aGluaz8m bmJzcDsgU2hvdWxkIHdlIHVzZSB0aGUgJnF1b3Q7dW5udW1iZXJlZCZxdW90OyB0ZXJtcywgb3Ig c2hvdWxkPGJyPg0KJmd0OyZndDsgd2UgdXNlIGp1c3QgdGhlICZxdW90Oy4uLiB3aXRoIG9ubHkg bGluay1sb2NhbCBhZGRyZXNzJnF1b3Q7IHRlcm1zPyZuYnNwOyBJcyBpdDxicj4NCiZndDsmZ3Q7 IGFjY2VwdGFibGUgdG8gbWl4IHRoZSB0d28gc2V0cyBvZiB0ZXJtcz88YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IFBoaWxpcDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXF0 ZmQzMTg5NCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wczwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_75B6FA9F576969419E42BECB86CB1B891682EBEAxmbrcdx06ciscoc_-- From nobody Mon Mar 23 17:16:06 2015 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 103141A8035 for ; Mon, 23 Mar 2015 17:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 4Z-NhDICycR4 for ; Mon, 23 Mar 2015 17:16: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 803A21A702E for ; Mon, 23 Mar 2015 17:16:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2O0G0kk019899 for ; Tue, 24 Mar 2015 01:16:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6D53D202E00 for ; Tue, 24 Mar 2015 01:16: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 63F11202BB6 for ; Tue, 24 Mar 2015 01:16:41 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2O0FvCC018178 for ; Tue, 24 Mar 2015 01:15:59 +0100 Message-ID: <5510ACBD.2040109@gmail.com> Date: Mon, 23 Mar 2015 19:15:57 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> <75B6FA9F576969419E42BECB86CB1B891682EBEA@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B891682EBEA@xmb-rcd-x06.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 24 Mar 2015 00:16:05 -0000 One cant have an interface be unnumbered yet numbered by a link-local address. One can't have 'an interface with only link-local address' because there is the MAC address as well. One cant have a '_link_ with only link local addresses' because a link is fixed into computers which have addresses configured on interfaces on that link, but also on virtual interfaces, and on other real interfaces. A link by itself does not make much sense. We could as well call this a 'transit-only' link. Alex Le 23/03/2015 18:56, Hemant Singh (shemant) a écrit : > Sorry, but “unnumbered” has already been Nacked by EricV and others in > this mailer because the interface borrows the loopback interface’s ipv6 > global address to source some ipv6 packets. > > “Link-local only” doesn’t look good to me because what if the interface > actually tried DHCPv6 or SLAAC for a GUA but DHCPv6 and SLAAC failed? > Thus “administratively” seems to be key so that one is clear the admin > managing the interface on the node consciously wanted only a link-local > address on the interface. Why not > > “administratively link-local only”. > > Hemant > > *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Mark ZZZ Smith > *Sent:* Monday, March 23, 2015 7:07 PM > *To:* Victor Kuarsingh; v6ops@ietf.org > *Subject:* Re: [v6ops] Should we use "unnumbered" in IPv6? > > I still think 'link-local only' is better, as it is very explicitly > saying what the addressing scheme is. There is no and cannot be any > ambiguity. > > I think 'administratively unnumbered' is close to the inverse of that > and less descriptive and specific. > > ------------------------------------------------------------------------ > > *From:*Victor Kuarsingh > > *To:* v6ops@ietf.org > *Sent:* Monday, 23 March 2015, 23:23 > *Subject:* Re: [v6ops] Should we use "unnumbered" in IPv6? > > > Eric/All, > > What about the term "administratively unnumbered?" This could be > defined as an interface where the network administrator did not > specifically number the interface, but does not preclude it from having > an address at all (i.e. LL address). > > regards, > > Victor K > > > > On 2015-03-10 5:15 PM, Eric Vyncke (evyncke) wrote: >> Philip >> >> In the legacy world of IPv4, unnumbered actually means using a global IPv4 >> address 'stolen' from another interface. >> >> In the current world of IPv6, every interface has at least a link-local >> address which can be used for IGP and other purposes (see RFC 7404) which >> is NOT equivalent (IMHO) to 'unnumbered interface' >> >> So, I am afraid that you should use another working (albeit cumbersome) >> >> -éric >> >> On 10/03/15 15:52, "Philip Matthews" > wrote: >> >>> Just want to get some direct feedback from the WG on the use of the terms >>> "unnumbered interface" and "unnumbered link" in IPv6. >>> >>> Mark Smith, in some comments on the Design Choices draft , has said that >>> he prefers the terms "interface with only link-local address" or "link >>> with only link-local addresses" instead. See the thread with title "I-D >>> Action: draft-ietf-v6ops-design-choices-04.txt". >>> >>> What does the WG think? Should we use the "unnumbered" terms, or should >>> we use just the "... with only link-local address" terms? Is it >>> acceptable to mix the two sets of terms? >>> >>> Philip >>> >>> >>> _______________________________________________ >>> 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 Mon Mar 23 17:25:46 2015 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 573C51A90DD for ; Mon, 23 Mar 2015 17:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 xcuVKdxWtqAl for ; Mon, 23 Mar 2015 17:25:42 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 48ADD1A90C7 for ; Mon, 23 Mar 2015 17:25:42 -0700 (PDT) Received: from [2001:67c:370:160:c80b:333b:eb35:8e14] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YaCf5-0000n1-9Y; Tue, 24 Mar 2015 01:25:39 +0100 Message-ID: <5510A522.7040008@si6networks.com> Date: Mon, 23 Mar 2015 18:43:30 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Victor Kuarsingh , "v6ops@ietf.org" References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 24 Mar 2015 00:25:44 -0000 On 03/23/2015 06:07 PM, Mark ZZZ Smith wrote: > I still think 'link-local only' is better, as it is very explicitly > saying what the addressing scheme is. There is no and cannot be any > ambiguity. > > I think 'administratively unnumbered' is close to the inverse of that > and less descriptive and specific. +1 Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Mar 23 18:32:47 2015 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 E674A1B2B38 for ; Mon, 23 Mar 2015 18:32:46 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 k0UMcsOtlujF for ; Mon, 23 Mar 2015 18:32:44 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (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 8000D1B2B36 for ; Mon, 23 Mar 2015 18:32:44 -0700 (PDT) Received: by igcqo1 with SMTP id qo1so54932909igc.0 for ; Mon, 23 Mar 2015 18:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=maCywEOQsvrA6RrErsMucHlPA9PaobsHO0UK9hlVrEc=; b=YZJ6Cn18R/kP9Cd+to5uam0vcVjy6qu+6rtGzH7mAjNREYt6ruS8WNWT+CNuLOLjQp Fs4H4QNuHjNre+kpTGTSIn4tBL+Fng6RMKrvO+Bdzz1HRlTI+OjcQDo+YnMuToPbK7pT DPRO+Amn9u/yj84FPBpjimd35kmXoeSYxw83yLlgH/z44rQT+mA/W96oKct1T49TV5cA QFCAtS/e5/Suy8nF8QtW8LC0J/2s7YG06qo4maBZEtWeQAXDzg3NuNpi2qyZfSjmSoJS QXPTp6vuH66FQMzEP0IL4mI/dWUn1Ln9sI8C7BZ01vtDHBNEa6YuDK/X5NxiayqXmDnR ra3g== X-Gm-Message-State: ALoCoQnvPv1+0t69FHkKukOldwaNAeT5EOTiizl2rQedQUtDCAU4Gqrbot7ezPaTOx25S9bExml8 X-Received: by 10.43.38.144 with SMTP id ti16mr22936187icb.26.1427160763714; Mon, 23 Mar 2015 18:32:43 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local (CPE001319d6e9ab-CM84948c50c950.cpe.net.cable.rogers.com. [99.230.38.79]) by mx.google.com with ESMTPSA id o196sm1730219ioe.26.2015.03.23.18.32.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 18:32:43 -0700 (PDT) Message-ID: <5510BEBD.2030507@jvknet.com> Date: Mon, 23 Mar 2015 21:32:45 -0400 From: Victor Kuarsingh User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alexandru Petrescu , v6ops@ietf.org References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> <75B6FA9F576969419E42BECB86CB1B891682EBEA@xmb-rcd-x06.cisco.com> <5510ACBD.2040109@gmail.com> In-Reply-To: <5510ACBD.2040109@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 24 Mar 2015 01:32:47 -0000 All, What's one more email in such an active conversation. Here area few points to take note of. - When I suggested "administratively unnumbered", I was intending to find text which has less imposed (vs just "unnumbered") meaning while attempting to keep within the spirit of the text in section 2.1.2. - The intention of this text was to describe the configuration choices for links within a network, which was to apply a ULA/GUA or to not apply a ULA/GUA (in which case the LL address would be the only one that remains). - The emphasis for the draft section is about what the operator/administrator will (or will not) apply as configuration and not what potential behaviors will be exhibited (although this would have relevance for troubleshooting, but I don't think that is specific to this draft in that it's something to consider more widely). - The action in the one case (by the administrator) would be to not apply addressing (additional) to a link, in which case the result is LL-only. - When I re-read the text to myself, substituting "administratively unnumbered" , it seemed to make sense to me (I am biased), and the flow of the text seems to make sense as I put myself into the position of a operator reading this for guidance. I don't think they will be confused at all (given the context and full text). - Section 2.1.2 text does present the options as (a). link-local addresses ("unnumbered") or (b) have global or ULA addresses assigned. which are in fact the choices (where I am already presuming we would have replaced "unnumbered" with "administratively unnumbered") - I think it's important for us to realize the intention of the section, and what we are trying to accomplish by providing the general choices to the reader. - We then have a reference to "draft-ietf-opsec-lla-only" which is a document that then goes into more detail of the approach, advantages and caveats of using LL-only addressing models. I don't want to undermine the great conversation we had on the list on the potential impacts of using ll-only and the behaviors which we may see, but feel that (as I think others have noted), can be captured in a more appropriate document. my two cents, regards, Victor K On 2015-03-23 8:15 PM, Alexandru Petrescu wrote: > One cant have an interface be unnumbered yet numbered by a link-local > address. > > One can't have 'an interface with only link-local address' because > there is the MAC address as well. > > One cant have a '_link_ with only link local addresses' because a link > is fixed into computers which have addresses configured on interfaces > on that link, but also on virtual interfaces, and on other real > interfaces. A link by itself does not make much sense. > > We could as well call this a 'transit-only' link. > > Alex > > Le 23/03/2015 18:56, Hemant Singh (shemant) a écrit : >> Sorry, but “unnumbered” has already been Nacked by EricV and others in >> this mailer because the interface borrows the loopback interface’s ipv6 >> global address to source some ipv6 packets. >> >> “Link-local only” doesn’t look good to me because what if the interface >> actually tried DHCPv6 or SLAAC for a GUA but DHCPv6 and SLAAC failed? >> Thus “administratively” seems to be key so that one is clear the admin >> managing the interface on the node consciously wanted only a link-local >> address on the interface. Why not >> >> “administratively link-local only”. >> >> Hemant >> >> *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Mark ZZZ >> Smith >> *Sent:* Monday, March 23, 2015 7:07 PM >> *To:* Victor Kuarsingh; v6ops@ietf.org >> *Subject:* Re: [v6ops] Should we use "unnumbered" in IPv6? >> >> I still think 'link-local only' is better, as it is very explicitly >> saying what the addressing scheme is. There is no and cannot be any >> ambiguity. >> >> I think 'administratively unnumbered' is close to the inverse of that >> and less descriptive and specific. >> >> ------------------------------------------------------------------------ >> >> *From:*Victor Kuarsingh > >> *To:* v6ops@ietf.org >> *Sent:* Monday, 23 March 2015, 23:23 >> *Subject:* Re: [v6ops] Should we use "unnumbered" in IPv6? >> >> >> Eric/All, >> >> What about the term "administratively unnumbered?" This could be >> defined as an interface where the network administrator did not >> specifically number the interface, but does not preclude it from having >> an address at all (i.e. LL address). >> >> regards, >> >> Victor K >> >> >> >> On 2015-03-10 5:15 PM, Eric Vyncke (evyncke) wrote: >>> Philip >>> >>> In the legacy world of IPv4, unnumbered actually means using a >>> global IPv4 >>> address 'stolen' from another interface. >>> >>> In the current world of IPv6, every interface has at least a link-local >>> address which can be used for IGP and other purposes (see RFC 7404) >>> which >>> is NOT equivalent (IMHO) to 'unnumbered interface' >>> >>> So, I am afraid that you should use another working (albeit cumbersome) >>> >>> -éric >>> >>> On 10/03/15 15:52, "Philip Matthews" >> > wrote: >>> >>>> Just want to get some direct feedback from the WG on the use of the >>>> terms >>>> "unnumbered interface" and "unnumbered link" in IPv6. >>>> >>>> Mark Smith, in some comments on the Design Choices draft , has said >>>> that >>>> he prefers the terms "interface with only link-local address" or "link >>>> with only link-local addresses" instead. See the thread with title >>>> "I-D >>>> Action: draft-ietf-v6ops-design-choices-04.txt". >>>> >>>> What does the WG think? Should we use the "unnumbered" terms, or >>>> should >>>> we use just the "... with only link-local address" terms? Is it >>>> acceptable to mix the two sets of terms? >>>> >>>> Philip >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Mar 24 05:53:40 2015 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 474161A0084 for ; Tue, 24 Mar 2015 05:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dukEuRALW2rW for ; Tue, 24 Mar 2015 05:53: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 2C1E71A0056 for ; Tue, 24 Mar 2015 05:53:36 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so65370949igb.1 for ; Tue, 24 Mar 2015 05:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W6/sMGBe9QgRsT2nbkN9ljY2It88VVAnVBxeYLZs4F0=; b=YQsEizcj5+TW88XvMQWESOVk/2Mcr00ycC2xG4CKlL7lJpy9LTi/gRM80h3zCrtqkn bOM2zEZ1kHfXqWhLeGYtyZf4wMKQm9PQ5AJg9NWVxg4XROUsleB0UVpI9TKy1l/hx1dG trKyf4c6MiOGrmwEvHl0G/qwCC6pByjj/zlPH//EcHBMrJm72V+AYXKHpK4kRTBEcalK 4/AEX45W24x0VbPYS+kABbeRvX9kPdWRhEvwiH3uGHAZrPauPdBsrHeNMc1Wp812jeyb qK12tPOs6IRO4y7Z+byGpVBSPPUeHxJg9dheXIM+p9qtvLWNm8+8Nbd8vtzA3et4oFcb YELA== 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-type; bh=W6/sMGBe9QgRsT2nbkN9ljY2It88VVAnVBxeYLZs4F0=; b=ax0r4g0jtdK0kviaIPE5/ThEG7sDG/vhBRArtoN62+M369CeAPIS/o8SnfJAFIh1tZ vWqc2MZ8oVOhEqgu0rQisu9g1oxJlzXWllW66t/Cm+cbdThNuv7a3i/StHePLy+ujBcp cEjuALdg8jNCdUXh333k7QdQRB78d65bYzyUMZiefe5/f4RrU8QL8gfk4AtdkFbvTgeb Z0BPZzzW8u9jSMk5b69gSQ0m+OA3dv263gZr7Ov7eNXKMT8EL+STdYAHbGKLmT9JxOvk C/Fj1/eHOUmGLqtsxuSc8jTWgzafo0xLqsKjm35FSBN5r6KSVdJBv81ewYalWAQIQ7g9 N//Q== X-Gm-Message-State: ALoCoQmG3dY9lyeqDVLrGxHBKofSYbiGKkQC03ERH3C7c+jQSfn0GsLontIHAnGs6nMRuSu+2WXy X-Received: by 10.107.137.25 with SMTP id l25mr6061701iod.23.1427201616469; Tue, 24 Mar 2015 05:53:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Tue, 24 Mar 2015 05:53:16 -0700 (PDT) In-Reply-To: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> From: Lorenzo Colitti Date: Tue, 24 Mar 2015 07:53:16 -0500 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=001a113fb1585f939505120845cb Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 12:53:38 -0000 --001a113fb1585f939505120845cb Content-Type: text/plain; charset=UTF-8 On Fri, Mar 20, 2015 at 7:42 AM, Tore Anderson wrote: > Justine Vick from Microsoft held a very interesting presentation at the > V6 World Congress on Wednesday about their plans to make one of their > buildings IPv6-only. One of the things she had identified a need for > was to have a CLAT in the desktop version of Windows. She had already > established contact with the relevant teams to try to make that happen > (I asked her to add the Windows Server folks to her CC list). Fingers > crossed! > Are the slides of that presentation available, and if not, do you know how we might be able to read them? (e.g., by getting in touch with Justine). --001a113fb1585f939505120845cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 20, 2015 at 7:42 AM, Tore Anderson <tore@fud.no> wrote:
Justine Vick from Microsoft held a very int= eresting presentation at the
V6 World Congress on Wednesday about their plans to make one of their
buildings IPv6-only. One of the things she had identified a need for
was to have a CLAT in the desktop version of Windows. She had already
established contact with the relevant teams to try to make that happen
(I asked her to add the Windows Server folks to her CC list). Fingers
crossed!

Are the slides of that present= ation available, and if not, do you know how we might be able to read them?= (e.g., by getting in touch with Justine).
--001a113fb1585f939505120845cb-- From nobody Tue Mar 24 05:54:56 2015 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 DC29C1A006D for ; Tue, 24 Mar 2015 05:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wxM81tSifZyt for ; Tue, 24 Mar 2015 05:54:54 -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 D508A1A0084 for ; Tue, 24 Mar 2015 05:54:53 -0700 (PDT) Received: by igcau2 with SMTP id au2so51240715igc.1 for ; Tue, 24 Mar 2015 05:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1a5JaK5TMNDAUICjezH2nFkex9MILFuzOSXqfJot6m4=; b=aQuKixLnaNenp8ZsQaSoU76BjqKmusmVDnzUBmvnMkLNfmLsQaZetyvP4YsvN8JWxM Uwp1fnbV+U0D3Fhglp894kkEm8Mqal9L3ejBePFOHU3qTh7R1ukpsgZnWzuJWH9u9ZpN GzrJ2XEpGF/B2OcUO9eP4147aXxJKDjRz5jgzpMPMTnY1mpoPKkDV7SrlQ4gd6XgJfci 5ukjsz7Sr6+ph3SZg7UGTcYpgXCajdQ+poL035AxX5X//4F8l5qxbST+txRtvrEQvZ6V Xi3rvagAUNYoBWezK2kCHe9sFSFYLzlhccHO77rfa1WXWtrQjH9kDzLYQx2zEkOld1LF 2AOA== 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-type; bh=1a5JaK5TMNDAUICjezH2nFkex9MILFuzOSXqfJot6m4=; b=CeA4Fe1ovoxh2az9o9YvHnFzXJI4ZVldRetmHT2Zy6633qkBkerJkq0AE+XVMW/DSx t/y1CZovLK8uYVPx6yZ7UfnoeE+6zGPj8MaCyh3DoCprAlcFT8U5NfeLT511CO5ICRrW PUInkj6eSHRD1jxmolZ5/mYEjqn5AXE3jc+Q7NXU5BNmAVnq2lfzotV9XXYPIhtXPrCb O9O5qzbwdgQT3Ui7vMkP5aAPFFlUvUnqFLXwUx57PnB3FG90cTD2CDrVl92A9YaFFF1P 4bxjSYHQ3r5POxTaW3eXqqIG+E/q/bUm86zA7LFOdPQrlZst2Ucn54wTwYq5Xio6iyER P4kA== X-Gm-Message-State: ALoCoQmaornTqjmGdwYEnZPRhz1SDnSkJldAjoYkC9cXuNPRFLvka/Rk0kkvu4vo4mMU1/npfse2 X-Received: by 10.50.124.164 with SMTP id mj4mr21630157igb.38.1427201693034; Tue, 24 Mar 2015 05:54:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Tue, 24 Mar 2015 05:54:32 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> From: Lorenzo Colitti Date: Tue, 24 Mar 2015 07:54:32 -0500 Message-ID: To: Ca By Content-Type: multipart/alternative; boundary=001a11c2a686efe6cd0512084992 Archived-At: Cc: IPv6 Ops WG , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 12:54:55 -0000 --001a11c2a686efe6cd0512084992 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 11:12 AM, Ca By wrote: > But there is one major mobile OS missing this feature. > > Perhaps the IETF should give guidance via BCP that an IPv6-only solution > that supports IPv4 sockets be supported on hosts > Oh, I see why you started this thread now. Do you expect that the IETF would be able to reach consensus on such a statement? --001a11c2a686efe6cd0512084992 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 23, 2015 at 11:12 AM, Ca By <cb.list6@gmail.com> wr= ote:
But there is one major mobile OS mi= ssing this feature.

Perhaps the IETF should give g= uidance via BCP that an IPv6-only solution that supports IPv4 sockets be su= pported on hosts=C2=A0

<= div>Oh, I see why you started this thread now. Do you expect that the IETF = would be able to reach consensus on such a statement?
--001a11c2a686efe6cd0512084992-- From nobody Tue Mar 24 06:52:48 2015 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 900A01A86F1 for ; Tue, 24 Mar 2015 06:52:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 ORoWTUWU3e5J for ; Tue, 24 Mar 2015 06:52:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAFA1A86F7 for ; Tue, 24 Mar 2015 06:52:44 -0700 (PDT) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 24 Mar 2015 13:52:43 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0118.021; Tue, 24 Mar 2015 13:52:43 +0000 From: "Metzler, Dan J" To: Victor Kuarsingh , Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQW0H0aXH7g/48ckavSwrGIzcwY50WOCmAgBPZpICAALPZgIAADeAAgAAFXICAABV1gIAAwAZQ Date: Tue, 24 Mar 2015 13:52:43 +0000 Message-ID: References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> <75B6FA9F576969419E42BECB86CB1B891682EBEA@xmb-rcd-x06.cisco.com> <5510ACBD.2040109@gmail.com> <5510BEBD.2030507@jvknet.com> In-Reply-To: <5510BEBD.2030507@jvknet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:0:e50:1001:f5f6:fde1:5644:3bb8] authentication-results: jvknet.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB585; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(13464003)(93886004)(106116001)(88552001)(33656002)(122556002)(89122001)(2501003)(75432002)(40100003)(46102003)(107886001)(76576001)(2656002)(87936001)(74316001)(90282001)(62966003)(77156002)(19580395003)(50986999)(86362001)(54356999)(92566002)(2900100001)(2950100001)(99286002)(19580405001)(102836002)(76176999)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB585; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO2PR04MB585; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB585; x-forefront-prvs: 0525BB0ADF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2015 13:52:43.3644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB585 Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 24 Mar 2015 13:52:46 -0000 Hi, See below: > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor Kuarsingh > Sent: Monday, March 23, 2015 8:33 PM > To: Alexandru Petrescu; v6ops@ietf.org > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >=20 > All, >=20 > What's one more email in such an active conversation. Here area few poin= ts > to take note of. >=20 > - When I suggested "administratively unnumbered", I was intending to find > text which has less imposed (vs just "unnumbered") meaning while attempti= ng > to keep within the spirit of the text in section 2.1.2. I sort of understand where you're coming from, but I think the addition of= "administratively" just modified the confusion, but did not remove it. I think you're trying to equate the situation to something in IPv4 to make = it seem more familiar. In the short term that might have some benefit, but= in the long term it seems to lose meaning. I think the term "unnumbered" is what introduces the confusion, simply beca= use it is different with IPv6. >=20 > - The intention of this text was to describe the configuration choices fo= r links > within a network, which was to apply a ULA/GUA or to not apply a ULA/GUA > (in which case the LL address would be the only one that remains). If you are using "administratively unnumbered" in any way that is not inten= ded to confuse the issue, then I think you can't assume that LL is the only= one that remains. With IPv6, that just means you're leaving it up to the = network operator vs the system admin. It might be ULA. It might be GUA. = It might be LL. It depends on what's in the flags in the RA. If that's really what you meant then the assumption that LL address is the = only one that remains is simply a flawed assumption, but "Administratively = Unnumbered" becomes closer to a reasonable term, other than the fact that "= unnumbered" is technically inaccurate. (And that's probably what people fi= nd most confusing.) If you really meant LL-only, then "Administratively Unnumbered" is probably= not the best term because it doesn't really describe what you meant. (Do you see how it gets confusing?) >=20 > - The emphasis for the draft section is about what the operator/administr= ator > will (or will not) apply as configuration and not what potential behavior= s will > be exhibited (although this would have relevance for troubleshooting, but= I > don't think that is specific to this draft in that it's something to cons= ider more > widely). Agreed. >=20 > - The action in the one case (by the administrator) would be to not apply > addressing (additional) to a link, in which case the result is LL-only. What do you mean by "administrator"? (System admin or network admin or bot= h) That's only correct if there is no router on the network, but if that's par= t of the scenario you're discussing right now, then ok. (Can also get GUA = and ULA from RAs imposed by the network operator; unless by the phrase "by = the administrator" you meant by either network or system admin. ) Ultimately, if you really mean LL-only, I think you should just say that. = It seems like a lot of effort to dance around it with implications, and sti= ll try to convey what you actually meant without confusing the issue. Cheers, - Dan Metzler From nobody Tue Mar 24 07:03:04 2015 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 1F7281A8716 for ; Tue, 24 Mar 2015 07:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 s8zgq-TGYiLL for ; Tue, 24 Mar 2015 07:03:02 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB721A872A for ; Tue, 24 Mar 2015 07:02:45 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id t2ODuOD6061593; Tue, 24 Mar 2015 14:56:24 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201503241356.t2ODuOD6061593@givry.fdupont.fr> From: Francis Dupont To: Fernando Gont In-reply-to: Your message of Mon, 23 Mar 2015 18:43:30 EST. <5510A522.7040008@si6networks.com> Date: Tue, 24 Mar 2015 14:56:24 +0100 Sender: Francis.Dupont@fdupont.fr Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 24 Mar 2015 14:03:03 -0000 In your previous mail you wrote: > On 03/23/2015 06:07 PM, Mark ZZZ Smith wrote: > > I still think 'link-local only' is better, as it is very explicitly > > saying what the addressing scheme is. There is no and cannot be any > > ambiguity. > > > > I think 'administratively unnumbered' is close to the inverse of that > > and less descriptive and specific. > > +1 +1 Francis.Dupont@fdupont.fr From nobody Tue Mar 24 07:06:57 2015 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 58C571A872D for ; Tue, 24 Mar 2015 07:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vPDc9armPxQE for ; Tue, 24 Mar 2015 07:06:54 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50FC71A871C for ; Tue, 24 Mar 2015 07:06:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E260A2; Tue, 24 Mar 2015 15:06:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1427206012; bh=ocCM35++ai8mAlp3FAoEb3VqynCH34I5Q5M7A+gYrVA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DX3GSu477jYwvUsT2SYjMjlE96AkdV2A6uxEaNlHMR7l53NP4OSwRevc9d2zVd/hw lI/MwTv+xaltRTd0PEcgx/g20xl5tv2SMUuJUfF6Sb8BidFtyGRNeS93N80IPKvr2Z SO4lS28wZXHRhJFuTM4/JuJEMS0pDk8P7Dsa8Mts= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 58DF9A1; Tue, 24 Mar 2015 15:06:52 +0100 (CET) Date: Tue, 24 Mar 2015 15:06:52 +0100 (CET) From: Mikael Abrahamsson To: Mark ZZZ Smith In-Reply-To: <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> Message-ID: References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-583899563-1427206012=:20507" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 24 Mar 2015 14:06:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-583899563-1427206012=:20507 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 23 Mar 2015, Mark ZZZ Smith wrote: > I still think 'link-local only' is better, as it is very explicitly saying what the addressing scheme is. There is no and cannot be any ambiguity.  > I think 'administratively unnumbered' is close to the inverse of that and less descriptive and specific. Yes, I don't like "administratively unnumbered" either. "interface without address", "link-local only" or some other variant is fine, but I really do not like the use of "unnumbered", with or without prefix to this. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-583899563-1427206012=:20507-- From nobody Tue Mar 24 07:11:13 2015 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 CB92B1A8716 for ; Tue, 24 Mar 2015 07:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 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, FREEMAIL_REPLY=1, 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 2PymcFj0MhEs for ; Tue, 24 Mar 2015 07:11:11 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c: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 9DE801A8739 for ; Tue, 24 Mar 2015 07:11:10 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so97271923wib.1 for ; Tue, 24 Mar 2015 07:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vhxPvzx7zhrB9F8EQ6mk3li4/SJ5vuPK267AGiyKXC0=; b=WY7hDFXdw23wjJtThZZ+jLJqBnMWARNwP1u+PG6j3SINiIh7wn2/YP0FfWNAQNXr5c 54V3ZyGd8weqGjUyxUG7M+nGxGiMBU9PU12/8QqmkBTIzQGRyjyok26svJ4BRCgIWOka hjs2k16ZiBmCUfe68KOd7ZvfQzDqyLaKUkWLXU/YGMl8YECr0gPZhfxxWos1RgidZA8k iPTBNzoBPMiw1vwVUUsAzwG7GXMFSLdjQcibdiOspWASR5xDkEtWAs5atii5f27ZIfJE ZV6Zg9AItU1UU3dncR4WBbz2O9hnQO8+dFPAL2ODW89r9iKeGJXsVygoQwAtvLEnnp5V HIsA== MIME-Version: 1.0 X-Received: by 10.194.77.230 with SMTP id v6mr8461060wjw.25.1427206269316; Tue, 24 Mar 2015 07:11:09 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Tue, 24 Mar 2015 07:11:09 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Tue, 24 Mar 2015 07:11:09 -0700 Message-ID: From: Ca By To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7bfd028cb433de0512095ad7 Archived-At: Cc: IPv6 Ops WG , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 14:11:12 -0000 --047d7bfd028cb433de0512095ad7 Content-Type: text/plain; charset=UTF-8 On Tuesday, March 24, 2015, Lorenzo Colitti wrote: > On Mon, Mar 23, 2015 at 11:12 AM, Ca By > wrote: > >> But there is one major mobile OS missing this feature. >> >> Perhaps the IETF should give guidance via BCP that an IPv6-only solution >> that supports IPv4 sockets be supported on hosts >> > > Oh, I see why you started this thread now. Do you expect that the IETF > would be able to reach consensus on such a statement? > Yes. Are you in opposition? --047d7bfd028cb433de0512095ad7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, March 24, 2015, Lorenzo Colitti <lorenzo@google.com> wrote:
On Mon, Mar 23, 2015 at 11:12 AM, Ca By <cb.list6@gmail.com> wrote:
But there is one major mobile OS missing this feature= .

Perhaps the IETF should give guidance via BCP th= at an IPv6-only solution that supports IPv4 sockets be supported on hosts= =C2=A0

Oh, I see wh= y you started this thread now. Do you expect that the IETF would be able to= reach consensus on such a statement?
<= div>

Yes. Are you in opposition? =C2=A0
--047d7bfd028cb433de0512095ad7-- From nobody Tue Mar 24 07:13:33 2015 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 8DFED1A8734 for ; Tue, 24 Mar 2015 07:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XOqgcQRapRVT for ; Tue, 24 Mar 2015 07:13:26 -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 6FAB91A8738 for ; Tue, 24 Mar 2015 07:13:26 -0700 (PDT) Received: by igbud6 with SMTP id ud6so72839314igb.1 for ; Tue, 24 Mar 2015 07:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5tClT7BemEHRtVadZu4ILwanKgQx591x7FUbgZgtnr0=; b=BW+hq1KvTULsQ0rYuCUODry9akki3qiULZJK04+f0P023zTgJ66f/Yu0ag/rThJvMT 5Fd11P4R1Y9iKxNyvw8CV9BK3KSkE1oDEVmjlkyHz1vCosOYp31m/UppPTPcGmrjoVYz FyHqk5SL8wcI/UjJpfum/mVJ/1H2s5+xBASD6MaFJCQn67VY/Vt195+MzOdu0sUy/xra OoLCiqhg4wrGHezeH/RhZdtaH4TwitOrJkzsfW5+uLxoY3U0H0zzKVS41X1RBRHxsAyy VOweJ1bSpc95YmZ1NXYZm2WmLm0fEVEGBr2j2l4jNUdhpL2izzWjDGZ5i8c111i9PlvX teSg== 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-type; bh=5tClT7BemEHRtVadZu4ILwanKgQx591x7FUbgZgtnr0=; b=WL9J4vh5NP0QjQizzVNru+yJskoZSnOBOHDt7TqLel8t3hAjypvAdZUjFt49Iu+Er7 6Aida0xOMrPdW+RbJXT4LCTrAFC8K8DpTO8t6MSFCl3XmUDdeLriVshjjX1UTtameO9z PwOZ5P0aGtzu2KlR8IK03Hy4LnV4L5dO5+rbgxFPdDc/0WGQk5+EwZNkYN9OFpsRrQAA Avvl6PjUEdBfsAqLtDEOcWupJBiAVMk/sPv4whjVL+gmWliTaCrQZ+hf+gEzOw2OWcZt e2uvylvJF7NYtMHYwpCFTA7uk21gX9D9cIFrUjiR1CvpReknsogZKLBPZczTtd47e1oN Zlmw== X-Gm-Message-State: ALoCoQkuboanSq4zICViEBBdLc4OoVn/MPfxVD89YhDG3JWap92WWGm7uzMtOlth55SNJ+Z62rXs X-Received: by 10.43.94.70 with SMTP id bx6mr25773487icc.85.1427206405500; Tue, 24 Mar 2015 07:13:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Tue, 24 Mar 2015 07:13:05 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> From: Lorenzo Colitti Date: Tue, 24 Mar 2015 09:13:05 -0500 Message-ID: To: Ca By Content-Type: multipart/alternative; boundary=bcaec5186f08d25cbd05120962ac Archived-At: Cc: IPv6 Ops WG , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 14:13:32 -0000 --bcaec5186f08d25cbd05120962ac Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 9:11 AM, Ca By wrote: > > Oh, I see why you started this thread now. Do you expect that the IETF >> would be able to reach consensus on such a statement? >> > > Yes. Are you in opposition? > Oh, of course not. I'm the maintainer of a popular 464xlat implementation, remember? --bcaec5186f08d25cbd05120962ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 24, 2015 at 9:11 AM, Ca By <cb.list6@gmail.com> wro= te:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">
Oh, I see why you started this thread now. D= o you expect that the IETF would be able to reach consensus on such a state= ment?

Y= es. Are you in opposition?

Oh, of cou= rse not. I'm the maintainer of a popular 464xlat implementation, rememb= er?
--bcaec5186f08d25cbd05120962ac-- From nobody Tue Mar 24 07:40:21 2015 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 37B551A87C4 for ; Tue, 24 Mar 2015 07:40:20 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 JwDiK6z40O5T for ; Tue, 24 Mar 2015 07:40:18 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 A0EC01A87BB for ; Tue, 24 Mar 2015 07:39:48 -0700 (PDT) Received: by iedm5 with SMTP id m5so61895425ied.3 for ; Tue, 24 Mar 2015 07:39:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gEOtn6QHTM8NdQoI30ri/MVRYtD36/8QKsm110jNjLc=; b=elW0WncoWMr0/R7t5aj41UXAsdpgE9DhvC01NeEdqWOhknL5s+t/PIdjI+V/Rwf+NF BynGfwpHCnmVBiFsOlixCTFQEKvKGGyq2d0n+0JHNDM6+p32LA1l/uqHQCDLi5c+zdfJ QzH5TUgknaJfidxrjdkX+dPDlQCT+fLBJBvbixT+iQas2/wQ65w9MadrmKD59Sy9Jwsd REfUHUWHbnsJiustf2VaR2N2tFlAtyZNyC8utsSGHiP9RHcdkFs5gQ3FJD3mVRqIf7k/ odiXV8v9P02sCdrgMVjluRCTJUAEUWbIEbfnCtWtFSf1wrd1b5WvoX68z+tJaysIXa91 tIow== X-Gm-Message-State: ALoCoQny0GCaRlliQctNphEhjCpfPDltjSSva7w+hkr+zqJ8a860ZQ4uY+8WY3rUv3JdfvCPhx2t X-Received: by 10.107.31.14 with SMTP id f14mr6934059iof.28.1427207988182; Tue, 24 Mar 2015 07:39:48 -0700 (PDT) Received: from Victors-MacBook-Pro-2.local (CPE001319d6e9ab-CM84948c50c950.cpe.net.cable.rogers.com. [99.230.38.79]) by mx.google.com with ESMTPSA id 137sm2739419ioe.40.2015.03.24.07.39.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 07:39:47 -0700 (PDT) Message-ID: <55117731.6010806@jvknet.com> Date: Tue, 24 Mar 2015 10:39:45 -0400 From: Victor Kuarsingh User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Metzler, Dan J" , Alexandru Petrescu , "v6ops@ietf.org" References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> <75B6FA9F576969419E42BECB86CB1B891682EBEA@xmb-rcd-x06.cisco.com> <5510ACBD.2040109@gmail.com> <5510BEBD.2030507@jvknet.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 24 Mar 2015 14:40:20 -0000 On 2015-03-24 9:52 AM, Metzler, Dan J wrote: > Hi, > > See below: > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor Kuarsingh >> Sent: Monday, March 23, 2015 8:33 PM >> To: Alexandru Petrescu; v6ops@ietf.org >> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >> >> All, >> >> What's one more email in such an active conversation. Here area few points >> to take note of. >> >> - When I suggested "administratively unnumbered", I was intending to find >> text which has less imposed (vs just "unnumbered") meaning while attempting >> to keep within the spirit of the text in section 2.1.2. > I sort of understand where you're coming from, but I think the addition of "administratively" just modified the confusion, but did not remove it. > I think you're trying to equate the situation to something in IPv4 to make it seem more familiar. In the short term that might have some benefit, but in the long term it seems to lose meaning. > I think the term "unnumbered" is what introduces the confusion, simply because it is different with IPv6. I totally understand the differences between IPv4 and IPv6. You are right in a way, in that there are some parallels between IPv4 and IPv6 being drawn (since some parallels still exist, as well as differences). I guess the parallel component is the action the administrator (some may call this the sysadmin, or the network admin - all the same to me - the person or tool configuring stuff) takes. The result is where one of the differences are between IPv4 and IPv6. >> - The intention of this text was to describe the configuration choices for links >> within a network, which was to apply a ULA/GUA or to not apply a ULA/GUA >> (in which case the LL address would be the only one that remains). > If you are using "administratively unnumbered" in any way that is not intended to confuse the issue, then I think you can't assume that LL is the only one that remains. With IPv6, that just means you're leaving it up to the network operator vs the system admin. Maybe I missed something here, but we are specifically talking about the network operator / system admin (the subject of the conversation is the actions the person designing (and/or configuration) the network makes. > It might be ULA. It might be GUA. It might be LL. I think this is true and I think this is clear in the text as well. > It depends on what's in the flags in the RA. This is true, and using an RA to get a ULA/GUA onto an interface (vs. manual configuration) is just a way to do it (I don't think our draft discusses or recommends on how to accomplish the addressing. We point documents like RFC4852 which expand on the methods on how to address stuff (as an example). > If that's really what you meant then the assumption that LL address is the only one that remains is simply a flawed assumption, but "Administratively Unnumbered" becomes closer to a reasonable term, other than the fact that "unnumbered" is technically inaccurate. (And that's probably what people find most confusing.) I think we are all open to new terms, but that would likely become subject to further misconceptions unless well defined. I guess the "adminstatively" part of hte term was to denote "something you do to give it an address". > If you really meant LL-only, then "Administratively Unnumbered" is probably not the best term because it doesn't really describe what you meant. > > (Do you see how it gets confusing?) Well I do understand people's point, irrespective if I agree. To be honest, I am not confused, and when reading the text (as I had noted before) I don't think folks who would seek guidance in such a draft would come away not understanding what the options are, or what the result will be. I do agree, that out of context, it can be considered confusing, but I am not considering the use of the word out of context. >> - The action in the one case (by the administrator) would be to not apply >> addressing (additional) to a link, in which case the result is LL-only. > What do you mean by "administrator"? (System admin or network admin or both) The term administrator was to apply to anyone who managers/configures network (was to cover all cases). A sysadmin and netadmin are just types of administrators. Victor K From nobody Tue Mar 24 08:07:03 2015 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 135611A87E0 for ; Tue, 24 Mar 2015 08:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 9udDYpYrP74A for ; Tue, 24 Mar 2015 08:06:59 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 034311A87DF for ; Tue, 24 Mar 2015 08:06:50 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so149443642obd.3 for ; Tue, 24 Mar 2015 08:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ChmJLsUHgL9PhM5S6KCmm+y5pdWvL8elc6KmyflneIQ=; b=TuCFyOB7mzr8K5FAI6FF/6WhMR5UMlsvv4a2sNrCcTt12K4rbwVAfOjqqS46KZo4kr TCjQ0diT24Bb7pymM3aekezyRAIgZ6UGwnakPtKvIaP/u8s7Lgx1UGRL5a5dY3YjOQKl 0YOtpn6KYLceEnnvOlDV/8SWnQu74ONZgSdU0= 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:content-type; bh=ChmJLsUHgL9PhM5S6KCmm+y5pdWvL8elc6KmyflneIQ=; b=nAOGVHEXTMTEd0P1YvZN0ek5SDDqZG9IX+hbwvLioFlrXdtrAbfY+k0MLozQ7+OBLY 4QeC8byc6JinhZkkOnV9Cr9gN/Ch1qcNLrEGAFjZh2+b9noqg+J+00uiagek8gwa5y68 tPnAcOtCpY8MlhdSBvjcUA7J8y3/tpNMqX4t4NfXUnov9kMEjcvOJtir3QIIgCHuapTf LO5A1JR7fG7OsxDsuv5+gZ+HTvDUvRQBqlWAIk3HcIuywLCGo/FcYLfGBlE0m7VriBpW 50STJLixebt3xe2nLxw/J1089bqDm5U964mUuRsJkwHpV+GTCiWU1N5M+xYzedBJWYyr 5G9A== X-Gm-Message-State: ALoCoQkT+9QYLtnvEgmmxEO4ROmheXcm6PnYMFGPwuNUmRN8Db6yMO+sq0AKuXja5zIWWqsyZjXR MIME-Version: 1.0 X-Received: by 10.202.205.146 with SMTP id d140mr3401134oig.35.1427209609502; Tue, 24 Mar 2015 08:06:49 -0700 (PDT) Received: by 10.76.150.2 with HTTP; Tue, 24 Mar 2015 08:06:49 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Tue, 24 Mar 2015 10:06:49 -0500 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a1134e69acb802105120a2161 Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 15:07:01 -0000 --001a1134e69acb802105120a2161 Content-Type: text/plain; charset=UTF-8 On the other hand, I would be disappointed if such a consensus were to emerge. It would mean that we would never be able to sunset IPv4, and as an endpoint software developer, if every host I want to deploy on has a CLAT provided by the system, then I'd observe that my incentives to stop writing IPv4-only software logic would evaporate for all practical purposes. I expect my opposition would be trammeled by bulldozers, but I would oppose. On Tue, Mar 24, 2015 at 9:13 AM, Lorenzo Colitti wrote: > On Tue, Mar 24, 2015 at 9:11 AM, Ca By wrote: >> >> Oh, I see why you started this thread now. Do you expect that the IETF >>> would be able to reach consensus on such a statement? >>> >> >> Yes. Are you in opposition? >> > > Oh, of course not. I'm the maintainer of a popular 464xlat implementation, > remember? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- james woodyatt Nest Labs, Communications Engineering --001a1134e69acb802105120a2161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the other hand, I would be disappointed if such a conse= nsus were to emerge. It would mean that we would never be able to sunset IP= v4, and as an endpoint software developer, if every host I want to deploy o= n has a CLAT provided by the system, then I'd observe that my incentive= s to stop writing IPv4-only software logic would evaporate for all practica= l purposes.

I expect my opposition would be trammeled by= bulldozers, but I would oppose.

=
On Tue, Mar 24, 2015 at 9:13 AM, Lorenzo Colitti= <lorenzo@google.com> wrote:
= On Tue, Mar 24, 2015 at 9:11 AM, Ca By &= lt;cb.list6@gmail.c= om> wrote:
Oh, I see why you started this thread now. Do you exp= ect that the IETF would be able to reach consensus on such a statement?

Yes. Are y= ou in opposition?

Oh, of cours= e not. I'm the maintainer of a popular 464xlat implementation, remember= ?

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




--
james woodyatt <jhw@nestlabs.com>
Nest Lab= s, Communications Engineering
--001a1134e69acb802105120a2161-- From nobody Tue Mar 24 08:26:48 2015 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 97BC71A88E2 for ; Tue, 24 Mar 2015 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 skO-ZsD6C6C3 for ; Tue, 24 Mar 2015 08:26:46 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 C1CBA1A88CE for ; Tue, 24 Mar 2015 08:26:27 -0700 (PDT) Received: by igbud6 with SMTP id ud6so75048305igb.1 for ; Tue, 24 Mar 2015 08:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nJMftVOdVU1FPL0qGSFxq4snJPeiYotfux/VPZFoY+U=; b=X3s83Db/ZkWrr6aP5HrB2+pgNipntv/qpneNdZG3acJbWIh4gjoVBuebnnFSldJsMo NbtaUYwggQqx3i8ExrrleF/sUxAarclrntnBn2ywgkxzov9WMJjJeMWsOsYucRvgAodr NnP5Hn3Ce2xJNsxtvWl957HLL1k9il0l5b261ESg/b09ByiSdczlsWEoM/1A/dKkfpL8 FIgCYAwToP/rrQbgEzbIfQKzRN7FmbNDgPS51om4ZHnsGnhtKuZhMa2rpGndC+ZFg7VO JaDXFfzrCtL8ugN6RJyYcuAWAqH+PSFkIOtpH2eIYEvj2rjUIADSQqiEGupNdFZmM92G 0bdA== 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-type; bh=nJMftVOdVU1FPL0qGSFxq4snJPeiYotfux/VPZFoY+U=; b=fT1o4cGP38Z3TgyU5dznXDYDYdsPhCma0b88Go/e/xHNh7xpED10RmhTXT4d7+mJoP 7Q6gDsoKCGRCaR4s0UfHlffhGIjdBdukutRILrjyUa5M5h6Up0dgmWVNcdkOioyy2Mvz 1MqIOsV1DLY+tXTb6pMNjrnYLR0GGc/qGRLhRlvNxBu3u2oMa0JKcpBjeF4Kl0cC7wBN iYW7KBb72mae+arXK0qxhpGhz8qOwm+K0o73rkhX3K5ceL28bSwq8PF3adYhQ8c+ZlTH hd0N+g2tN4Xrt26vivLElq9j8sOk6Bdj7azk9PZxKVTKh8nMkqli0G7/RToPAA9G+LJs j83Q== X-Gm-Message-State: ALoCoQmG8gcm+NBj6zEEVhRabyp8zRLN8SXLJsBFDxB6gpXbDunCk38rEMpKUzQUe4FHFOCdfQok X-Received: by 10.107.166.11 with SMTP id p11mr7284191ioe.30.1427210787162; Tue, 24 Mar 2015 08:26:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Tue, 24 Mar 2015 08:26:07 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> From: Lorenzo Colitti Date: Tue, 24 Mar 2015 10:26:07 -0500 Message-ID: To: James Woodyatt Content-Type: multipart/alternative; boundary=001a1141f104fd2cbc05120a6733 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 15:26:47 -0000 --001a1141f104fd2cbc05120a6733 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 10:06 AM, James Woodyatt wrote: > as an endpoint software developer, if every host I want to deploy on has a > CLAT provided by the system, then I'd observe that my incentives to stop > writing IPv4-only software logic would evaporate for all practical purposes. > I'm not sure that's true. We have four scenarios, in order of decreasing incentives (from 100% to 0%) to write IPv4-only code: 1. IPv4-only device 2. Dual-stack device (native IPv6 and NAT44 or NAT444) 3. IPv6-only device with "compatibility quality" IPv4 (e.g., 464xlat). 4. IPv6-only device Based on personal experience, I know that #3 provides less incentives to write IPv4-only code than #2. I've heard developers say multiple times, "Double NAT and 464xlat? (i.e., #3.) Man, that sounds pretty flaky, and high latency too. What do I need to do to fix my code to support IPv6?" In contrast, #2 is seen as, "well, we still have IPv4 right? So we can just continue to use it. You say IPv6 has no NAT? But we deal with NAT today, and it works fine..." I think the real discussion here is whether going from #2 to #4 without passing through #3 is possible at all. If you believe that it's possible, then #2 makes sense. If you believe it's not possible, then the only thing that makes sense is to do #3 ASAP. I don't believe that going from #2 to #4 is possible for the industry. It may be possible for a tightly-controlled, substantial subset of the industry (e.g., Apple) to do it, but if we did not have a substantial part of the industry doing #3 already, we'd likely get stuck. #3 does provide strong advantages over #2 to operators; in some networks, #2 doesn't actually fix anything because the problem is private IPv4 address exhaustion. For those networks, the only options are #1 or #3 - which is why those networks are doing 464xlat. --001a1141f104fd2cbc05120a6733 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 24, 2015 at 10:06 AM, James Woodyatt <jhw@nestlabs.com> wrote:
as an endpoin= t software developer, if every host I want to deploy on has a CLAT provided= by the system, then I'd observe that my incentives to stop writing IPv= 4-only software logic would evaporate for all practical purposes.

I'm not sure that's true. We have four= scenarios, in order of decreasing incentives (from 100% to 0%) to write IP= v4-only code:
  1. IPv4-only device
  2. Dual-stack dev= ice (native IPv6 and NAT44 or NAT444)
  3. IPv6-only device with "c= ompatibility quality" IPv4 (e.g., 464xlat).
  4. IPv6-only device
Based on personal experience, I know that #3 provides le= ss incentives to write IPv4-only code than #2. I've heard developers sa= y multiple times, "Double NAT and 464xlat? (i.e., #3.) Man, that sound= s pretty flaky, and high latency too. What do I need to do to fix my code t= o support IPv6?" In contrast, #2 is seen as, "well, we still have= IPv4 right? So we can just continue to use it. You say IPv6 has no NAT? Bu= t we deal with NAT today, and it works fine..."

I think the real discussion here is whether going from #2 to #4 with= out passing through #3 is possible at all. If you believe that it's pos= sible, then #2 makes sense. If you believe it's not possible, then the = only thing that makes sense is to do #3 ASAP.

I do= n't believe that going from #2 to #4 is possible for the industry. It m= ay be possible for a tightly-controlled, substantial subset of the industry= (e.g., Apple) to do it, but if we did not have a substantial part of the i= ndustry doing #3 already, we'd likely get stuck.=C2=A0

#3 does provide strong advantages over #2 to operators; in some ne= tworks, #2 doesn't actually fix anything because the problem is private= IPv4 address exhaustion. For those networks, the only options are #1 or #3= - which is why those networks are doing 464xlat.
--001a1141f104fd2cbc05120a6733-- From nobody Tue Mar 24 08:47:49 2015 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 82E271A892F for ; Tue, 24 Mar 2015 08:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 xeaBh-Xtq1Fz for ; Tue, 24 Mar 2015 08:47:44 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 4F0731A8908 for ; Tue, 24 Mar 2015 08:47:44 -0700 (PDT) Received: by wibg7 with SMTP id g7so78380528wib.1 for ; Tue, 24 Mar 2015 08:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PKcJ3zalV9g3bQbu6QmlMTjtIFcVnUiQplCoERkqImc=; b=Nf3car9knClm7GWQ88yx2j7YOsELc5EFeEJsLODOc/gZ4IrWhd0fjD+o+rw5hSpMay R8MyfNPqu/6T6OFyytVQqpDSxO8rWNOkEYrsXWRBP1qnMspzYUwkGixO3uizy7ijjXws xfaKUvVEMlmC8SB2rtj4CJKV80AYw5ypFe9BXsYHP03hXh2wZYXyiu5RJm57Ou++9Ydr oboIZObu4HJlddmWnfb1USMh62aVVUIVz20N4r3JHpBn6RloqwjwLX7oM2UvOxY5HfnN Ih6t+AE31c6SHKrxDQvvZDvYMuWx6I/MmSWYWkC70ZM/jsW0gY3HFVZG6tgIYlQfDOOb CWKg== MIME-Version: 1.0 X-Received: by 10.180.206.83 with SMTP id lm19mr29891697wic.41.1427212063058; Tue, 24 Mar 2015 08:47:43 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Tue, 24 Mar 2015 08:47:42 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Tue, 24 Mar 2015 08:47:42 -0700 Message-ID: From: Ca By To: James Woodyatt Content-Type: multipart/alternative; boundary=001a11c26b7809b19505120ab4ba Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 15:47:46 -0000 --001a11c26b7809b19505120ab4ba Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 8:06 AM, James Woodyatt wrote: > On the other hand, I would be disappointed if such a consensus were to > emerge. It would mean that we would never be able to sunset IPv4, and as an > endpoint software developer, if every host I want to deploy on has a CLAT > provided by the system, then I'd observe that my incentives to stop writing > IPv4-only software logic would evaporate for all practical purposes. > > I expect my opposition would be trammeled by bulldozers, but I would > oppose. > Rev'ing up the bulldozer (puffs of smoke fill the air) I agree with your principles, and i believed in them too at one point, but i became painfully aware that this view is grossly misaligned with reality. Once abandoning this view and accepting that i cannot boil the IPv4 ocean, i experienced a great deal of internal peace as i took control of my internet numbering destiny. As we know, in mobile, there are 3 dominate operating systems. Each and everyone of them ships with fundamental software -- core functionality -- that cannot operate without IPv4 sockets. Beyond the IPv4 dependent software that ships on a clean build, the apps stores are littered with IPv4 dependencies -- in top 100 apps. The typical number in the app store is 20% of the top 100 fail on IPv6 + NAT64/DNS64, recently re-verified by myself. Even if these amazingly-wealthy talent-stuffed software factories were able to clean up their own ipv4-dependent software, and painfully thrust standards on 3rd party app makers, they cannot clean up the world wide web (as noted in the first message of the thread). They cannot clean up enterprise VPNs. And no, no ISP / Mobile provider is willing to accept 1% of the web breaking (including Alexa top 100 web pages) while their competitors deliver 100% of the web. Shorter Cameron: Failure to deploy a proper IPv6-only solution to the host is creating real and meaningful harm to IPv6 deployment at large. The network that i work at has hit a ceiling on IPv6 deployment due to a single major host operating system lacking this basic functionality (Windows Phone and Android support 464XLAT, deployed to 10s of millions of users who have never heard of IPv4). IPv4 dependence is hurting the internet and allows for middle-box proliferation. So, perhaps a BCP from the IETF would make it clear what is best and what is not-best. CB > > On Tue, Mar 24, 2015 at 9:13 AM, Lorenzo Colitti > wrote: > >> On Tue, Mar 24, 2015 at 9:11 AM, Ca By wrote: >>> >>> Oh, I see why you started this thread now. Do you expect that the IETF >>>> would be able to reach consensus on such a statement? >>>> >>> >>> Yes. Are you in opposition? >>> >> >> Oh, of course not. I'm the maintainer of a popular 464xlat >> implementation, remember? >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > -- > james woodyatt > Nest Labs, Communications Engineering > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c26b7809b19505120ab4ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 24, 2015 at 8:06 AM, James Woodyatt <<= a href=3D"mailto:jhw@nestlabs.com" target=3D"_blank">jhw@nestlabs.com&g= t; wrote:
On the = other hand, I would be disappointed if such a consensus were to emerge. It = would mean that we would never be able to sunset IPv4, and as an endpoint s= oftware developer, if every host I want to deploy on has a CLAT provided by= the system, then I'd observe that my incentives to stop writing IPv4-o= nly software logic would evaporate for all practical purposes.

I expect my opposition would be trammeled by bulldozers, but I would= oppose.

Rev'ing up the bul= ldozer (puffs of smoke fill the air)

I agree with = your principles, and i believed in them too at one point, but i became pain= fully aware that this view is grossly misaligned with reality.=C2=A0 Once a= bandoning this view and accepting that i cannot boil the IPv4 ocean, i expe= rienced a great deal of internal peace as i took control of my internet num= bering destiny.=C2=A0

As we know, in mobile, there= are 3 dominate operating systems.=C2=A0 Each and everyone of them ships wi= th fundamental software -- core functionality -- that cannot operate withou= t IPv4 sockets.=C2=A0 Beyond the IPv4 dependent software that ships on a cl= ean build, the apps stores are littered with IPv4 dependencies -- in top 10= 0 apps.=C2=A0 The typical number in the app store is 20% of the top 100 fai= l on IPv6 + NAT64/DNS64, recently re-verified by myself.

Even if these amazingly-wealthy talent-stuffed software factories we= re able to clean up their own ipv4-dependent software, and painfully thrust= standards on 3rd party app makers, they cannot clean up the world wide web= (as noted in the first message of the thread).=C2=A0 They cannot clean up = enterprise VPNs.=C2=A0

And no, no ISP / Mobile pro= vider is willing to accept 1% of the web breaking =C2=A0(including Alexa to= p 100 web pages) while their competitors deliver 100% of the web.=C2=A0

Shorter Cameron: =C2=A0Failure to deploy a proper IPv= 6-only solution to the host is creating real and meaningful harm to IPv6 de= ployment at large.=C2=A0 The network that i work at has hit a ceiling on IP= v6 deployment due to a single major host operating system lacking this basi= c functionality (Windows Phone and Android support 464XLAT, deployed to 10s= of millions of users who have never heard of IPv4).=C2=A0

IPv4 dependence is hurting the internet and allows for middle-box = proliferation.=C2=A0

So, perhaps a BCP from the IE= TF would make it clear what is best and what is not-best.=C2=A0
<= br>
CB
=C2=A0

On Tue, Mar = 24, 2015 at 9:13 AM, Lorenzo Colitti <lorenzo@google.com> w= rote:
On Tue, Mar= 24, 2015 at 9:11 AM, Ca By <cb.list6@gmail.com> wrote:
Oh, I = see why you started this thread now. Do you expect that the IETF would be a= ble to reach consensus on such a statement?

Yes. Are you in opposition?

Oh, of course not. I'm the maintaine= r of a popular 464xlat implementation, remember?

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




--
james woodyatt <jhw@nestlabs.com>=
Nest Labs, Communications Engineering

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


--001a11c26b7809b19505120ab4ba-- From nobody Tue Mar 24 09:24:33 2015 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 3FBDF1A88A9 for ; Tue, 24 Mar 2015 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 ZP86Fo4fx3b6 for ; Tue, 24 Mar 2015 09:24:25 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c: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 DAABE1A6F3F for ; Tue, 24 Mar 2015 09:24:24 -0700 (PDT) Received: by wetk59 with SMTP id k59so167709673wet.3 for ; Tue, 24 Mar 2015 09:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mJDpzp6W2CCzM1jotJeldmc+XMClAbKNA8E7Pl7yS1k=; b=FLbOdRnSxE+IB0e57+dBZ6USK1ecW/oESFGFhTA52O4VbigmI5uSWhQU0aWvWX7hPv iMOYwtBK04Xa2bomGh78f2VWtT+FvCzRB1jaVs7FSmNGpGDiev8tYYr2s+jvH7vCSrXm lmv6Fd3e4RLH7PcKzhYQkfc504bHnu6w4XxAHSPWgOFfq5hRsqNW3dG2sd1UJGeQqC3g VW/QVgGLc2+lUggqtW8yEtYjV9N3mAhbNUXEPwi2yg7qQmk1A5Wa55kwoxn/P78NGe4J YfL6PXOIl7DXmkxqM5AgchN/OKtZryFWt2f1/8p4HIa8X9kaPrNFCFmxlHecDcZ6+cuv uQJA== X-Received: by 10.180.218.73 with SMTP id pe9mr16342638wic.79.1427214263108; Tue, 24 Mar 2015 09:24:23 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ha10sm6745840wjc.37.2015.03.24.09.24.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 09:24:22 -0700 (PDT) Message-ID: <55118FBB.4080205@gmail.com> Date: Wed, 25 Mar 2015 05:24:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Lorenzo Colitti , James Woodyatt References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 16:24:31 -0000 On 25/03/2015 04:26, Lorenzo Colitti wrote: > On Tue, Mar 24, 2015 at 10:06 AM, James Woodyatt wrote: > >> as an endpoint software developer, if every host I want to deploy on has a >> CLAT provided by the system, then I'd observe that my incentives to stop >> writing IPv4-only software logic would evaporate for all practical purposes. >> > > I'm not sure that's true. We have four scenarios, in order of decreasing > incentives (from 100% to 0%) to write IPv4-only code: > > 1. IPv4-only device > 2. Dual-stack device (native IPv6 and NAT44 or NAT444) > 3. IPv6-only device with "compatibility quality" IPv4 (e.g., 464xlat). > 4. IPv6-only device > > Based on personal experience, I know that #3 provides less incentives to > write IPv4-only code than #2. I've heard developers say multiple times, > "Double NAT and 464xlat? (i.e., #3.) Man, that sounds pretty flaky, and > high latency too. What do I need to do to fix my code to support IPv6?" I think this is important. The biggest problem that I see is how to incent smaller content providers (smaller than Google and Facebook, I mean) that it is in their own interest to support native IPv6. If they perceive IPv4 as becoming a second-class service for millions of users, that might push them in the right direction. #3 is useful in that context. Brian > In > contrast, #2 is seen as, "well, we still have IPv4 right? So we can just > continue to use it. You say IPv6 has no NAT? But we deal with NAT today, > and it works fine..." > > I think the real discussion here is whether going from #2 to #4 without > passing through #3 is possible at all. If you believe that it's possible, > then #2 makes sense. If you believe it's not possible, then the only thing > that makes sense is to do #3 ASAP. > > I don't believe that going from #2 to #4 is possible for the industry. It > may be possible for a tightly-controlled, substantial subset of the > industry (e.g., Apple) to do it, but if we did not have a substantial part > of the industry doing #3 already, we'd likely get stuck. > > #3 does provide strong advantages over #2 to operators; in some networks, > #2 doesn't actually fix anything because the problem is private IPv4 > address exhaustion. For those networks, the only options are #1 or #3 - > which is why those networks are doing 464xlat. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Mar 24 11:17:56 2015 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 8A9891A6EFB for ; Tue, 24 Mar 2015 11:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 8K7XlpZyan9a for ; Tue, 24 Mar 2015 11:17:47 -0700 (PDT) Received: from tor-smtp-01.primus.ca (mail23.primus.ca [216.254.141.190]) by ietfa.amsl.com (Postfix) with ESMTP id 90B101A028A for ; Tue, 24 Mar 2015 11:17:47 -0700 (PDT) Received: from dhcp-b24b.meeting.ietf.org ([31.133.178.75]) by tor-smtp-01.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1YaTOc-0001wc-Ij; Tue, 24 Mar 2015 14:17:46 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <55117731.6010806@jvknet.com> Date: Tue, 24 Mar 2015 14:17:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38427ACD-CCA6-4C5F-9AE2-192BD1CA1C0C@magma.ca> References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> <75B6FA9F576969419E42BECB86CB1B891682EBEA@xmb-rcd-x06.cisco.com> <5510ACBD.2040109@gmail.com> <5510BEBD.2030507@jvknet.com> <55117731.6010806@jvknet.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - dhcp-b24b.meeting.ietf.org [31.133.178.75] Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 24 Mar 2015 18:17:55 -0000 Just a heads up to everyone that Victor and I have a presentation slot = tomorrow for the Design Choices draft, and we plan to have a discussion = on what term the WG would like us to use here. Philip On 2015-03-24, at 10:39 , Victor Kuarsingh wrote: >=20 >=20 > On 2015-03-24 9:52 AM, Metzler, Dan J wrote: >> Hi, >>=20 >> See below: >>=20 >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor = Kuarsingh >>> Sent: Monday, March 23, 2015 8:33 PM >>> To: Alexandru Petrescu; v6ops@ietf.org >>> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >>>=20 >>> All, >>>=20 >>> What's one more email in such an active conversation. Here area few = points >>> to take note of. >>>=20 >>> - When I suggested "administratively unnumbered", I was intending to = find >>> text which has less imposed (vs just "unnumbered") meaning while = attempting >>> to keep within the spirit of the text in section 2.1.2. >> I sort of understand where you're coming from, but I think the = addition of "administratively" just modified the confusion, but did not = remove it. >> I think you're trying to equate the situation to something in IPv4 to = make it seem more familiar. In the short term that might have some = benefit, but in the long term it seems to lose meaning. >> I think the term "unnumbered" is what introduces the confusion, = simply because it is different with IPv6. > I totally understand the differences between IPv4 and IPv6. You are = right in a way, in that there are some parallels between IPv4 and IPv6 = being drawn (since some parallels still exist, as well as differences). >=20 > I guess the parallel component is the action the administrator (some = may call this the sysadmin, or the network admin - all the same to me - = the person or tool configuring stuff) takes. The result is where one of = the differences are between IPv4 and IPv6. >>> - The intention of this text was to describe the configuration = choices for links >>> within a network, which was to apply a ULA/GUA or to not apply a = ULA/GUA >>> (in which case the LL address would be the only one that remains). >> If you are using "administratively unnumbered" in any way that is not = intended to confuse the issue, then I think you can't assume that LL is = the only one that remains. With IPv6, that just means you're leaving it = up to the network operator vs the system admin. > Maybe I missed something here, but we are specifically talking about = the network operator / system admin (the subject of the conversation is = the actions the person designing (and/or configuration) the network = makes. >=20 >> It might be ULA. It might be GUA. It might be LL. > I think this is true and I think this is clear in the text as well. >> It depends on what's in the flags in the RA. > This is true, and using an RA to get a ULA/GUA onto an interface (vs. = manual configuration) is just a way to do it (I don't think our draft = discusses or recommends on how to accomplish the addressing. >=20 > We point documents like RFC4852 which expand on the methods on how to = address stuff (as an example). >> If that's really what you meant then the assumption that LL address = is the only one that remains is simply a flawed assumption, but = "Administratively Unnumbered" becomes closer to a reasonable term, other = than the fact that "unnumbered" is technically inaccurate. (And that's = probably what people find most confusing.) > I think we are all open to new terms, but that would likely become = subject to further misconceptions unless well defined. I guess the = "adminstatively" part of hte term was to denote "something you do to = give it an address". >=20 >> If you really meant LL-only, then "Administratively Unnumbered" is = probably not the best term because it doesn't really describe what you = meant. >>=20 >> (Do you see how it gets confusing?) > Well I do understand people's point, irrespective if I agree. To be = honest, I am not confused, and when reading the text (as I had noted = before) I don't think folks who would seek guidance in such a draft = would come away not understanding what the options are, or what the = result will be. >=20 > I do agree, that out of context, it can be considered confusing, but I = am not considering the use of the word out of context. >=20 >>> - The action in the one case (by the administrator) would be to not = apply >>> addressing (additional) to a link, in which case the result is = LL-only. >> What do you mean by "administrator"? (System admin or network admin = or both) > The term administrator was to apply to anyone who managers/configures = network (was to cover all cases). A sysadmin and netadmin are just = types of administrators. >=20 > Victor K >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Mar 24 15:22:23 2015 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 F174A1A1B5C for ; Tue, 24 Mar 2015 15:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 T3s3esKVhvAh for ; Tue, 24 Mar 2015 15:22:20 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 8F9931A1B57 for ; Tue, 24 Mar 2015 15:22:20 -0700 (PDT) Received: by oigv203 with SMTP id v203so6489040oig.3 for ; Tue, 24 Mar 2015 15:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AHDE6MYWvNxoETni1XZDYTdYWkK5iI6ufnuOSB3pPT8=; b=Ok6wz0zmav6qE0f5ms+cvsLrzyls3EVsGKlocraAR3EClNWMUUGfn3G6xKsb/hZbYE sZrX8lTJq1BFgdFh2wNV5xsWB8+xHBF1IrYdkQ2CzTnxmB7vvLA07XkD8oBKjjbsgUdg l+xMLQx3jme0Qfq5DWajc36H9Rf1ARKqJojC0= 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-type; bh=AHDE6MYWvNxoETni1XZDYTdYWkK5iI6ufnuOSB3pPT8=; b=FXNpi4CRSgOI/h3YAVwymas3gwiY9ZzWU5aEpFgV/UtN6YtYpTT1h6PEJC88AbTz/L APwbS4TRBSADAvSlDNcoZ0DXE38P1HxeZaeeZgZEx2vbDT/h2uiXjyITvDas5Ubw7B9X yz2Ofz8gufkTcaRTPy45QOE3xBIIS2xsHIp2aR5LltNnZS6Rrsb+cgZGVuwpibCoBMIu mOeWxZEp+c0T6S5yzSjCML0C8hIloq9g0K+/q9EMd9e7D+VKhpsj1YJKXG5JTvTCxjg/ 8RuOhKQizWqJYpAp5aSMxYy1ui6IxyBXJoWir5jS8qFDTxJrcf2Gz9k3oWspgxg9+88c OxoA== X-Gm-Message-State: ALoCoQnUkgRi+eGc0gRIpaWvu6D965hE+XWSARPeteCjhfffYePEZcL+cEEf52VGvLPad10rAzYD MIME-Version: 1.0 X-Received: by 10.182.215.133 with SMTP id oi5mr5018386obc.55.1427235740092; Tue, 24 Mar 2015 15:22:20 -0700 (PDT) Received: by 10.76.150.2 with HTTP; Tue, 24 Mar 2015 15:22:19 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Tue, 24 Mar 2015 17:22:19 -0500 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11c254344ca3f10512103792 Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 24 Mar 2015 22:22:22 -0000 --001a11c254344ca3f10512103792 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cameron, Lorenzo=E2=80=94 Lorenzo writes, "I think the real discussion here is whether going from #2 [IPv6 + IPv4/NAT] to #4 [IPv6-ONLY] without passing through #3 [IPv6 + 464XLAT] is possible at all. If you believe that it's possible, then #2 makes sense. If you believe it's not possible, then the only thing that makes sense is to do #3 ASAP." My reply: "I don't agree with that characterization of the discussion. A very large faction of the Internet community remains convinced to this day that IPv6-ONLY is neither necessary nor even desirable. I'm partially sympathetic=E2=80=94 I see it as desirable in the long term, absolutely, bu= t I recognize that I don't yet have convincing arguments that it's strictly necessary, much less necessary to get there this decade. If IPv6-ONLY is desirable but not actually necessary, as many people still believe, then the discussion is about whether IPv6-ONLY is more or less desirable than IPv6 + IPv4/NAT. Can we honestly say we know which of those outcomes is better? I can't." Cameron writes, "IPv4 dependence is hurting the internet and allows for middle-box proliferation." My reply: "I agree that IPv4 dependency is hurting the Internet, but I also view 464XLAT as a scheme to prolong the viability of IPv4-only software. I also don't agree that IPv4 dependence is any more permissive of middlebox proliferation than IPv6 is permissive of it. From my view, it looks like IPv6 is at least as permissive as IPv4 and probably more permissive because the prevalence of NAT in IPv4 makes some middlebox functions more difficult to deploy. Shorter james. This middlebox comment smells all kinds of wrong to me." Cameron also writes, "So, perhaps a BCP from the IETF would make it clear what is best and what is not-best." My reply: "It might make 'somewhat less unclear' what IETF thinks is best vs. non best. I believe it would make very clear that IETF thinks developing software that depends on IPv4-ONLY programming interfaces is a best CURRENT practice, which would make it much more difficult=E2=80=94 at = a critical juncture in the transition to IPv6=E2=80=94 to communicate to deve= lopers that adopting IPv6-aware programming interfaces is important, and I would feel compelled to object to that." --=20 james woodyatt Nest Labs, Communications Engineering --001a11c254344ca3f10512103792 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cameron, Lorenzo=E2=80=94

Lorenzo write= s, "I think the real disc= ussion here is whether going from #2 [IPv6 + IPv4/NAT] to #4 [IPv6-ONLY] wi= thout passing through #3 [IPv6 + 464XLAT] is possible at all. If you believ= e that it's possible, then #2 makes sense. If you believe it's not = possible, then the only thing that makes sense is to do #3 ASAP.&quo= t;

My reply: "I don't agree with that cha= racterization of the discussion. A very large faction of the Internet commu= nity remains convinced to this day that IPv6-ONLY is neither necessary nor = even desirable. I'm partially sympathetic=E2=80=94 I see it as desirabl= e in the long term, absolutely, but I recognize that I don't yet have c= onvincing arguments that it's strictly necessary, much less necessary t= o get there this decade. If IPv6-ONLY is desirable but not actually necessa= ry, as many people still believe, then the discussion is about whether IPv6= -ONLY is more or less desirable than IPv6 + IPv4/NAT. Can we honestly say w= e know which of those outcomes is better? I can't."

Cameron writes, &quo= t;IPv4 dependence is hurting the internet and allows for middle-box prolife= ration."

My reply: "I agree that IPv4 dependency is hurting the Int= ernet, but I also view 464XLAT as a scheme to prolong the viability of IPv4= -only software. I also don't agree that IPv4 dependence is any more per= missive of middlebox proliferation than IPv6 is permissive of it. From my v= iew, it looks like IPv6 is at least as permissive as IPv4 and probably more= permissive because the prevalence of NAT in IPv4 makes some middlebox func= tions more difficult to deploy. Shorter james. This middlebox comment smell= s all kinds of wrong to me."

=
Cameron also writes, "So, perhaps a BCP from the IETF would= make it clear what is best and what is not-best."

My reply: "It might make 'somewhat less unclear' what IE= TF thinks is best vs. non best. I believe it would make very clear that IET= F thinks developing software that depends on IPv4-ONLY programming interfac= es is a best CURRENT practice, which would make it much more difficult=E2= =80=94 at a critical juncture in the transition to IPv6=E2=80=94 to communi= cate to developers that adopting IPv6-aware programming interfaces is impor= tant, and I would feel compelled to object to that."


--
james woodyatt <jhw@nestlabs.com>Nest Labs, Communications Engineering

--001a11c254344ca3f10512103792-- From nobody Wed Mar 25 00:08:29 2015 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 CAA3E1ACDA8 for ; Wed, 25 Mar 2015 00:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 W1hU2wbHAKpp for ; Wed, 25 Mar 2015 00:08:26 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A6F1ACDD8 for ; Wed, 25 Mar 2015 00:08:21 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=42446 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YafQJ-00061u-BT; Wed, 25 Mar 2015 08:08:19 +0100 Date: Wed, 25 Mar 2015 08:07:47 +0100 From: Tore Anderson To: Ca By Message-ID: <20150325080747.2d80884d@echo.ms.redpill-linpro.com> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 25 Mar 2015 07:08:28 -0000 * Ca By > The point of this message is to discuss the use of IPv4 literals and > how this use requires transition solutions such as MAP, DS-Lite, and > 464XLAT -- all of which provide local IPv4 socket support to the > host. If the primary operating environment of the host is the > "internet", and the "web" is a highly valuable part of the that > operating environment, then local IPv4 socket support is still > required. Hi Cameron, You - and anyone else that cares about this topic - might want to read draft-anderson-v6ops-siit-eam-03 and send any comments or feedback you might have to the list. Keep in mind that 464XLAT is not a formal standard, but rather the description of a use case that at least in some deployment models (e.g., 3GPP networks) requires a non-standard building block, in particular an SIIT implementation that can work with non-IPv4-translatable IPv6 addresses. https://tools.ietf.org/html/draft-anderson-v6ops-siit-eam The purpose of the the siit-eam draft is to formally add the missing funtionality to RFC 6145, so that we can ask vendors to =C2=ABplease implement this standard=C2=BB. If they do so, they will have not only provided the basic building block that is necessary to implement 464XLAT's CLAT component, but also something that can be used for other similar transition solutions (SIIT-DC comes to mind). I'll present the siit-eam draft in the v6ops session tomorrow, and intend to ask for WG adoption. I'm hoping your hum will be heard loud and clear all the way to here in Norway. (Through Meetecho, that is.) Yes, this message is a shameless plug. My apologies. Tore From nobody Wed Mar 25 02:40:33 2015 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 427971A07BC for ; Wed, 25 Mar 2015 02:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.036 X-Spam-Level: * X-Spam-Status: No, score=1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 F6RSXRYGZZQj for ; Wed, 25 Mar 2015 02:40:30 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50EEC1A8947 for ; Wed, 25 Mar 2015 02:40:29 -0700 (PDT) Received: from 10.236.62.153 (EHLO OPE10HT05.tp.gk.corp.tepenet) ([10.236.62.153]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DIC64504; Wed, 25 Mar 2015 10:40:21 +0100 (CET) From: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= To: Lorenzo Colitti , James Woodyatt Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AQHQYot+JPbEs9uqwESBzZsi6hPKXZ0ky1EAgAB1XQCAADeeAIADZ0CAgAFS5oCAAVsLAIAAFWiAgAAAioCAAA8EgIAABWSAgAFCEqA= Date: Wed, 25 Mar 2015 09:39:37 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745FB5905@OPE10MB05.tp.gk.corp.tepenet> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.13.107.45] Content-Type: multipart/alternative; boundary="_000_2D29C51862222E49B991EF64EEB0B5B745FB5905OPE10MB05tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.3.25.90028:17:8.129, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __STOCK_PHRASE_7, __SUBJ_ALPHA_NEGATE, __C230066_P5, SUPERLONG_LINE, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __RATWARE_SIGNATURE_3_N1, __URI_NS, HTML_50_70, WEBMAIL_SOURCE, REFERENCES X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0201.55128285.021A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0201.55128285.021A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2eca9daec65e3c3c3a1d95939e6b4202 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 25 Mar 2015 09:40:32 -0000 --_000_2D29C51862222E49B991EF64EEB0B5B745FB5905OPE10MB05tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KQlIsDQpNY3oNCg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IFR1ZXNkYXksIE1hcmNo IDI0LCAyMDE1IDQ6MjYgUE0NClRvOiBKYW1lcyBXb29keWF0dA0KQ2M6IElQdjYgT3BzIFdHDQpT dWJqZWN0OiBSZTogW3Y2b3BzXSBUaGUgbmVlZCBmb3IgbG9jYWwtaXB2NCBzb2NrZXQgdHJhbnNp dGlvbiBzb2x1dGlvbnMgLS0gTkFUNjQvRE5TNjQgcmVtYWlucyBpbnN1ZmZpY2llbnQNCg0KT24g VHVlLCBNYXIgMjQsIDIwMTUgYXQgMTA6MDYgQU0sIEphbWVzIFdvb2R5YXR0IDxqaHdAbmVzdGxh YnMuY29tPG1haWx0bzpqaHdAbmVzdGxhYnMuY29tPj4gd3JvdGU6DQphcyBhbiBlbmRwb2ludCBz b2Z0d2FyZSBkZXZlbG9wZXIsIGlmIGV2ZXJ5IGhvc3QgSSB3YW50IHRvIGRlcGxveSBvbiBoYXMg YSBDTEFUIHByb3ZpZGVkIGJ5IHRoZSBzeXN0ZW0sIHRoZW4gSSdkIG9ic2VydmUgdGhhdCBteSBp bmNlbnRpdmVzIHRvIHN0b3Agd3JpdGluZyBJUHY0LW9ubHkgc29mdHdhcmUgbG9naWMgd291bGQg ZXZhcG9yYXRlIGZvciBhbGwgcHJhY3RpY2FsIHB1cnBvc2VzLg0KDQpJJ20gbm90IHN1cmUgdGhh dCdzIHRydWUuIFdlIGhhdmUgZm91ciBzY2VuYXJpb3MsIGluIG9yZGVyIG9mIGRlY3JlYXNpbmcg aW5jZW50aXZlcyAoZnJvbSAxMDAlIHRvIDAlKSB0byB3cml0ZSBJUHY0LW9ubHkgY29kZToNCg0K ICAxLiAgSVB2NC1vbmx5IGRldmljZQ0KICAyLiAgRHVhbC1zdGFjayBkZXZpY2UgKG5hdGl2ZSBJ UHY2IGFuZCBOQVQ0NCBvciBOQVQ0NDQpDQogIDMuICBJUHY2LW9ubHkgZGV2aWNlIHdpdGggImNv bXBhdGliaWxpdHkgcXVhbGl0eSIgSVB2NCAoZS5nLiwgNDY0eGxhdCkuDQogIDQuICBJUHY2LW9u bHkgZGV2aWNlDQpCYXNlZCBvbiBwZXJzb25hbCBleHBlcmllbmNlLCBJIGtub3cgdGhhdCAjMyBw cm92aWRlcyBsZXNzIGluY2VudGl2ZXMgdG8gd3JpdGUgSVB2NC1vbmx5IGNvZGUgdGhhbiAjMi4g SSd2ZSBoZWFyZCBkZXZlbG9wZXJzIHNheSBtdWx0aXBsZSB0aW1lcywgIkRvdWJsZSBOQVQgYW5k IDQ2NHhsYXQ/IChpLmUuLCAjMy4pIE1hbiwgdGhhdCBzb3VuZHMgcHJldHR5IGZsYWt5LCBhbmQg aGlnaCBsYXRlbmN5IHRvby4gV2hhdCBkbyBJIG5lZWQgdG8gZG8gdG8gZml4IG15IGNvZGUgdG8g c3VwcG9ydCBJUHY2PyIgSW4gY29udHJhc3QsICMyIGlzIHNlZW4gYXMsICJ3ZWxsLCB3ZSBzdGls bCBoYXZlIElQdjQgcmlnaHQ/IFNvIHdlIGNhbiBqdXN0IGNvbnRpbnVlIHRvIHVzZSBpdC4gWW91 IHNheSBJUHY2IGhhcyBubyBOQVQ/IEJ1dCB3ZSBkZWFsIHdpdGggTkFUIHRvZGF5LCBhbmQgaXQg d29ya3MgZmluZS4uLiINCg0KSSB0aGluayB0aGUgcmVhbCBkaXNjdXNzaW9uIGhlcmUgaXMgd2hl dGhlciBnb2luZyBmcm9tICMyIHRvICM0IHdpdGhvdXQgcGFzc2luZyB0aHJvdWdoICMzIGlzIHBv c3NpYmxlIGF0IGFsbC4gSWYgeW91IGJlbGlldmUgdGhhdCBpdCdzIHBvc3NpYmxlLCB0aGVuICMy IG1ha2VzIHNlbnNlLiBJZiB5b3UgYmVsaWV2ZSBpdCdzIG5vdCBwb3NzaWJsZSwgdGhlbiB0aGUg b25seSB0aGluZyB0aGF0IG1ha2VzIHNlbnNlIGlzIHRvIGRvICMzIEFTQVAuDQoNCkkgZG9uJ3Qg YmVsaWV2ZSB0aGF0IGdvaW5nIGZyb20gIzIgdG8gIzQgaXMgcG9zc2libGUgZm9yIHRoZSBpbmR1 c3RyeS4gSXQgbWF5IGJlIHBvc3NpYmxlIGZvciBhIHRpZ2h0bHktY29udHJvbGxlZCwgc3Vic3Rh bnRpYWwgc3Vic2V0IG9mIHRoZSBpbmR1c3RyeSAoZS5nLiwgQXBwbGUpIHRvIGRvIGl0LCBidXQg aWYgd2UgZGlkIG5vdCBoYXZlIGEgc3Vic3RhbnRpYWwgcGFydCBvZiB0aGUgaW5kdXN0cnkgZG9p bmcgIzMgYWxyZWFkeSwgd2UnZCBsaWtlbHkgZ2V0IHN0dWNrLg0KDQojMyBkb2VzIHByb3ZpZGUg c3Ryb25nIGFkdmFudGFnZXMgb3ZlciAjMiB0byBvcGVyYXRvcnM7IGluIHNvbWUgbmV0d29ya3Ms ICMyIGRvZXNuJ3QgYWN0dWFsbHkgZml4IGFueXRoaW5nIGJlY2F1c2UgdGhlIHByb2JsZW0gaXMg cHJpdmF0ZSBJUHY0IGFkZHJlc3MgZXhoYXVzdGlvbi4gRm9yIHRob3NlIG5ldHdvcmtzLCB0aGUg b25seSBvcHRpb25zIGFyZSAjMSBvciAjMyAtIHdoaWNoIGlzIHdoeSB0aG9zZSBuZXR3b3JrcyBh cmUgZG9pbmcgNDY0eGxhdC4NCg== --_000_2D29C51862222E49B991EF64EEB0B5B745FB5905OPE10MB05tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5TdHlsd2lhZG9tb2NpZS1tYWlsMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uVGVrc3RkeW1rYVpuYWsNCgl7bXNvLXN0eWxlLW5hbWU6IlRla3N0 IGR5bWthIFpuYWsiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi VGVrc3QgZHlta2EiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpQTDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY4NTY2OTkxMDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTEwMzUwMzU4MjQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iUEwiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m IzQzOzEmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk1jejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5M b3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMjQsIDIwMTUg NDoyNiBQTTxicj4NCjxiPlRvOjwvYj4gSmFtZXMgV29vZHlhdHQ8YnI+DQo8Yj5DYzo8L2I+IElQ djYgT3BzIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIFRoZSBuZWVkIGZvciBs b2NhbC1pcHY0IHNvY2tldCB0cmFuc2l0aW9uIHNvbHV0aW9ucyAtLSBOQVQ2NC9ETlM2NCByZW1h aW5zIGluc3VmZmljaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciAyNCwgMjAx NSBhdCAxMDowNiBBTSwgSmFtZXMgV29vZHlhdHQgJmx0OzxhIGhyZWY9Im1haWx0bzpqaHdAbmVz dGxhYnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+amh3QG5lc3RsYWJzLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFzIGFuIGVuZHBv aW50IHNvZnR3YXJlIGRldmVsb3BlciwgaWYgZXZlcnkgaG9zdCBJIHdhbnQgdG8gZGVwbG95IG9u IGhhcyBhIENMQVQgcHJvdmlkZWQgYnkgdGhlIHN5c3RlbSwgdGhlbiBJJ2Qgb2JzZXJ2ZSB0aGF0 IG15IGluY2VudGl2ZXMgdG8gc3RvcCB3cml0aW5nIElQdjQtb25seSBzb2Z0d2FyZSBsb2dpYyB3 b3VsZCBldmFwb3JhdGUgZm9yIGFsbCBwcmFjdGljYWwgcHVycG9zZXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3Qgc3VyZSB0aGF0 J3MgdHJ1ZS4gV2UgaGF2ZSBmb3VyIHNjZW5hcmlvcywgaW4gb3JkZXIgb2YgZGVjcmVhc2luZyBp bmNlbnRpdmVzIChmcm9tIDEwMCUgdG8gMCUpIHRvIHdyaXRlIElQdjQtb25seSBjb2RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSVB2NC1vbmx5IGRl dmljZTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCkR1YWwtc3RhY2sgZGV2aWNlIChuYXRpdmUgSVB2NiBhbmQgTkFUNDQgb3Ig TkFUNDQ0KTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCklQdjYtb25seSBkZXZpY2Ugd2l0aCAmcXVvdDtjb21wYXRpYmlsaXR5 IHF1YWxpdHkmcXVvdDsgSVB2NCAoZS5nLiwgNDY0eGxhdCkuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSVB2Ni1vbmx5IGRl dmljZTxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmFzZWQgb24gcGVyc29uYWwgZXhwZXJpZW5jZSwgSSBrbm93IHRoYXQgIzMgcHJvdmlk ZXMgbGVzcyBpbmNlbnRpdmVzIHRvIHdyaXRlIElQdjQtb25seSBjb2RlIHRoYW4gIzIuIEkndmUg aGVhcmQgZGV2ZWxvcGVycyBzYXkgbXVsdGlwbGUgdGltZXMsICZxdW90O0RvdWJsZSBOQVQgYW5k IDQ2NHhsYXQ/IChpLmUuLCAjMy4pIE1hbiwgdGhhdCBzb3VuZHMgcHJldHR5IGZsYWt5LCBhbmQg aGlnaCBsYXRlbmN5IHRvby4gV2hhdA0KIGRvIEkgbmVlZCB0byBkbyB0byBmaXggbXkgY29kZSB0 byBzdXBwb3J0IElQdjY/JnF1b3Q7IEluIGNvbnRyYXN0LCAjMiBpcyBzZWVuIGFzLCAmcXVvdDt3 ZWxsLCB3ZSBzdGlsbCBoYXZlIElQdjQgcmlnaHQ/IFNvIHdlIGNhbiBqdXN0IGNvbnRpbnVlIHRv IHVzZSBpdC4gWW91IHNheSBJUHY2IGhhcyBubyBOQVQ/IEJ1dCB3ZSBkZWFsIHdpdGggTkFUIHRv ZGF5LCBhbmQgaXQgd29ya3MgZmluZS4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSByZWFsIGRpc2N1c3Npb24g aGVyZSBpcyB3aGV0aGVyIGdvaW5nIGZyb20gIzIgdG8gIzQgd2l0aG91dCBwYXNzaW5nIHRocm91 Z2ggIzMgaXMgcG9zc2libGUgYXQgYWxsLiBJZiB5b3UgYmVsaWV2ZSB0aGF0IGl0J3MgcG9zc2li bGUsIHRoZW4gIzIgbWFrZXMgc2Vuc2UuIElmIHlvdSBiZWxpZXZlIGl0J3Mgbm90IHBvc3NpYmxl LCB0aGVuIHRoZSBvbmx5IHRoaW5nIHRoYXQgbWFrZXMgc2Vuc2UNCiBpcyB0byBkbyAjMyBBU0FQ LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGRvbid0IGJlbGlldmUgdGhhdCBnb2luZyBmcm9tICMyIHRvICM0IGlzIHBvc3NpYmxlIGZvciB0 aGUgaW5kdXN0cnkuIEl0IG1heSBiZSBwb3NzaWJsZSBmb3IgYSB0aWdodGx5LWNvbnRyb2xsZWQs IHN1YnN0YW50aWFsIHN1YnNldCBvZiB0aGUgaW5kdXN0cnkgKGUuZy4sIEFwcGxlKSB0byBkbyBp dCwgYnV0IGlmIHdlIGRpZCBub3QgaGF2ZSBhIHN1YnN0YW50aWFsIHBhcnQgb2YgdGhlIGluZHVz dHJ5IGRvaW5nDQogIzMgYWxyZWFkeSwgd2UnZCBsaWtlbHkgZ2V0IHN0dWNrLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jMyBkb2Vz IHByb3ZpZGUgc3Ryb25nIGFkdmFudGFnZXMgb3ZlciAjMiB0byBvcGVyYXRvcnM7IGluIHNvbWUg bmV0d29ya3MsICMyIGRvZXNuJ3QgYWN0dWFsbHkgZml4IGFueXRoaW5nIGJlY2F1c2UgdGhlIHBy b2JsZW0gaXMgcHJpdmF0ZSBJUHY0IGFkZHJlc3MgZXhoYXVzdGlvbi4gRm9yIHRob3NlIG5ldHdv cmtzLCB0aGUgb25seSBvcHRpb25zIGFyZSAjMSBvciAjMyAtIHdoaWNoIGlzIHdoeSB0aG9zZSBu ZXR3b3Jrcw0KIGFyZSBkb2luZyA0NjR4bGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D29C51862222E49B991EF64EEB0B5B745FB5905OPE10MB05tpgkco_-- From nobody Wed Mar 25 10:08:29 2015 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 62A361A879C for ; Wed, 25 Mar 2015 10:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 PpHv39sINg_g for ; Wed, 25 Mar 2015 10:08:25 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E81F61A1A75 for ; Wed, 25 Mar 2015 10:08:24 -0700 (PDT) Received: from delong-dhcp214.delong.com (delong-dhcp14 [192.159.10.214]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2PH7QEp031362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2015 10:07:26 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2PH7QEp031362 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1427303246; bh=s3C6p2zQ0Z8UBJCubLvFAhQaxgc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=5AbMDaTZiO4oOKr5HEv/aveniaDSBBKJEuH4nJnC8vwCXikAPN6f+3ad8KLxu7K2J xPPaw3qPAfxib4RR2J4BdhV3UIHYdYCYV5gV4a4em/NZeT1QMNukI+6jLv4lpsv9l0 5sYJ0gmhVoa49w4++3aK3d0iCETF5KijINFyTsaQ= Content-Type: multipart/alternative; boundary="Apple-Mail=_8D603F3D-69BF-49CA-B26A-A770B42ADDD5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Owen DeLong In-Reply-To: <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 25 Mar 2015 10:07:25 -0700 Message-Id: <72037C9E-B718-4177-96D9-603B17B3DB96@delong.com> References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 25 Mar 2015 10:07:26 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 25 Mar 2015 17:08:27 -0000 --Apple-Mail=_8D603F3D-69BF-49CA-B26A-A770B42ADDD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 I dislike administratively unnumbered for the reasons stated. Owen > On Mar 23, 2015, at 16:07 , Mark ZZZ Smith = wrote: >=20 > I still think 'link-local only' is better, as it is very explicitly = saying what the addressing scheme is. There is no and cannot be any = ambiguity.=20 >=20 > I think 'administratively unnumbered' is close to the inverse of that = and less descriptive and specific. >=20 >=20 >=20 >=20 >=20 > From: Victor Kuarsingh > To: v6ops@ietf.org=20 > Sent: Monday, 23 March 2015, 23:23 > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >=20 > Eric/All, >=20 > What about the term "administratively unnumbered?" This could be=20 > defined as an interface where the network administrator did not=20 > specifically number the interface, but does not preclude it from = having=20 > an address at all (i.e. LL address). >=20 > regards, >=20 > Victor K >=20 >=20 >=20 > On 2015-03-10 5:15 PM, Eric Vyncke (evyncke) wrote: > > Philip > > > > In the legacy world of IPv4, unnumbered actually means using a = global IPv4 > > address 'stolen' from another interface. > > > > In the current world of IPv6, every interface has at least a = link-local > > address which can be used for IGP and other purposes (see RFC 7404) = which > > is NOT equivalent (IMHO) to 'unnumbered interface' > > > > So, I am afraid that you should use another working (albeit = cumbersome) > > > > -=C3=A9ric > > > > On 10/03/15 15:52, "Philip Matthews" > wrote: > > > >> Just want to get some direct feedback from the WG on the use of the = terms > >> "unnumbered interface" and "unnumbered link" in IPv6. > >> > >> Mark Smith, in some comments on the Design Choices draft , has said = that > >> he prefers the terms "interface with only link-local address" or = "link > >> with only link-local addresses" instead. See the thread with title = "I-D > >> Action: draft-ietf-v6ops-design-choices-04.txt". > >> > >> What does the WG think? Should we use the "unnumbered" terms, or = should > >> we use just the "... with only link-local address" terms? Is it > >> acceptable to mix the two sets of terms? > >> > >> Philip > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops = >=20 >=20 >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops = >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_8D603F3D-69BF-49CA-B26A-A770B42ADDD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

I = dislike administratively unnumbered for the reasons stated.

Owen

On Mar 23, 2015, at 16:07 , Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:

I still = think 'link-local only' is better, as it is very explicitly saying what = the addressing scheme is. There is no and cannot be any = ambiguity. 

I think = 'administratively unnumbered' is close to the inverse of that and less = descriptive and specific.





From: = Victor Kuarsingh <victor@jvknet.com>
To: v6ops@ietf.org
Sent: Monday, 23 March 2015, 23:23
= Subject: Re: [v6ops] Should we use "unnumbered" in = IPv6?

Eric/All,

What about the = term "administratively unnumbered?"  This could be
defined as an interface where the network administrator did = not
specifically number the interface, but = does not preclude it from having
an = address at all (i.e. LL address).

regards,

Victor K



On 2015-03-10 5:15 PM, Eric Vyncke (evyncke) wrote:
> Philip
>> In the legacy world of IPv4, unnumbered = actually means using a global IPv4
> = address 'stolen' from another interface.
>
> In the current world = of IPv6, every interface has at least a link-local
> address which can be used for IGP and other purposes = (see RFC 7404) which
> is NOT equivalent = (IMHO) to 'unnumbered interface'
>
> So, I am afraid that you should use = another working (albeit cumbersome)
>
> -=C3=A9ric
>
> On 10/03/15 15:52, = "Philip Matthews" <philip_matthews@magma.ca> wrote:
>
>> Just want to get = some direct feedback from the WG on the use of the terms
>> "unnumbered interface" and "unnumbered link" in = IPv6.
>>
>> Mark Smith, in some comments on the Design Choices = draft , has said that
>> he prefers = the terms "interface with only link-local address" or "link
>> with only link-local addresses" = instead.  See the thread with title "I-D
>> Action: draft-ietf-v6ops-design-choices-04.txt".
>>
>> = What does the WG think?  Should we use the "unnumbered" terms, or = should
>> we use just the "... with = only link-local address" terms?  Is it
>> acceptable to mix the two sets of terms?
>>
>> = Philip
>>
>>
>> = _______________________________________________
>> 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

= --Apple-Mail=_8D603F3D-69BF-49CA-B26A-A770B42ADDD5-- From nobody Wed Mar 25 10:23:27 2015 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 7949D1A9059 for ; Wed, 25 Mar 2015 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 F80Z01g4Y3Gu for ; Wed, 25 Mar 2015 10:23:22 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c: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 671061A8989 for ; Wed, 25 Mar 2015 10:23:22 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so35201346wgb.0 for ; Wed, 25 Mar 2015 10:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dVTlZ1opiqazGXzsyV5gVyg7t/e5LdDujGmFzJmJ2Q=; b=HArPoy+Zkv577StapFy2KYHa0O4zdUvT5f9BRPzZ+60TDbLkz8O9w+Oa/CkQKoar3H N/i2xr+J4ioSWYqR2sTReHfRKwMt2MQrWaWrve7eVB0LeRqhKmo18/OG4q8MtUt2W6lj 3kT6PFtFzzNxVir0cgX+b1oGUomWiAFbKJP44Mwv/TmHW0QyjYmkewcKV6BHFwOOu6jc yED2NKjYQT4dWT6nyeRpQwW80FcULpXQi8jKwl+vx96HCHzqijxzL1r38fwVgOAF9Z4W 55giIGSbqpBAKOXhcJ+yp5Q+JGqTOARENq3hrW/1N3h7E8VaMLEW+FsQDYNh3Fzgk8w+ C/pA== MIME-Version: 1.0 X-Received: by 10.194.19.10 with SMTP id a10mr20217136wje.153.1427304201085; Wed, 25 Mar 2015 10:23:21 -0700 (PDT) Received: by 10.194.69.71 with HTTP; Wed, 25 Mar 2015 10:23:20 -0700 (PDT) Received: by 10.194.69.71 with HTTP; Wed, 25 Mar 2015 10:23:20 -0700 (PDT) In-Reply-To: <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 25 Mar 2015 18:23:20 +0100 Message-ID: From: Richard Hartmann To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=047d7b5d4808e46a49051220274a Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 25 Mar 2015 17:23:25 -0000 --047d7b5d4808e46a49051220274a Content-Type: text/plain; charset=UTF-8 I don't want to bikeshed, but as this is not dying down: Please consider everything Mark said in this thread +1 by me. Until I pipe up, this is a standing +1 for everything he will say. Lurking, Richard Sent by mobile; excuse my brevity. --047d7b5d4808e46a49051220274a Content-Type: text/html; charset=UTF-8

I don't want to bikeshed, but as this is not dying down:

Please consider everything Mark said in this thread +1 by me.

Until I pipe up, this is a standing +1 for everything he will say.

Lurking,
Richard

Sent by mobile; excuse my brevity.

--047d7b5d4808e46a49051220274a-- From nobody Wed Mar 25 10:39:29 2015 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 AE7961A90C0 for ; Wed, 25 Mar 2015 10:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 8gBsfIzyOZas for ; Wed, 25 Mar 2015 10:39:26 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.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 D7C7A1A8A03 for ; Wed, 25 Mar 2015 10:39:26 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 8C23DDA0160; Wed, 25 Mar 2015 17:39:25 +0000 (UTC) Received: from [IPv6:2001:67c:1231:998:59fc:1802:aa5c:57ae] (31.130.238.113) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 Mar 2015 10:39:20 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Wed, 25 Mar 2015 12:39:17 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <7C4156C8-E48E-4243-AFBD-1CC2DB8C10DB@nominum.com> References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> To: Richard Hartmann X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.113] Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 25 Mar 2015 17:39:27 -0000 On Mar 25, 2015, at 12:23 PM, Richard Hartmann = wrote: > I don't want to bikeshed, but as this is not dying down: > Please consider everything Mark said in this thread +1 by me. > Until I pipe up, this is a standing +1 for everything he will say. So you are saying that Mark should be considered to have two votes? :) From nobody Wed Mar 25 12:17:56 2015 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 EDF101B2A2A for ; Wed, 25 Mar 2015 12:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 70CNf6WPy6YT for ; Wed, 25 Mar 2015 12:17:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7A51ABD38 for ; Wed, 25 Mar 2015 12:17:53 -0700 (PDT) Received: from dhcp-b22f.meeting.ietf.org ([31.133.178.47]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MfVYB-1YpVEy10Yd-00P9WX for ; Wed, 25 Mar 2015 20:17:51 +0100 From: Ian Farrer Content-Type: multipart/alternative; boundary="Apple-Mail=_4A951F40-D85D-457A-BB33-808B7B91A972" Message-Id: Date: Wed, 25 Mar 2015 14:17:49 -0500 To: v6ops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Provags-ID: V03:K0:l3KkhokPt/ubiwrSGYzqm2K+94zjh0mFPJeWaS1DRK4s5Aov38F DbUbbe3r8RO3qCp1KcQXj3MNaDyAYnuIGk7y05wbfLPkkH4B4G2el5plphw+ymUk2bQM8/M 0cHE5FANk/3s6pc8aPcmoAIrHZAj0LUR6d2V6vG2AgXqSWYzh/+tjNeTPTfjxqgb2yzz2wL fc4AANqASgJNKnu8+54Mg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [v6ops] Existing work on Softwire Deployment Experiences 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, 25 Mar 2015 19:17:55 -0000 --Apple-Mail=_4A951F40-D85D-457A-BB33-808B7B91A972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, As mentioned at the mike in today=E2=80=99s session, Softwire has = already produced a couple of drafts on deployment experience: draft-ietf-softwire-map-deployment draft-liu-softwire-lw4over6-dhcp-deployment It would be good to get any input to these from the operators who = presented their implementations today. Cheers, Ian --Apple-Mail=_4A951F40-D85D-457A-BB33-808B7B91A972 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

As = mentioned at the mike in today=E2=80=99s session, Softwire has already = produced a couple of drafts on deployment experience:

draft-ietf-softwire-map-deployment
draft-liu-softwire-lw4over6-dhcp-deployment

It =
would be good to get any input to these from the operators who presented =
their implementations today.

Cheers,
Ian

= --Apple-Mail=_4A951F40-D85D-457A-BB33-808B7B91A972-- From nobody Wed Mar 25 13:48:31 2015 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 ED09F1A895E for ; Wed, 25 Mar 2015 13:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, 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 sgKRxYgvjjxj for ; Wed, 25 Mar 2015 13:48:29 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 B93061A0058 for ; Wed, 25 Mar 2015 13:48:28 -0700 (PDT) Received: by wibg7 with SMTP id g7so124442781wib.1 for ; Wed, 25 Mar 2015 13:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cSk99gGcAtTwA2cB7KqdOWmuGnZ4OlxxzC/X7f+UkmQ=; b=ZGgX45qvwJZNvHVoK3H1nVVTT03gEJLiGS1SdlDm8zAUitErp9R0O867EAQeo22oVY MtJSTLy4aj/j7bnxKZYXZyV4nm1nBtz5LQkVI6Mr6wRhNpSPTwJmDdqSBznM6ks+wKJC /mymUyiA2AwVzHG8vG2yWiHwq3LadHGgOMPvnTfEI6jsBvNv19PwcAs1skdHd1rQk3WL mzd8irorxI2UlnCgSzBFnbHkoi+kw3ejO0gDj/ZZJjOKD12QIFLF9a/t4cJfXnXOGVM+ RWhco1axzJSQCT9rNGCPq04NDseY34H7miV7j+tJY58R2Duyx4a40HsE4NAlOTgbFnpc T4UQ== MIME-Version: 1.0 X-Received: by 10.194.87.100 with SMTP id w4mr20909040wjz.65.1427316507579; Wed, 25 Mar 2015 13:48:27 -0700 (PDT) Received: by 10.194.69.71 with HTTP; Wed, 25 Mar 2015 13:48:27 -0700 (PDT) Received: by 10.194.69.71 with HTTP; Wed, 25 Mar 2015 13:48:27 -0700 (PDT) In-Reply-To: <7C4156C8-E48E-4243-AFBD-1CC2DB8C10DB@nominum.com> References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> <7C4156C8-E48E-4243-AFBD-1CC2DB8C10DB@nominum.com> Date: Wed, 25 Mar 2015 21:48:27 +0100 Message-ID: From: Richard Hartmann To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bf10a166a9c1a051223055c Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 25 Mar 2015 20:48:30 -0000 --047d7bf10a166a9c1a051223055c Content-Type: text/plain; charset=UTF-8 On Mar 25, 2015 6:39 PM, "Ted Lemon" wrote: > So you are saying that Mark should be considered to have two votes? May he hum louder. Richard Sent by mobile; excuse my brevity. --047d7bf10a166a9c1a051223055c Content-Type: text/html; charset=UTF-8

On Mar 25, 2015 6:39 PM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

> So you are saying that Mark should be considered to have two votes?

May he hum louder.

Richard

Sent by mobile; excuse my brevity.

--047d7bf10a166a9c1a051223055c-- From nobody Wed Mar 25 13:54:31 2015 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 BB6251B2C02 for ; Wed, 25 Mar 2015 13:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 CW6IPOO3zHRS for ; Wed, 25 Mar 2015 13:54:23 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.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 4556E1B2BDB for ; Wed, 25 Mar 2015 13:54:18 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 3B949DA015D; Wed, 25 Mar 2015 20:54:18 +0000 (UTC) Received: from [IPv6:2001:67c:1231:998:c192:7ada:1d2d:643f] (31.130.238.161) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 Mar 2015 13:54:17 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Wed, 25 Mar 2015 15:54:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <551005BD.40501@jvknet.com> <2089269939.25823.1427152027428.JavaMail.yahoo@mail.yahoo.com> <7C4156C8-E48E-4243-AFBD-1CC2DB8C10DB@nominum.com> To: Richard Hartmann X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.161] Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 25 Mar 2015 20:54:29 -0000 On Mar 25, 2015, at 3:48 PM, Richard Hartmann = wrote: > May he hum louder. That's actually specifically discussed in RFC 7282! :) From nobody Wed Mar 25 16:48:58 2015 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 3079C1A87F1 for ; Wed, 25 Mar 2015 16:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 LAuGGoL9Wuxz for ; Wed, 25 Mar 2015 16:48:54 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934761A6F7B for ; Wed, 25 Mar 2015 16:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2010; q=dns/txt; s=iport; t=1427327334; x=1428536934; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=IoZP7ieBg00fqZMgMEQ79WAEMO6lzNWg/o7tNi3JYbY=; b=O/23mcYdyVbrJSlgFRDbjA1j2HTj3Bta03MzuGXt6dHsf9nksAiL58Ea DLepjrWw9AVsTiobBgVKo7xy9PwsqcZnRSV1Pkzzl0EWhYOl2miCcVUc1 mZ2kxY1NXkRwBgqJ4PNnd0qWbcP/wF6XyV+dpS2RVfIogsO6cH/A+1Dva o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DnBACkSBNV/5FdJa1cgwNSWsNDgVGFc4FdOBQBAQEBAQEBfIRVNAuBPieIGw3KIAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkBaDHoEWBYULhgeIXE+Ff4EbgzCCOIlfg0cihAwgMQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.11,468,1422921600"; d="scan'208";a="135348472" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP; 25 Mar 2015 23:48:53 +0000 Received: from [10.89.11.3] ([10.89.11.3]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2PNmqEg027240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2015 23:48:53 GMT From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2015 18:48:51 -0500 Message-Id: To: IPv6 Ops WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: v6ops-ads@tools.ietf.org, V6ops Chairs , softwire-chairs@tools.ietf.org, sunset4-ads@tools.ietf.org, sunset4-chairs@tools.ietf.org Subject: [v6ops] Discussion: IPv4 as a Service 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, 25 Mar 2015 23:48:56 -0000 Lee and I opened a discussion in the v6ops meeting today on a topic that = I believe that the IETF, in cooperation with the *NOGs, needs to = address. My slide is at = https://www.ietf.org/proceedings/92/slides/slides-92-v6ops-9.pptx. = Sunset4 and softwire chairs, please feel free to forward this to your = mailing lists. In short, we are starting to see the deployment of IPv6-only networks. = In most cases, these are existing IPv4 networks that have become dual = stack, and are somewhere in the process of shutting IPv4 down. These = include Facebook, which (regardless of whether you view it as an = enterprise or a content network) has been public about the fact, several = mobile networks that treat IPv6-capable telephones as an IPv6-only = network and use 464xlat as an operational methodology dealing with that, = and some research networks, notably CERNET2, which has been running = IPv6-only for ten years now. We also see green-field networks, such as = Reliance JIO Infocomm Ltd; Suprita Sah presented on that topic today. I am of the opinion, and there seemed to be agreement in the room, that = the Internet community would be well served if we collected deployment = experience with these technologies, and the considered advice of = deploying operators. We have tried to guide the deployment of IPv6, and = gathered experience and mitigations for that. Now, as IPv4 begins to = fade, we need to take a leadership role in that. I have opened a document on Google Docs, and given folks the ability to = view it. That is at = https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwoUWdz6psyEb4= 56c3A. I have included an initial list of relevant technologies, and an = initial list of the questions that we would want discussed in experience = documents. I guarantee that there is an important question not asked, = and while I hope otherwise, there may be some technology I have = overlooked. So I invite discussion to flesh out that initial phase. From nobody Wed Mar 25 17:08:04 2015 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 1601F1ACCE7 for ; Wed, 25 Mar 2015 17:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 B5qS8JXTNH6U for ; Wed, 25 Mar 2015 17:08:02 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 F030E1A00B7 for ; Wed, 25 Mar 2015 17:08:01 -0700 (PDT) Received: by igcau2 with SMTP id au2so116246504igc.0 for ; Wed, 25 Mar 2015 17:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Lbk8olHAbILXHh4g4j4sLQFxjVM+u1BSwewJv6jL6/A=; b=t8YogXx4veLCC+npYSZBZXSOmRpy+MQaeRP57o7nXHCNM1/EXerLL1VMY6cuy/dDGE cCuieTHLnsoGkMyaWYYmhLcvzImTUlyU8Y/GCx7fFJzsuq3LKBGvxTs5ZZWQ82evb0iS uHW5XL7TAqU2T+HfjgWT8WWRQOKBaUF+CP95lEeWEVWfIJuPIJwF70rjW3t+PM+6givL 64wkY0geClnI9ZYQ/z11imMmikM3FwL2uRCGisl6WcgzyxQsfTygeInu0lrmYgvo1c7v 2o04qk7T+I4WP8C/lQfVbbXx19Ta7JfOYWn2MWmnsgsRuoVjbLoCQSZjBjoEnE2uVq1d sbdw== MIME-Version: 1.0 X-Received: by 10.42.216.67 with SMTP id hh3mr30123980icb.46.1427328481432; Wed, 25 Mar 2015 17:08:01 -0700 (PDT) Received: by 10.107.7.95 with HTTP; Wed, 25 Mar 2015 17:08:00 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Thu, 26 Mar 2015 01:08:00 +0100 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: James Woodyatt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 00:08:03 -0000 On 3/24/15, James Woodyatt wrote: > Cameron, Lorenzo=E2=80=94 > Cameron writes, "IPv4 dependence is hurting the internet and allows for > middle-box proliferation." > > My reply: "I agree that IPv4 dependency is hurting the Internet, but I al= so > view 464XLAT as a scheme to prolong the viability of IPv4-only software. One of more reliable ways to drive the IPv4-only software sunset would be to emit a compiler warning whenever the static analyzer discovers an AF_INET socket being made. This warning would come with a corresponding developer page explaining why AF_INET is the new strcpy(), and give the correct examples of how to implement the dualstack networking correctly. But even absent the compiler magic, I would like you to consider the following logic: 1) One can say "dualstack" access network promotes IPv4-only apps stronger than "IPv6+CLAT" access network. 2) Universal availability of CLAT would allow the percentage of "IPv6+CLAT" networks to increase, because now a network can just flip from IPv4-only to IPv6-only+CLAT at little or no cost. 3) This would increase the overall share of IPv6 while decreasing the share of IPv4 *at the same time* 4) This will increase the attractiveness of using AF_INET6. What do you think ? --a From nobody Wed Mar 25 18:21:58 2015 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 8C8E91ACDD5 for ; Wed, 25 Mar 2015 18:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 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, HTML_MESSAGE=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 0bIWAmfEc0ia for ; Wed, 25 Mar 2015 18:21:55 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450: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 783241A1B76 for ; Wed, 25 Mar 2015 18:21:54 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so46283965wib.0 for ; Wed, 25 Mar 2015 18:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ydsb6LDCe9L7WgSZThh1rbZUOX1BdSL/jx710SMtt50=; b=er66dnRFzg1h1zo7CuW8yG8yUJA58VFtxeyvy/9MWg4g1Ypd4TjRA1iTi6CZMhaINY LtWCzd6FbryMx4I/XVzbQ2HpuWkjh5CAhs3PR3AgV5RyoIKBMYEqMSiW4r1WRk0iw+0R mgmDwQGSunp0KHxLCB6hXUmG1CbkG6VBzzptyN/qsLhjl5nx9cYVbxyQa7kJvDGPgEeC ANDzEgMDRDkG+ESx77B7OHJjgctGhYzCRawRGbjSUfipq9ggnKwuWnJL7JMr9dVWOCkZ OZGFd9Q2xSIqcMFxJoO42YF1TrHEN7s0puRFcKLipR+/xpKe/H0WLqmmFvThBWao6//V Plhg== MIME-Version: 1.0 X-Received: by 10.194.77.230 with SMTP id v6mr23662881wjw.25.1427332913279; Wed, 25 Mar 2015 18:21:53 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Wed, 25 Mar 2015 18:21:53 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Wed, 25 Mar 2015 18:21:53 -0700 Message-ID: From: Ca By To: =?UTF-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= Content-Type: multipart/alternative; boundary=047d7bfd028c45baad051226d7e7 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 01:21:56 -0000 --047d7bfd028c45baad051226d7e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, March 25, 2015, Andrew =F0=9F=91=BD Yourtchenko wrote: > On 3/24/15, James Woodyatt > wrote: > > Cameron, Lorenzo=E2=80=94 > > > > Cameron writes, "IPv4 dependence is hurting the internet and allows for > > middle-box proliferation." > > > > My reply: "I agree that IPv4 dependency is hurting the Internet, but I > also > > view 464XLAT as a scheme to prolong the viability of IPv4-only software= . > > One of more reliable ways to drive the IPv4-only software sunset would > be to emit a compiler warning whenever the static analyzer discovers > an AF_INET socket being made. > > This warning would come with a corresponding developer page explaining > why AF_INET is the new strcpy(), and give the correct examples of how > to implement the dualstack networking correctly. > > But even absent the compiler magic, I would like you to consider the > following logic: > > 1) One can say "dualstack" access network promotes IPv4-only apps > stronger than "IPv6+CLAT" access network. > > 2) Universal availability of CLAT would allow the percentage of > "IPv6+CLAT" networks > to increase, because now a network can just flip from IPv4-only to > IPv6-only+CLAT at little or no cost. > > 3) This would increase the overall share of IPv6 while decreasing the > share of IPv4 *at the same time* > > 4) This will increase the attractiveness of using AF_INET6. > > What do you think ? > > --a > > That would be a nice step. But that is improbable and does not solve the non-zero number of websites in the Alexa 100 that have IPv4 literals in html / xml / js. It also does not solve the sip / xmpp issue of being completely littered with IPv4 referrals. See first post in this thread for the problem CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7bfd028c45baad051226d7e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, March 25, 2015, Andrew =F0=9F=91=BD Yourtchenko <= ayourtch@gmail.com> wrote:
=
On 3/24/15, James Woodyatt <jhw@nestlabs.com> wrote:
> Cameron, Lorenzo=E2=80=94


> Cameron writes, "IPv4 dependence is hurting the internet and allo= ws for
> middle-box proliferation."
>
> My reply: "I agree that IPv4 dependency is hurting the Internet, = but I also
> view 464XLAT as a scheme to prolong the viability of IPv4-only softwar= e.

One of more reliable ways to drive the IPv4-only software sunset would
be to emit a compiler warning whenever the static analyzer discovers
an AF_INET socket being made.

This warning would come with a corresponding developer page explaining
why AF_INET is the new strcpy(), and give the correct examples of how
to implement the dualstack networking correctly.

But even absent the compiler magic, I would like you to consider the
following logic:

1) One can say "dualstack" access network promotes IPv4-only apps=
stronger than "IPv6+CLAT" access network.

2) Universal availability of CLAT would allow the percentage of
"IPv6+CLAT" networks
to increase, because now a network can just flip from IPv4-only to
IPv6-only+CLAT at little or no cost.

3) This would increase the overall share of IPv6 while decreasing the
share of IPv4 *at the same time*

4) This will increase the attractiveness of using AF_INET6.

What do you think ?

--a



That would be a nice st= ep.=C2=A0

But that is improbable=C2=A0=C2=A0and=C2= =A0does not solve the=C2=A0non-zero number of websites in the Alexa 100 tha= t have IPv4 literals in html / xml / js.=C2=A0

It= =C2=A0also does not solve the sip / xmpp issue of being completely littered= with IPv4 referrals.=C2=A0

See first post in = this thread for the problem

CB
=C2=A0
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--047d7bfd028c45baad051226d7e7-- From nobody Wed Mar 25 20:46:10 2015 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 740121A7004 for ; Wed, 25 Mar 2015 20:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JU8-NSkBSMCF for ; Wed, 25 Mar 2015 20:46:07 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8438D1A7001 for ; Wed, 25 Mar 2015 20:46:06 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 5EEED1FCC87; Thu, 26 Mar 2015 03:46:03 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5852816005C; Thu, 26 Mar 2015 03:53:14 +0000 (UTC) Received: from rock.dv.isc.org (unknown [38.96.210.190]) by zmx1.isc.org (Postfix) with ESMTPSA id 30C48160042; Thu, 26 Mar 2015 03:53:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rock.dv.isc.org (Postfix) with ESMTP id 29A772C026D2; Thu, 26 Mar 2015 14:46:01 +1100 (EST) To: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= From: Mark Andrews References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-reply-to: Your message of "Thu, 26 Mar 2015 01:08:00 +0100." Date: Thu, 26 Mar 2015 14:46:01 +1100 Message-Id: <20150326034601.29A772C026D2@rock.dv.isc.org> Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 03:46:08 -0000 In message , =?UTF-8?B? QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= writes: > On 3/24/15, James Woodyatt wrote: > > Cameron, Lorenzo > > > > Cameron writes, "IPv4 dependence is hurting the internet and allows for > > middle-box proliferation." > > > > My reply: "I agree that IPv4 dependency is hurting the Internet, but I > also > > view 464XLAT as a scheme to prolong the viability of IPv4-only software. > > One of more reliable ways to drive the IPv4-only software sunset would > be to emit a compiler warning whenever the static analyzer discovers > an AF_INET socket being made. > > This warning would come with a corresponding developer page explaining > why AF_INET is the new strcpy(), and give the correct examples of how > to implement the dualstack networking correctly. > > But even absent the compiler magic, I would like you to consider the > following logic: > > 1) One can say "dualstack" access network promotes IPv4-only apps > stronger than "IPv6+CLAT" access network. > > 2) Universal availability of CLAT would allow the percentage of > "IPv6+CLAT" networks > to increase, because now a network can just flip from IPv4-only to > IPv6-only+CLAT at little or no cost. > > 3) This would increase the overall share of IPv6 while decreasing the > share of IPv4 *at the same time* > > 4) This will increase the attractiveness of using AF_INET6. > > What do you think ? #ifdef KERNEL #define AF_INET X #endif #define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG) > --a > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Mar 26 00:57:21 2015 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 7788A1A92DC for ; Thu, 26 Mar 2015 00:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 OgHGiAmHpjYF for ; Thu, 26 Mar 2015 00:57:19 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA561A8881 for ; Thu, 26 Mar 2015 00:57:19 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=53981 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Yb2fE-0000gq-Uk; Thu, 26 Mar 2015 08:57:16 +0100 Date: Thu, 26 Mar 2015 08:56:44 +0100 From: Tore Anderson To: Philip Matthews Message-ID: <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> In-Reply-To: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 07:57:20 -0000 * Philip Matthews > What does the WG think? Should we use the "unnumbered" terms, or > should we use just the "... with only link-local address" terms? Is > it acceptable to mix the two sets of terms? I didn't quite catch on the Meetecho if a final decision was reached yesterday, but in case not here's my suggestions: - Link-scoped (IPv6) interface vs - Global-scoped (IPv6) interface The global scope includes the link scope, so the latter wouldn't mean "no link local address". (Or maybe it's better to say "globally" and "scope", my English isn't good enough to know which of these nuances would be 100% correct.) Tore who finally succumbed to the bikeshedding temptation From nobody Thu Mar 26 05:04:05 2015 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 598711B2CA0 for ; Thu, 26 Mar 2015 05:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7qs_Y9Ih7lUu for ; Thu, 26 Mar 2015 05:03:57 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id E09201B2CA7 for ; Thu, 26 Mar 2015 05:03:54 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,471,1422939600"; d="scan'208";a="231492588" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Mar 2015 07:51:31 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 26 Mar 2015 08:03:53 -0400 From: "Howard, Lee" To: Tore Anderson , Philip Matthews Date: Thu, 26 Mar 2015 08:03:52 -0400 Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AdBnvO0R1t7IaijFSiGV/dEO+yqAUA== Message-ID: References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> In-Reply-To: <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 12:04:03 -0000 We seemed to have rough consensus on link-local-address-only. Lee On 3/26/15, 2:56 AM, "Tore Anderson" wrote: >* Philip Matthews > >> What does the WG think? Should we use the "unnumbered" terms, or >> should we use just the "... with only link-local address" terms? Is >> it acceptable to mix the two sets of terms? > >I didn't quite catch on the Meetecho if a final decision was reached >yesterday, but in case not here's my suggestions: > >- Link-scoped (IPv6) interface > >vs > >- Global-scoped (IPv6) interface > >The global scope includes the link scope, so the latter wouldn't mean >"no link local address". > >(Or maybe it's better to say "globally" and "scope", my English isn't >good enough to know which of these nuances would be 100% correct.) > >Tore >who finally succumbed to the bikeshedding temptation > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Thu Mar 26 05:28:21 2015 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 CEA7C1ACE4F for ; Thu, 26 Mar 2015 05:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] 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 pRVC8YPolr8N for ; Thu, 26 Mar 2015 05:28:17 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 188DF1B2CD2 for ; Thu, 26 Mar 2015 05:28:09 -0700 (PDT) Received: from [127.0.0.1] (unknown [31.133.182.70]) by centos (Coremail) with SMTP id AQAAf3BLAAP2+RNVHCEnAA--.2297S5; Thu, 26 Mar 2015 20:22:17 +0800 (CST) Message-ID: <5513FB51.3090309@cernet.edu.cn> Date: Thu, 26 Mar 2015 20:28:01 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ian Farrer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3BLAAP2+RNVHCEnAA--.2297S5 X-Coremail-Antispam: 1UD129KBjvdXoW7JFWUXr1UKr18AF15Jr17Awb_yoWxurg_AF WktF4kJr1Utr4jqF4Utr17trnrWrWDtr4UAryUJrsFvw17Aw1DJr4UtrWUZr1UXry8Jwnr Grn7Jr1ak3WUCjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb18YjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwA2z4x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwVC2z280aVCY1x0267AKxVW8JVW8Jr 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0 cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8Jw ACjcxG0xvEwIxGrwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I0E 7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcV C0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF 04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6x kF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU7GYLDUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Existing work on Softwire Deployment Experiences 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, 26 Mar 2015 12:28:20 -0000 Ian Farrer 写é“: > Hi, > > As mentioned at the mike in today’s session, Softwire has already > produced a couple of drafts on deployment experience: > > draft-ietf-softwire-map-deployment > draft-liu-softwire-lw4over6-dhcp-deployment and the one in my presentation. draft-xli-softwire-map-testing Regards, xing > It would be good to get any input to these from the operators who presented their implementations today. > > Cheers, > Ian > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 26 06:53:35 2015 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 0F1AC1A88D0 for ; Thu, 26 Mar 2015 06:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AOE3wOr-juDk for ; Thu, 26 Mar 2015 06:53:27 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D9B1ACEE3 for ; Thu, 26 Mar 2015 06:53:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2QDrQ3I015430; Thu, 26 Mar 2015 06:53:27 -0700 Received: from XCH-BLV-404.nw.nos.boeing.com (xch-blv-404.nw.nos.boeing.com [130.247.25.157]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2QDrPBr015402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 26 Mar 2015 06:53:25 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.24]) with mapi id 14.03.0210.002; Thu, 26 Mar 2015 06:53:25 -0700 From: "Templin, Fred L" To: "Howard, Lee" , Tore Anderson , Philip Matthews Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AQHQZ5qXF72S/g1H3EOcttGR86UKzZ0vH/0A//+om9A= Date: Thu, 26 Mar 2015 13:53:23 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 13:53:32 -0000 > We seemed to have rough consensus on link-local-address-only. The consensus alternative I recall seeing was "link-local-only" (three words separated by two dashes). Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee > Sent: Thursday, March 26, 2015 5:04 AM > To: Tore Anderson; Philip Matthews > Cc: v6ops list > Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >=20 > We seemed to have rough consensus on link-local-address-only. >=20 > Lee >=20 > On 3/26/15, 2:56 AM, "Tore Anderson" wrote: >=20 > >* Philip Matthews > > > >> What does the WG think? Should we use the "unnumbered" terms, or > >> should we use just the "... with only link-local address" terms? Is > >> it acceptable to mix the two sets of terms? > > > >I didn't quite catch on the Meetecho if a final decision was reached > >yesterday, but in case not here's my suggestions: > > > >- Link-scoped (IPv6) interface > > > >vs > > > >- Global-scoped (IPv6) interface > > > >The global scope includes the link scope, so the latter wouldn't mean > >"no link local address". > > > >(Or maybe it's better to say "globally" and "scope", my English isn't > >good enough to know which of these nuances would be 100% correct.) > > > >Tore > >who finally succumbed to the bikeshedding temptation > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is inten= ded solely for the use of the individual or entity to which it is > addressed. If you are not the intended recipient of this E-mail, you are = hereby notified that any dissemination, distribution, copying, > or action taken in relation to the contents of and attachments to this E-= mail is strictly prohibited and may be unlawful. If you have > received this E-mail in error, please notify the sender immediately and p= ermanently delete the original and any copy of this E-mail and > any printout. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Mar 26 07:37:58 2015 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 0B9A91A0110 for ; Thu, 26 Mar 2015 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 87mn9xn6P9B1 for ; Thu, 26 Mar 2015 07:37:46 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C660B1A014B for ; Thu, 26 Mar 2015 07:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3548; q=dns/txt; s=iport; t=1427380665; x=1428590265; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=R9riCjoqRIv+97mY8N9kBCahx+GFay7G5nmCMvhXowU=; b=hnYrI2J49Q1GgrxFS2y64nMXvf6Us+uTaByLBdXZ2cxleSeU4jsmtu0C qabmiKhI98co5qeWoEZczdSPIo4KBcEXHcZ5oxuKQQNvTXeLiE3XtLgnJ r74o61rRLVT36iQ6P6BuPSTtyNyiPW/x+OqzpQsktgmAITqIfkiG5hoIN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQBgGRRV/5RdJa1cgwZSWgSDDsISCoV1AhyBO0wBAQEBAQF9hBUBAQQBAQEgETQGCQIQAgEIGAICHwcCAgIlCxUQAgQBDQUUhWeCNA2wZpoqAQEBAQEBAQEBAQEBAQEBAQEBARmBIYoHhBYRAR0YGweCaIFFBZBQg2+GAIEbOoJ2jBuDRyKCMoE8b4ELOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,472,1422921600"; d="scan'208";a="135646801" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 26 Mar 2015 14:37:42 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2QEbg5w022101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 14:37:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.130]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 09:37:42 -0500 From: "Eric Vyncke (evyncke)" To: Merike Kaeo , Mikael Abrahamsson Thread-Topic: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) Thread-Index: AQHQWs7PxLq1VIcV1E6/+HsVS3BBAZ0e0RlYgABglwCAAB89AIAABs8AgAAn/QCAAAG/gIAAK42AgAAL4ICAAViYAIAABRgAgA3YnoA= Date: Thu, 26 Mar 2015 14:37:41 +0000 Message-ID: References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.89.2.186] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 26 Mar 2015 14:37:53 -0000 TWVyaWtlIGFuZCBGZXJuYW5kbywNCg0KQXMgSSB3cm90ZSBhIGNvdXBsZSBvZiBjb21tZW50cyBv biB0aGUgbWV0aG9kb2xvZ3ksIEkgZG8gbm90IG1pbmQgam9pbmluZw0KeW91ciB0ZXN0IGNhbXBh aWduIDstKQ0KDQpMZXQncyB0YWxrIHBlcmhhcHMgaGVyZSBpbiBEYWxsYXM/DQoNCi3DqXJpYw0K DQpPbiAxNy8wMy8xNSAxNToxMCwgIk1lcmlrZSBLYWVvIiA8a2Flb0BtZXJpa2UuY29tPiB3cm90 ZToNCg0KPg0KPk9uIE1hciAxNywgMjAxNSwgYXQgNjo1MiBBTSwgTWlrYWVsIEFicmFoYW1zc29u IDxzd21pa2VAc3dtLnBwLnNlPiB3cm90ZToNCj4NCj4+IE9uIE1vbiwgMTYgTWFyIDIwMTUsIHN0 aGF1Z0BuZXRoZWxwLm5vIHdyb3RlOg0KPj4gDQo+Pj4+PiBMZXRzIGxpdmUgaW4gdGhlIHJlYWwg d29ybGQgc2hhbGwgd2U/DQo+Pj4+PiANCj4+Pj4+aHR0cDovL2N1c3RvbWVyLmNvbWNhc3QuY29t L2hlbHAtYW5kLXN1cHBvcnQvaW50ZXJuZXQvZW1haWwtcG9ydC0yNS1ubw0KPj4+Pj4tbG9uZ2Vy LXN1cHBvcnRlZC8NCj4+Pj4gDQo+Pj4+IEFoLCBzbyB0aGUgcmVhc29uIHRoYXQgYW4gSVNQIHdv dWxkIGVuZm9yY2UgQUNMcyBpcyBiZWNhdXNlIG9mIGENCj4+Pj5wcm90b2NvbCB3aXRoIGEgbG91 c3kgc2VjdXJpdHkgbW9kZWwgdGhhdCBpcyBvbmx5IGZpeGFibGUgKGFuZCBldmVuDQo+Pj4+dGhl biwgbm90IHZlcnkpIHdpdGggdGhlIGhlbHAgb2YgZmlyZXdhbGxzLiAgIEZhaXIgZW5vdWdoLS1J IGhhZA0KPj4+PmRldmVsb3BlZCBhIGJsaW5kIHNwb3QgYWJvdXQgdGhpcyBpc3N1ZSBiZWNhdXNl IGl0J3MgYmVlbiBicm9rZW4gZm9yDQo+Pj4+c28gbG9uZyBhbmQgd2UndmUgYmVlbiByZWZsZXhp dmVseSBhdm9pZGluZyB0aGUgYnJva2VubmVzcyBmb3Igc28gbG9uZy4NCj4+Pj4gDQo+Pj4+IEJ1 dCBlc3NlbnRpYWxseSB3aGF0J3MgaGFwcGVuaW5nIGhlcmUgaXMgdGhhdCB3ZSBhcmUgc2VlaW5n IGEgZGVzaWduDQo+Pj4+ZmxhdyBhdCBsYXllciA3IGZvcmNpbmcgYnJva2VubmVzcyBhdCBsYXll ciAzLiAgIE9vcHMuICAgTWF5YmUgd2UNCj4+Pj5zaG91bGQgc3RvcCByZWZsZXhpdmVseSB3b3Jr aW5nIGFyb3VuZCB0aGlzIHByb2JsZW0gYW5kIHNlcmlvdXNseQ0KPj4+PmZpZ3VyZSBvdXQgaG93 IGZpeCBpdCwgc28gdGhhdCB0d2VudHkgeWVhcnMgZnJvbSBub3cgd2Ugbm8gbG9uZ2VyIG5lZWQN Cj4+Pj5hIGJyb2tlbiBsYXllciAzLg0KPj4+IA0KPj4+IEknbSBhbGwgZm9yIHRoYXQuIEhvd2V2 ZXIsIEkgY2Fubm90IGFmZm9yZCB0byB3YWl0IDIwIHllYXJzIGZvciBhIGZpeA0KPj4+IHRvIHRo ZSBwcm9ibGVtcy4gTXkgcHJpb3JpdGllcywgYXMgSSBzZWUgdGhlbToNCj4+PiANCj4+PiAxLiBQ cm90ZWN0IG15IG5ldHdvcmsuDQo+Pj4gMi4gV2l0aGluIHJlYXNvbiwgcHJvdGVjdCBteSBjdXN0 b21lcnMuDQo+Pj4gMy4gTW92ZSB0cmFmZmljIHRvIGFuZCBmcm9tIG15IGN1c3RvbWVycywgaW4g YSBzZW1pLW9wdGltYWwgd2F5Lg0KPj4gDQo+PiBQbGVhc2UgYWxzbyBhZGQgNC4gIlByb3RlY3Qg dGhlIEludGVybmV0IGZyb20geW91ciBjdXN0b21lcnMiLiBUaGlzIGlzDQo+PnNvbWV0aGluZyB0 b28gbWFueSBtaXNzLg0KPg0KPkkgZm9yIG9uZSBhbSByZWFsbHkgZ2xhZCB0aGF0IHdlIGFyZSBn ZXR0aW5nIG9wZXJhdGlvbmFsIHJlYWxpdHkgaW5wdXQuDQo+VGhhbmsgeW91LiAgRldJVywgSSdt IHNpdHRpbmcgbmV4dCB0byBGZXJuYW5kbyBhdCBhIHNlY3VyaXR5IGNvbmZlcmVuY2UNCj53ZSBh cmUgYm90aCBhdA0KPmFuZCBJIGhhZCBvZmZlcmVkIHRvIGhlbHAgd2l0aCB0aGlzIGRyYWZ0LiAg VGhpcyB3YXMgYSBmZXcgbW9udGhzIGFnby4NCj5XaGF0IEkgc2VlIGlzIHRoYXQgd2UgYXJlIGlu IG5lZWQgb2Ygc29tZSBhZGRpdGlvbmFsIG1lYXN1cmVtZW50cyBhbmQgdGhhdA0KPndpbGwgaGFw cGVuLiAgSSB3b3VsZCBsb3ZlIHRvIHNlZSBzb21lIGFkZGVkIGlucHV0IG9uIHRoaXMgbGlzdCBp biBob3cgdG8NCj5pbXByb3ZlIG1lYXN1cmVtZW50cyByYXRoZXIgdGhhbiB0aGUgY3JpdGljaXNt IG9mIGp1c3QgaG93IGN1cnJlbnQNCj5tZWFzdXJlbWVudHMNCj5oYXZlIGJlZW4gZG9uZS4gIENv bGxlY3RpdmVseSBnYXRoZXJpbmcgb3BlcmF0aW9uYWwgcmVhbGl0aWVzIGlzIGEgZ29vZA0KPnRo aW5nIGZvciBhZGRlZCBpbnB1dCBvbiBob3cgdG8gZGVhbCB3aXRoIEVIcy4gIEFuZCBGV0lXLCBJ IGFtIG5vdCBpbg0KPmZhdm9yIG9mDQo+ZGVwcmVjYXRpbmcgRUhzIHNpbmNlIHRoYXQgaXMgdG9v IGRyYXN0aWMgYnV0IHdlIGFzIGEgY29tbXVuaXR5IGhhdmUgdG8NCj51bmRlcnN0YW5kIHdoZXJl IHRoZXkgYXJlIHByYWN0aWNhbGx5IHVzZWQgYW5kIHdoZXJlIHRoZXkgYXJlIGRyb3BwZWQgZm9y DQo+cmVhc29ucyB0aGF0IHNvbWUgZGVlbSBhcyBuZWNlc3NhcnkuDQo+DQo+LSBtZXJpa2UNCj4N Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnY2 b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Thu Mar 26 07:50:31 2015 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 F34C61AD0BB for ; Thu, 26 Mar 2015 07:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3] 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 K22WGMZSP2H8 for ; Thu, 26 Mar 2015 07:50:28 -0700 (PDT) Received: from Mail.Yoyodyne.COM (Mail.Yoyodyne.com [69.36.251.10]) by ietfa.amsl.com (Postfix) with SMTP id 3EFF51AD0A1 for ; Thu, 26 Mar 2015 07:48:09 -0700 (PDT) Received: from dhcp-b13c.meeting.ietf.org ([31.133.177.60]) by Mail.Yoyodyne.COM via Internet for (and others); Thu, 26 Mar 2015 07:47:55 PDT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: Date: Thu, 26 Mar 2015 07:47:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 26 Mar 2015 14:50:30 -0000 Sounds good. Warren/Joel=85I think resurrecting work on Why Operators Filter = Fragments (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) = may be a good idea :) - merike [list may get duplicate of this message since first attempt was blocked = due to using email I didn't use to subscribe to list=85..apologies in = advance] On Mar 26, 2015, at 7:37 AM, "Eric Vyncke (evyncke)" = wrote: > Merike and Fernando, >=20 > As I wrote a couple of comments on the methodology, I do not mind = joining > your test campaign ;-) >=20 > Let's talk perhaps here in Dallas? >=20 > -=E9ric >=20 > On 17/03/15 15:10, "Merike Kaeo" wrote: >=20 >>=20 >> On Mar 17, 2015, at 6:52 AM, Mikael Abrahamsson = wrote: >>=20 >>> On Mon, 16 Mar 2015, sthaug@nethelp.no wrote: >>>=20 >>>>>> Lets live in the real world shall we? >>>>>>=20 >>>>>> = http://customer.comcast.com/help-and-support/internet/email-port-25-no >>>>>> -longer-supported/ >>>>>=20 >>>>> Ah, so the reason that an ISP would enforce ACLs is because of a >>>>> protocol with a lousy security model that is only fixable (and = even >>>>> then, not very) with the help of firewalls. Fair enough--I had >>>>> developed a blind spot about this issue because it's been broken = for >>>>> so long and we've been reflexively avoiding the brokenness for so = long. >>>>>=20 >>>>> But essentially what's happening here is that we are seeing a = design >>>>> flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we >>>>> should stop reflexively working around this problem and seriously >>>>> figure out how fix it, so that twenty years from now we no longer = need >>>>> a broken layer 3. >>>>=20 >>>> I'm all for that. However, I cannot afford to wait 20 years for a = fix >>>> to the problems. My priorities, as I see them: >>>>=20 >>>> 1. Protect my network. >>>> 2. Within reason, protect my customers. >>>> 3. Move traffic to and from my customers, in a semi-optimal way. >>>=20 >>> Please also add 4. "Protect the Internet from your customers". This = is >>> something too many miss. >>=20 >> I for one am really glad that we are getting operational reality = input. >> Thank you. FWIW, I'm sitting next to Fernando at a security = conference >> we are both at >> and I had offered to help with this draft. This was a few months = ago. >> What I see is that we are in need of some additional measurements and = that >> will happen. I would love to see some added input on this list in = how to >> improve measurements rather than the criticism of just how current >> measurements >> have been done. Collectively gathering operational realities is a = good >> thing for added input on how to deal with EHs. And FWIW, I am not in >> favor of >> deprecating EHs since that is too drastic but we as a community have = to >> understand where they are practically used and where they are dropped = for >> reasons that some deem as necessary. >>=20 >> - merike >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Mar 26 07:52:46 2015 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 1913A1AD01E for ; Thu, 26 Mar 2015 07:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 vJSgX3BTd6yW for ; Thu, 26 Mar 2015 07:52:43 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c: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 8477F1ACE85 for ; Thu, 26 Mar 2015 07:51:08 -0700 (PDT) Received: by wgs2 with SMTP id 2so67251416wgs.1 for ; Thu, 26 Mar 2015 07:51:07 -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-type; bh=/np/Q4SilN7oMgfJnVh9AWT35wRGUpNKjlDD3a3tkxY=; b=ITl6gHbzUs6gLMrtajUA44XbB1QEd+oJJhTWkUlD29Vk6MFZCdbu9LRACpZDXdrOoI cdUFgqf4njzGpf+HDwvyfqSU9INdDzVitpCLjQJQvla7LOhrgFbqiitd65QMionm6HH3 gmnCOrAQmBsIXlDSJy/Zyv8csH2bMiYkN//BrYjeVwVNLzmg4NL4GQ68gy6/WNgrKLqa j1lkpiZWau0p/47W3+SBDF73JmQdVtye+LQ0gUxzG0JZ6tQNpwkJkgqV6VxF38fNZTcD gSc294kuVZaWUh4AYXHHSpFHdbxMMKwhjVmGV08cD4lMdrsMa1MJrilyn2hCS/uMKJx1 Z9aA== X-Received: by 10.194.210.103 with SMTP id mt7mr29158498wjc.103.1427381467158; Thu, 26 Mar 2015 07:51:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.58.76 with HTTP; Thu, 26 Mar 2015 07:50:46 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> From: Jen Linkova Date: Thu, 26 Mar 2015 15:50:46 +0100 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , Tore Anderson , Philip Matthews Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 14:52:45 -0000 On Thu, Mar 26, 2015 at 2:53 PM, Templin, Fred L wrote: >> We seemed to have rough consensus on link-local-address-only. > > The consensus alternative I recall seeing was "link-local-only" (three > words separated by two dashes). IMHO (but I'm not a native speaker), "link-local-only interface" sounds weird. Interface isn't link-local, it is address it has is link-local. So maybe we should use 'LLA-only interface' (less dashes ;)) and 'GUAed interface' for an interface with a global unicast address assigned? >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee >> Sent: Thursday, March 26, 2015 5:04 AM >> To: Tore Anderson; Philip Matthews >> Cc: v6ops list >> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >> >> We seemed to have rough consensus on link-local-address-only. >> >> Lee >> >> On 3/26/15, 2:56 AM, "Tore Anderson" wrote: >> >> >* Philip Matthews >> > >> >> What does the WG think? Should we use the "unnumbered" terms, or >> >> should we use just the "... with only link-local address" terms? Is >> >> it acceptable to mix the two sets of terms? >> > >> >I didn't quite catch on the Meetecho if a final decision was reached >> >yesterday, but in case not here's my suggestions: >> > >> >- Link-scoped (IPv6) interface >> > >> >vs >> > >> >- Global-scoped (IPv6) interface >> > >> >The global scope includes the link scope, so the latter wouldn't mean >> >"no link local address". >> > >> >(Or maybe it's better to say "globally" and "scope", my English isn't >> >good enough to know which of these nuances would be 100% correct.) >> > >> >Tore >> >who finally succumbed to the bikeshedding temptation >> > >> >_______________________________________________ >> >v6ops mailing list >> >v6ops@ietf.org >> >https://www.ietf.org/mailman/listinfo/v6ops >> >> >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or >> subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is >> addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, >> or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have >> received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and >> any printout. >> >> _______________________________________________ >> 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 -- SY, Jen Linkova aka Furry From nobody Thu Mar 26 07:55:33 2015 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 496941AD055 for ; Thu, 26 Mar 2015 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 KWYSJR392f7V for ; Thu, 26 Mar 2015 07:55:30 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c: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 BBFE01AD072 for ; Thu, 26 Mar 2015 07:53:26 -0700 (PDT) Received: by wiaa2 with SMTP id a2so26164873wia.0 for ; Thu, 26 Mar 2015 07:53:25 -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-type:content-transfer-encoding; bh=pHtsnUZ+5TY4UzF3CrdrH0cyUnuu1rmyURdw81p+v0Y=; b=SIvyFpwk/GSZkNgXslPKOfO+ithsA99LBJBZZVCeYmJy6J0vLKciYa7Meyph5BDRP0 BxJOzLGfPy3OValx1Gx37H3rKW9IMMkt5ROHp5R+AFARxRFKr69YY8wyiECZ+ySCUOCu n8kHH+OcwZXjQ5ZSIpGWygebYoMXeb3jz+hmk+GThEinj38CsLOyPYRlPaveyAotrztc Mnf2vXJw+ElkGq5j/l0r4151MZs6jXYDVk4thXKXi5P1/4GEIDFdYY/HnBlYPnX9KjgY UhHbH7N4ztKFS/bj48AyPL9ohPDmmzw10v/9EsiZ8uUsaYcC6lZodG96BDjYB/imR+yb g1jw== X-Received: by 10.180.228.104 with SMTP id sh8mr39978799wic.61.1427381605549; Thu, 26 Mar 2015 07:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.58.76 with HTTP; Thu, 26 Mar 2015 07:53:05 -0700 (PDT) In-Reply-To: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> From: Jen Linkova Date: Thu, 26 Mar 2015 15:53:05 +0100 Message-ID: To: Merike Kaeo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 26 Mar 2015 14:55:31 -0000 On Thu, Mar 26, 2015 at 3:47 PM, Merike Kaeo wrote: > Sounds good. > > Warren/Joel=E2=80=A6I think resurrecting work on Why Operators Filter Fra= gments (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be = a good idea :) Do we really need to resurrect a draft which covers one particular EH filtering while we are working on a draft which covers EHs in general? > > On Mar 26, 2015, at 7:37 AM, "Eric Vyncke (evyncke)" = wrote: > >> Merike and Fernando, >> >> As I wrote a couple of comments on the methodology, I do not mind joinin= g >> your test campaign ;-) >> >> Let's talk perhaps here in Dallas? >> >> -=C3=A9ric >> >> On 17/03/15 15:10, "Merike Kaeo" wrote: >> >>> >>> On Mar 17, 2015, at 6:52 AM, Mikael Abrahamsson wrot= e: >>> >>>> On Mon, 16 Mar 2015, sthaug@nethelp.no wrote: >>>> >>>>>>> Lets live in the real world shall we? >>>>>>> >>>>>>> http://customer.comcast.com/help-and-support/internet/email-port-25= -no >>>>>>> -longer-supported/ >>>>>> >>>>>> Ah, so the reason that an ISP would enforce ACLs is because of a >>>>>> protocol with a lousy security model that is only fixable (and even >>>>>> then, not very) with the help of firewalls. Fair enough--I had >>>>>> developed a blind spot about this issue because it's been broken for >>>>>> so long and we've been reflexively avoiding the brokenness for so lo= ng. >>>>>> >>>>>> But essentially what's happening here is that we are seeing a design >>>>>> flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we >>>>>> should stop reflexively working around this problem and seriously >>>>>> figure out how fix it, so that twenty years from now we no longer ne= ed >>>>>> a broken layer 3. >>>>> >>>>> I'm all for that. However, I cannot afford to wait 20 years for a fix >>>>> to the problems. My priorities, as I see them: >>>>> >>>>> 1. Protect my network. >>>>> 2. Within reason, protect my customers. >>>>> 3. Move traffic to and from my customers, in a semi-optimal way. >>>> >>>> Please also add 4. "Protect the Internet from your customers". This is >>>> something too many miss. >>> >>> I for one am really glad that we are getting operational reality input. >>> Thank you. FWIW, I'm sitting next to Fernando at a security conference >>> we are both at >>> and I had offered to help with this draft. This was a few months ago. >>> What I see is that we are in need of some additional measurements and t= hat >>> will happen. I would love to see some added input on this list in how = to >>> improve measurements rather than the criticism of just how current >>> measurements >>> have been done. Collectively gathering operational realities is a good >>> thing for added input on how to deal with EHs. And FWIW, I am not in >>> favor of >>> deprecating EHs since that is too drastic but we as a community have to >>> understand where they are practically used and where they are dropped f= or >>> reasons that some deem as necessary. >>> >>> - merike >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Thu Mar 26 08:38:38 2015 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 CCB661AD0B9 for ; Thu, 26 Mar 2015 08:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3] 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 mfsKA4uIPOlF for ; Thu, 26 Mar 2015 08:38:35 -0700 (PDT) Received: from Mail.Yoyodyne.COM (Mail.Yoyodyne.com [69.36.251.10]) by ietfa.amsl.com (Postfix) with SMTP id ADCDE1AD0B8 for ; Thu, 26 Mar 2015 08:38:31 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:e480:e613:b670:8a60] ([2001:67c:370:176:e480:e613:b670:8a60]) by Mail.Yoyodyne.COM via Internet for (and others); Thu, 26 Mar 2015 08:38:22 PDT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: Date: Thu, 26 Mar 2015 08:38:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> To: Jen Linkova X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 26 Mar 2015 15:38:37 -0000 On Mar 26, 2015, at 7:53 AM, Jen Linkova wrote: > On Thu, Mar 26, 2015 at 3:47 PM, Merike Kaeo wrote: >> Sounds good. >>=20 >> Warren/Joel=85I think resurrecting work on Why Operators Filter = Fragments (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) = may be a good idea :) >=20 > Do we really need to resurrect a draft which covers one particular EH > filtering while we are working on a draft which covers EHs in general? :) There's the option of resurrecting and expanding on the document = that describes why EHs in general are dropped and does not only speak to = Fragmentation Headers. IFF there is interest in more work on general case of Why Operators = Filter EHs - probably best to keep as separate document. I think. I = was debating with myself as to whether I'd prefer to read it in one = single document (here is what's measured, here's why EHs are dropped in = practice by operators, advice on operational practices). But I haven't = decided for myself yet since there is merit in just keeping a = measurement document separate so that the problem statement can be kept = separate from any recommendations, which will be wiggly at best. - merike >=20 >>=20 >> On Mar 26, 2015, at 7:37 AM, "Eric Vyncke (evyncke)" = wrote: >>=20 >>> Merike and Fernando, >>>=20 >>> As I wrote a couple of comments on the methodology, I do not mind = joining >>> your test campaign ;-) >>>=20 >>> Let's talk perhaps here in Dallas? >>>=20 >>> -=E9ric >>>=20 >>> On 17/03/15 15:10, "Merike Kaeo" wrote: >>>=20 >>>>=20 >>>> On Mar 17, 2015, at 6:52 AM, Mikael Abrahamsson = wrote: >>>>=20 >>>>> On Mon, 16 Mar 2015, sthaug@nethelp.no wrote: >>>>>=20 >>>>>>>> Lets live in the real world shall we? >>>>>>>>=20 >>>>>>>> = http://customer.comcast.com/help-and-support/internet/email-port-25-no >>>>>>>> -longer-supported/ >>>>>>>=20 >>>>>>> Ah, so the reason that an ISP would enforce ACLs is because of a >>>>>>> protocol with a lousy security model that is only fixable (and = even >>>>>>> then, not very) with the help of firewalls. Fair enough--I had >>>>>>> developed a blind spot about this issue because it's been broken = for >>>>>>> so long and we've been reflexively avoiding the brokenness for = so long. >>>>>>>=20 >>>>>>> But essentially what's happening here is that we are seeing a = design >>>>>>> flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe = we >>>>>>> should stop reflexively working around this problem and = seriously >>>>>>> figure out how fix it, so that twenty years from now we no = longer need >>>>>>> a broken layer 3. >>>>>>=20 >>>>>> I'm all for that. However, I cannot afford to wait 20 years for a = fix >>>>>> to the problems. My priorities, as I see them: >>>>>>=20 >>>>>> 1. Protect my network. >>>>>> 2. Within reason, protect my customers. >>>>>> 3. Move traffic to and from my customers, in a semi-optimal way. >>>>>=20 >>>>> Please also add 4. "Protect the Internet from your customers". = This is >>>>> something too many miss. >>>>=20 >>>> I for one am really glad that we are getting operational reality = input. >>>> Thank you. FWIW, I'm sitting next to Fernando at a security = conference >>>> we are both at >>>> and I had offered to help with this draft. This was a few months = ago. >>>> What I see is that we are in need of some additional measurements = and that >>>> will happen. I would love to see some added input on this list in = how to >>>> improve measurements rather than the criticism of just how current >>>> measurements >>>> have been done. Collectively gathering operational realities is a = good >>>> thing for added input on how to deal with EHs. And FWIW, I am not = in >>>> favor of >>>> deprecating EHs since that is too drastic but we as a community = have to >>>> understand where they are practically used and where they are = dropped for >>>> reasons that some deem as necessary. >>>>=20 >>>> - merike >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > --=20 > SY, Jen Linkova aka Furry From nobody Thu Mar 26 09:29:13 2015 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 BD3421A7D80 for ; Thu, 26 Mar 2015 09:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 N8nIS5h9VyZl for ; Thu, 26 Mar 2015 09:29:10 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 AAAC31A1B62 for ; Thu, 26 Mar 2015 09:29:10 -0700 (PDT) Received: by oifl3 with SMTP id l3so53853189oif.0 for ; Thu, 26 Mar 2015 09:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+oWAF9Hff2dKCr2xxgZp7njtIaWxTf/2Gy7LWCWdPeE=; b=fo8iT98Dv8iVkqdlBqx6QFYSNcGDjjk0E1N2j4l3itGqiaiDVoraplFbGfoC24HCM0 UY91jUfeRHmJBHSvnRkIkN1y20/+QrAIounZ9dInOGLduuPVWkFPMDniC1RBPqiTZSIl HC3lrWEdNEY4qm2+q1yaxWx1eZpssjJ9uRES8= 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-type; bh=+oWAF9Hff2dKCr2xxgZp7njtIaWxTf/2Gy7LWCWdPeE=; b=WKpvVxvfv0dYLxMTCcwLbjJKJr2mdwnNjS+udBUa9zOHRByxmjXWmRbC5uE8/B5Tvl 8qdJUlqDdEZXR0FyvDRmbVpt8ghbOVjCyE7GYJbbvczrXba8R8ceJ4oncNyHsU3ekQac cE1L50FtTv7FsKtiii3wfCvv8OCpP0L44hvEdp3daSMtUZqNbfbyxB3t430PYUIOtAp9 f15EgaWP383PcQXKidmtBX/aAzUJq8J3glYQLu7l1SzcqXpCtXZ59DOxgYf7k6Jwq8cF nvLQN1fIitjCorc2lFgyFzO/c9DfwerHBCVNZTXEkin1fhIp4guXOiGeQA6kyK2o8EQf WZ1w== X-Gm-Message-State: ALoCoQmGPKvWIAUz22miMZnUMJSu+1nXXOaGFcWC1jUKDi+AL8AHXZYH4p1ZVWcP2XDqyOAvWCk1 MIME-Version: 1.0 X-Received: by 10.202.231.85 with SMTP id e82mr12070428oih.104.1427387350211; Thu, 26 Mar 2015 09:29:10 -0700 (PDT) Received: by 10.76.150.2 with HTTP; Thu, 26 Mar 2015 09:29:10 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Thu, 26 Mar 2015 11:29:10 -0500 Message-ID: From: James Woodyatt To: Ca By Content-Type: multipart/alternative; boundary=001a11417b20f7788b0512338391 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 16:29:11 -0000 --001a11417b20f7788b0512338391 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 25, 2015 at 8:21 PM, Ca By wrote: > > > [...] does not solve the non-zero number of websites in the Alexa 100 that > have IPv4 literals in html / xml / js. > It also does not solve the sip / xmpp issue of being completely littered > with IPv4 referrals. [...] > Neither does IPv6+CLAT, which simply admits defeat. The IPv4 literals will never die, and IPv4 as a service will never be sunset. Yes, I recognize that entirely shifting the burden of supporting IPv4 onto the operating system developers, into the unforeseeable future, while the network operators get a clean transition to IPv6-only, can seem like a "solution" from certain bell-shaped perspectives, but there is still a world outside that perspective where some of us are trying to make a living. -- james woodyatt Nest Labs, Communications Engineering --001a11417b20f7788b0512338391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 25, 2015 at 8:21 PM, Ca By <cb.list6@gmail.com> wro= te:

=
[...] does not solve the=C2=A0non-zero number of websites in the= Alexa 100 that have IPv4 literals in html / xml / js.=C2=A0
It= =C2=A0also does not solve the sip / xmpp issue of being completely littered= with IPv4 referrals. [...]
Neither does IPv6+CLAT, which simply admits defeat. The IPv4 li= terals will never die, and IPv4 as a service will never be sunset. Yes, I r= ecognize that entirely shifting the burden of supporting IPv4 onto the oper= ating system developers, into the unforeseeable future, while the network o= perators get a clean transition to IPv6-only, can seem like a "solutio= n" from certain bell-shaped perspectives, but there is still a world o= utside that perspective where some of us are trying to make a living.
=


--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering<= /div>
--001a11417b20f7788b0512338391-- From nobody Thu Mar 26 09:47:03 2015 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 0267C1A87E3 for ; Thu, 26 Mar 2015 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 R75HadaFh6ax for ; Thu, 26 Mar 2015 09:47:00 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCA71A887A for ; Thu, 26 Mar 2015 09:46:51 -0700 (PDT) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 26 Mar 2015 16:46:50 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0118.022; Thu, 26 Mar 2015 16:46:50 +0000 From: "Metzler, Dan J" To: James Woodyatt , Ca By Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AQHQYouA3ye9AcRTck+xU68IbGwQo50k3BQAgAB1XgCAADeeAIADZz+AgAFS54CAAVsLAIAAFWiAgAAAioCAAA8DgIAAC2wAgABuQoCAAa/cAIAAFKSAgAD9fgCAAAMtoA== Date: Thu, 26 Mar 2015 16:46:49 +0000 Message-ID: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.255.224.53] authentication-results: nestlabs.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(377454003)(24454002)(66066001)(40100003)(93886004)(122556002)(87936001)(62966003)(77156002)(19300405004)(2950100001)(77096005)(92566002)(90282001)(2900100001)(102836002)(54356999)(74316001)(76176999)(16236675004)(50986999)(106116001)(86362001)(76576001)(99286002)(19580405001)(15975445007)(19609705001)(2656002)(89122001)(88552001)(75432002)(46102003)(19580395003)(19625215002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO2PR04MB587; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB587; x-forefront-prvs: 0527DFA348 Content-Type: multipart/alternative; boundary="_000_CO2PR04MB585C662E11E02460438EA45FE080CO2PR04MB585namprd_" MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2015 16:46:49.7483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB587 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 16:47:02 -0000 --_000_CO2PR04MB585C662E11E02460438EA45FE080CO2PR04MB585namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcWWVzLCBJIHJlY29nbml6ZSB0aGF0IGVudGlyZWx5IHNoaWZ0aW5nIHRoZSBidXJkZW4gb2Yg c3VwcG9ydGluZyBJUHY0IG9udG8gdGhlIG9wZXJhdGluZyBzeXN0ZW0gZGV2ZWxvcGVycywgaW50 byB0aGUgdW5mb3Jlc2VlYWJsZSBmdXR1cmUsIHdoaWxlIHRoZSBuZXR3b3JrIG9wZXJhdG9ycyBn ZXQgYSBjbGVhbiB0cmFuc2l0aW9uIHRvIElQdjYtb25seSwgY2FuIHNlZW0gbGlrZSBhICJzb2x1 dGlvbiIgZnJvbSBjZXJ0YWluIGJlbGwtc2hhcGVkIHBlcnNwZWN0aXZlcywgYnV0IHRoZXJlIGlz IHN0aWxsIGEgd29ybGQgb3V0c2lkZSB0aGF0IHBlcnNwZWN0aXZlIHdoZXJlIHNvbWUgb2YgdXMg YXJlIHRyeWluZyB0byBtYWtlIGEgbGl2aW5nLuKAnQ0KDQoNCi0gICAgICAgICAgV2hhdCBkb2Vz IHRoYXQgbWVhbj8NCg0KSVB2NCBsaXRlcmFscyB3aWxsIGRpZSBvZmYgd2l0aCBJUHY0LCBvciBz b29uZXIsIHdoZW5ldmVyIHRoYXQgaGFwcGVucy4gIEluIG90aGVyIHdvcmRzLCDigJxuZXZlcuKA nSwgaXMgYSBsb25nIHRpbWU7IHByb2JhYmx5IHRvbyBsb25nIGZvciB0aGF0IHN0YXRlbWVudCB0 byBiZSByZWFsaXN0aWMuICBXaGF0IGFyZSB5b3UgYWR2b2NhdGluZz8NCg0KVGhhbmtzLA0KDQoN Ci0gICAgICAgICAgRGFuIE1ldHpsZXINCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMgV29vZHlhdHQNClNlbnQ6IFRodXJzZGF5 LCBNYXJjaCAyNiwgMjAxNSAxMToyOSBBTQ0KVG86IENhIEJ5DQpDYzogSVB2NiBPcHMgV0cNClN1 YmplY3Q6IFJlOiBbdjZvcHNdIFRoZSBuZWVkIGZvciBsb2NhbC1pcHY0IHNvY2tldCB0cmFuc2l0 aW9uIHNvbHV0aW9ucyAtLSBOQVQ2NC9ETlM2NCByZW1haW5zIGluc3VmZmljaWVudA0KDQpPbiBX ZWQsIE1hciAyNSwgMjAxNSBhdCA4OjIxIFBNLCBDYSBCeSA8Y2IubGlzdDZAZ21haWwuY29tPG1h aWx0bzpjYi5saXN0NkBnbWFpbC5jb20+PiB3cm90ZToNCg0KWy4uLl0gZG9lcyBub3Qgc29sdmUg dGhlIG5vbi16ZXJvIG51bWJlciBvZiB3ZWJzaXRlcyBpbiB0aGUgQWxleGEgMTAwIHRoYXQgaGF2 ZSBJUHY0IGxpdGVyYWxzIGluIGh0bWwgLyB4bWwgLyBqcy4NCkl0IGFsc28gZG9lcyBub3Qgc29s dmUgdGhlIHNpcCAvIHhtcHAgaXNzdWUgb2YgYmVpbmcgY29tcGxldGVseSBsaXR0ZXJlZCB3aXRo IElQdjQgcmVmZXJyYWxzLiBbLi4uXQ0KDQpOZWl0aGVyIGRvZXMgSVB2NitDTEFULCB3aGljaCBz aW1wbHkgYWRtaXRzIGRlZmVhdC4gVGhlIElQdjQgbGl0ZXJhbHMgd2lsbCBuZXZlciBkaWUsIGFu ZCBJUHY0IGFzIGEgc2VydmljZSB3aWxsIG5ldmVyIGJlIHN1bnNldC4gWWVzLCBJIHJlY29nbml6 ZSB0aGF0IGVudGlyZWx5IHNoaWZ0aW5nIHRoZSBidXJkZW4gb2Ygc3VwcG9ydGluZyBJUHY0IG9u dG8gdGhlIG9wZXJhdGluZyBzeXN0ZW0gZGV2ZWxvcGVycywgaW50byB0aGUgdW5mb3Jlc2VlYWJs ZSBmdXR1cmUsIHdoaWxlIHRoZSBuZXR3b3JrIG9wZXJhdG9ycyBnZXQgYSBjbGVhbiB0cmFuc2l0 aW9uIHRvIElQdjYtb25seSwgY2FuIHNlZW0gbGlrZSBhICJzb2x1dGlvbiIgZnJvbSBjZXJ0YWlu IGJlbGwtc2hhcGVkIHBlcnNwZWN0aXZlcywgYnV0IHRoZXJlIGlzIHN0aWxsIGEgd29ybGQgb3V0 c2lkZSB0aGF0IHBlcnNwZWN0aXZlIHdoZXJlIHNvbWUgb2YgdXMgYXJlIHRyeWluZyB0byBtYWtl IGEgbGl2aW5nLg0KDQoNCi0tDQpqYW1lcyB3b29keWF0dCA8amh3QG5lc3RsYWJzLmNvbTxtYWls dG86amh3QG5lc3RsYWJzLmNvbT4+DQpOZXN0IExhYnMsIENvbW11bmljYXRpb25zIEVuZ2luZWVy aW5nDQo= --_000_CO2PR04MB585C662E11E02460438EA45FE080CO2PR04MB585namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDUxNzYxMjExOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTM0MjY4NzYzNiAxNTIxNTIz NDk0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTYuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDo5Mi41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTI4LjVwdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6MTY0LjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAw LjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMzYuNXB0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDoyNzIuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDguNXB0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj7igJw8L3NwYW4+WWVzLCBJIHJlY29nbml6ZSB0aGF0IGVudGlyZWx5IHNoaWZ0 aW5nIHRoZSBidXJkZW4gb2Ygc3VwcG9ydGluZyBJUHY0IG9udG8gdGhlIG9wZXJhdGluZyBzeXN0 ZW0gZGV2ZWxvcGVycywgaW50byB0aGUgdW5mb3Jlc2VlYWJsZSBmdXR1cmUsIHdoaWxlIHRoZSBu ZXR3b3JrDQogb3BlcmF0b3JzIGdldCBhIGNsZWFuIHRyYW5zaXRpb24gdG8gSVB2Ni1vbmx5LCBj YW4gc2VlbSBsaWtlIGEgJnF1b3Q7c29sdXRpb24mcXVvdDsgZnJvbSBjZXJ0YWluIGJlbGwtc2hh cGVkIHBlcnNwZWN0aXZlcywgYnV0IHRoZXJlIGlzIHN0aWxsIGEgd29ybGQgb3V0c2lkZSB0aGF0 IHBlcnNwZWN0aXZlIHdoZXJlIHNvbWUgb2YgdXMgYXJlIHRyeWluZyB0byBtYWtlIGEgbGl2aW5n LjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMC41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hhdCBkb2VzIHRoYXQgbWVh bj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklQdjQgbGl0ZXJh bHMgd2lsbCBkaWUgb2ZmIHdpdGggSVB2NCwgb3Igc29vbmVyLCB3aGVuZXZlciB0aGF0IGhhcHBl bnMuJm5ic3A7IEluIG90aGVyIHdvcmRzLCDigJxuZXZlcuKAnSwgaXMgYSBsb25nIHRpbWU7IHBy b2JhYmx5IHRvbyBsb25nIGZvciB0aGF0IHN0YXRlbWVudCB0byBiZSByZWFsaXN0aWMuJm5ic3A7 DQogV2hhdCBhcmUgeW91IGFkdm9jYXRpbmc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MjAuNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRhbiBNZXR6bGVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYW1lcyBXb29keWF0dDxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTE6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IENhIEJ5PGJy Pg0KPGI+Q2M6PC9iPiBJUHY2IE9wcyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3Bz XSBUaGUgbmVlZCBmb3IgbG9jYWwtaXB2NCBzb2NrZXQgdHJhbnNpdGlvbiBzb2x1dGlvbnMgLS0g TkFUNjQvRE5TNjQgcmVtYWlucyBpbnN1ZmZpY2llbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAy NSwgMjAxNSBhdCA4OjIxIFBNLCBDYSBCeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNiLmxpc3Q2QGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNiLmxpc3Q2QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsuLi5dIGRvZXMgbm90IHNvbHZlIHRo ZSZuYnNwO25vbi16ZXJvIG51bWJlciBvZiB3ZWJzaXRlcyBpbiB0aGUgQWxleGEgMTAwIHRoYXQg aGF2ZSBJUHY0IGxpdGVyYWxzIGluIGh0bWwgLyB4bWwgLyBqcy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0Jm5ic3A7YWxzbyBkb2Vz IG5vdCBzb2x2ZSB0aGUgc2lwIC8geG1wcCBpc3N1ZSBvZiBiZWluZyBjb21wbGV0ZWx5IGxpdHRl cmVkIHdpdGggSVB2NCByZWZlcnJhbHMuIFsuLi5dPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmVpdGhl ciBkb2VzIElQdjYmIzQzO0NMQVQsIHdoaWNoIHNpbXBseSBhZG1pdHMgZGVmZWF0LiBUaGUgSVB2 NCBsaXRlcmFscyB3aWxsIG5ldmVyIGRpZSwgYW5kIElQdjQgYXMgYSBzZXJ2aWNlIHdpbGwgbmV2 ZXIgYmUgc3Vuc2V0LiBZZXMsIEkgcmVjb2duaXplIHRoYXQgZW50aXJlbHkgc2hpZnRpbmcgdGhl IGJ1cmRlbiBvZiBzdXBwb3J0aW5nIElQdjQgb250byB0aGUgb3BlcmF0aW5nIHN5c3RlbSBkZXZl bG9wZXJzLA0KIGludG8gdGhlIHVuZm9yZXNlZWFibGUgZnV0dXJlLCB3aGlsZSB0aGUgbmV0d29y ayBvcGVyYXRvcnMgZ2V0IGEgY2xlYW4gdHJhbnNpdGlvbiB0byBJUHY2LW9ubHksIGNhbiBzZWVt IGxpa2UgYSAmcXVvdDtzb2x1dGlvbiZxdW90OyBmcm9tIGNlcnRhaW4gYmVsbC1zaGFwZWQgcGVy c3BlY3RpdmVzLCBidXQgdGhlcmUgaXMgc3RpbGwgYSB3b3JsZCBvdXRzaWRlIHRoYXQgcGVyc3Bl Y3RpdmUgd2hlcmUgc29tZSBvZiB1cyBhcmUgdHJ5aW5nIHRvIG1ha2UgYSBsaXZpbmcuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+amFtZXMgd29vZHlhdHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpqaHdAbmVzdGxhYnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+amh3 QG5lc3RsYWJzLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TmVzdCBMYWJzLCBDb21tdW5pY2F0aW9ucyBFbmdpbmVlcmluZzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO2PR04MB585C662E11E02460438EA45FE080CO2PR04MB585namprd_-- From nobody Thu Mar 26 09:56:46 2015 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 DB62E1A8866 for ; Thu, 26 Mar 2015 09:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mXQ8fHEGfFou for ; Thu, 26 Mar 2015 09:56:43 -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 829A91A87C6 for ; Thu, 26 Mar 2015 09:56:43 -0700 (PDT) Received: by ignm3 with SMTP id m3so16982603ign.0 for ; Thu, 26 Mar 2015 09:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K4MEMBfoLFx5oWmY/n9oTHZNbS9sqmHz5S4J6hIqjdM=; b=c3gbqoqcIqJxjH1qC3HiQEbRyFAq2fqBVVRVN28R62SYiVTv19nHfqceHTm1cJDE0R u2HErWkwt77leZRhthfpXkVV9l9UbW5/M8I4WkhNWV8xU3Vwxj2VDAzdiIWUcQLk7Xje d292f8UMKi7fSTvxUZ9COuNd2HySKTJmzJl/Rznq7SfM+dKskNg7ClvdNixNQy0dcwVp 3l7/GbWn8vAsFIWOooeud/Wam6qY+QUWU7q9POe0FJSlDJNYOdwFi2v47iYfdVTvhyGR 0Ag/s853DWAXuoz58qH7B3HSWEH/Ev8CsYqBw8SAuH0bk3gG9q1pIhvpOYb8LfkKmEs4 BzGQ== 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-type; bh=K4MEMBfoLFx5oWmY/n9oTHZNbS9sqmHz5S4J6hIqjdM=; b=UIpKG8pjauMrjB6FXa2DRL7CNUQmnYt2SSSxjJNHXWg6eaW9vnIY11iqBNKWOPxG4N SerEl9+7i/98Z18N3Kpbf4fBfYTyRLMOICmr8GKLGFga5hB+CNJjDpMaBJKX/bBfaEFx jZ0k+G+kh/e3mpWb7VDT8RTsm6Z4hNsLErmEovrwd+Mj1AspqVYLxKfqqdZWFz5iL9+y ZDns8jKxoT7tqHNCvdb10yoT2bs6IMhV83OD/wY6bsNjeM65RSAhdhwGaCo+5qywLawH sLB1MsZkxxDLypY5yYPwPEnaom1aEPT+Of7chBLdDGtn0OyijNvBWBfW4kXGN07QBT1X twcg== X-Gm-Message-State: ALoCoQmdyI/xfUbbcIDl01OG9sp7+/St4p5a5rWiYiX5oqg3SPiLjg41pgeNMpwRLmO8ccHxnvMq X-Received: by 10.50.124.164 with SMTP id mj4mr37954798igb.38.1427389002835; Thu, 26 Mar 2015 09:56:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Thu, 26 Mar 2015 09:56:22 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> From: Lorenzo Colitti Date: Thu, 26 Mar 2015 11:56:22 -0500 Message-ID: To: James Woodyatt Content-Type: multipart/alternative; boundary=001a11c2a68678905d051233e6c4 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 16:56:45 -0000 --001a11c2a68678905d051233e6c4 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt wrote: > Yes, I recognize that entirely shifting the burden of supporting IPv4 onto > the operating system developers, into the unforeseeable future, while the > network operators get a clean transition to IPv6-only, can seem like a > "solution" from certain bell-shaped perspectives, but there is still a > world outside that perspective where some of us are trying to make a living. > As someone who does maintain a 464xlat implementation for the purposes of supporting IPv4, I don't think it's an unreasonable burden. It's true that if we have compatibility solutions in place, we might never completely get rid of IPv4 until all IPv4-only apps are obsolete. But if the cost of maintaining such solutions is low, what's the harm? --001a11c2a68678905d051233e6c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 26, 2015 at 11:29 AM, James Woodyatt <jhw@nestlabs.com> wrote:
Yes, I recognize that entirely shi= fting the burden of supporting IPv4 onto the operating system developers, i= nto the unforeseeable future, while the network operators get a clean trans= ition to IPv6-only, can seem like a "solution" from certain bell-= shaped perspectives, but there is still a world outside that perspective wh= ere some of us are trying to make a living.
<= div>
As someone who does maintain a 464xlat implementation for the purpo= ses of supporting IPv4, I don't think it's an unreasonable burden.<= /div>

It's true that if we have compatibility soluti= ons in place, we might never completely get rid of IPv4 until all IPv4-only= apps are obsolete. But if the cost of maintaining such solutions is low, w= hat's the harm?
--001a11c2a68678905d051233e6c4-- From nobody Thu Mar 26 11:11:13 2015 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 93BD51A907F for ; Thu, 26 Mar 2015 11:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 J1OS9_FGT96Q for ; Thu, 26 Mar 2015 11:11:10 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BA81A9074 for ; Thu, 26 Mar 2015 11:11:10 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=49370 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YbCFG-0004Fo-O7; Thu, 26 Mar 2015 19:11:06 +0100 Date: Thu, 26 Mar 2015 19:11:06 +0100 From: Tore Anderson To: Lorenzo Colitti Message-ID: <20150326191106.42c1a9ac@envy.fud.no> In-Reply-To: References: <550F1F1F.3060703@cernet.edu.cn> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 18:11:11 -0000 * Lorenzo Colitti > On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt wrote: > > > Yes, I recognize that entirely shifting the burden of supporting > > IPv4 onto the operating system developers, into the unforeseeable > > future, while the network operators get a clean transition to > > IPv6-only, can seem like a "solution" from certain bell-shaped > > perspectives, but there is still a world outside that perspective > > where some of us are trying to make a living. > > As someone who does maintain a 464xlat implementation for the > purposes of supporting IPv4, I don't think it's an unreasonable > burden. Agreed. There's also the fact that the number of network operators in the world is many orders of magnitude higher than the number of operating system vendors, so even if the burden of maintaining a 464XLAT implementation in an operating system is higher than it is to maintain IPv4 access service in a network, so when you put it in in a bigger perspective, the total total burden gets *much* lower if the operating system vendors help out and allow the network operators to transition to IPv6-only. But maybe it doesn't have to be an additional burden for the OS vendors at all? If they follow our recommendation and kill 6to4 in their products, then maybe they could perhaps simply reallocate the resources that previously was spent on supporting 6to4 into supporting 464XLAT... Tore From nobody Thu Mar 26 11:22:58 2015 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 30DC41A9071 for ; Thu, 26 Mar 2015 11:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 Ci4WNllEGdTm for ; Thu, 26 Mar 2015 11:22:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EC7591A90C0 for ; Thu, 26 Mar 2015 11:22:53 -0700 (PDT) Received: from delong-dhcp214.delong.com (delong-dhcp14 [192.159.10.214]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2QILZpM003256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Mar 2015 11:21:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2QILZpM003256 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1427394095; bh=q47SKYKQyD1sp44DXO9R28cLdRs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=1Gud1LRbOaubVf5KLFQImUS//qmppjDrv2oi7Js6oMvDlT8sMMpL16q4nEKXIVuh5 2c/qDkLJkE920fcn2IG3KcumZh8sZFsWu63KX3fnmEjhuNsGK0d9B9P7HP8fgoVrTj ZtBAm2uGNm3uER5Dwo8hSvzuW1eoeqRJcs4UnKLE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Owen DeLong In-Reply-To: <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> Date: Thu, 26 Mar 2015 11:21:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <051725A5-2C80-4B9D-9395-7741FE5CDFF5@delong.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 26 Mar 2015 11:21:35 -0700 (PDT) Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 18:22:57 -0000 > On Mar 26, 2015, at 00:56 , Tore Anderson wrote: >=20 > * Philip Matthews >=20 >> What does the WG think? Should we use the "unnumbered" terms, or >> should we use just the "... with only link-local address" terms? Is >> it acceptable to mix the two sets of terms? >=20 > I didn't quite catch on the Meetecho if a final decision was reached > yesterday, but in case not here's my suggestions: >=20 > - Link-scoped (IPv6) interface >=20 > vs >=20 > - Global-scoped (IPv6) interface >=20 > The global scope includes the link scope, so the latter wouldn't mean > "no link local address". >=20 > (Or maybe it's better to say "globally" and "scope", my English isn't > good enough to know which of these nuances would be 100% correct.) >=20 Gramatically, I think you=E2=80=99re looking for globally-scoped. I question the value of applying these terms to interfaces as they = really apply to the address, not the interface. Owen From nobody Thu Mar 26 11:23:11 2015 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 EDEA31A9071 for ; Thu, 26 Mar 2015 11:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 nE7X10f4b9tE for ; Thu, 26 Mar 2015 11:23:08 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B591A90BF for ; Thu, 26 Mar 2015 11:23:06 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6DFB525D37D1 for ; Thu, 26 Mar 2015 18:23:04 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C1503C7705F for ; Thu, 26 Mar 2015 18:23:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id b_6j5dbM82cJ for ; Thu, 26 Mar 2015 18:23:02 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D8E21C7705C for ; Thu, 26 Mar 2015 18:23:01 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Bjoern A. Zeeb" In-Reply-To: <20150326191106.42c1a9ac@envy.fud.no> Date: Thu, 26 Mar 2015 18:23:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7EE952BA-AB35-4470-92C2-3003C6CC4B2D@lists.zabbadoz.net> References: <550F1F1F.3060703@cernet.edu.cn> <20150326191106.42c1a9ac@envy.fud.no> To: IPv6 Ops WG X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 18:23:10 -0000 > On 26 Mar 2015, at 18:11 , Tore Anderson wrote: >=20 > * Lorenzo Colitti >=20 >> On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt = wrote: >>=20 >>> Yes, I recognize that entirely shifting the burden of supporting >>> IPv4 onto the operating system developers, into the unforeseeable >>> future, while the network operators get a clean transition to >>> IPv6-only, can seem like a "solution" from certain bell-shaped >>> perspectives, but there is still a world outside that perspective >>> where some of us are trying to make a living. >>=20 >> As someone who does maintain a 464xlat implementation for the >> purposes of supporting IPv4, I don't think it's an unreasonable >> burden. >=20 > Agreed. >=20 > There's also the fact that the number of network operators in the = world > is many orders of magnitude higher than the number of operating system > vendors, so even if the burden of maintaining a 464XLAT implementation > in an operating system is higher than it is to maintain IPv4 access > service in a network, so when you put it in in a bigger perspective, > the total total burden gets *much* lower if the operating system > vendors help out and allow the network operators to transition to > IPv6-only. >=20 > But maybe it doesn't have to be an additional burden for the OS = vendors > at all? If they follow our recommendation and kill 6to4 in their > products, then maybe they could perhaps simply reallocate the = resources > that previously was spent on supporting 6to4 into supporting = 464XLAT... However if the network operators would encourage all their customers to = use IPv6 (traffic source and sink sides) . . . then everyone could just = switch and no one would have to care about the IPv4 noise anymore. Trying to solve this problem moving users to IPv6 by enforcing a = technical solution is using a hammer to slice a tomato. =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From nobody Thu Mar 26 11:23:35 2015 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 3292F1ACD9A for ; Thu, 26 Mar 2015 11:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 g98xfsKZCTGV for ; Thu, 26 Mar 2015 11:23:33 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d: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 C26BA1B29B0 for ; Thu, 26 Mar 2015 11:23:32 -0700 (PDT) Received: by qgep97 with SMTP id p97so110753734qge.1 for ; Thu, 26 Mar 2015 11:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SieAg/EOQmW0Jfl+Wj/QxM8k7ovAZb/TsfM1C43mhjU=; b=acYgtWupdlnW/Ww8hSom22kqSLhRcFDsZ+ZwXSs8a+5govQ5iOTHw3tUX6do+74C6i svgOx2O6lBeHsMEHNS5pNIaruHEe+I9DVEFala6SYofr2uDCqFn0O/N3I5UUgp97+Dhp 2Yh3TZtAnCyarbl/HYYxs8JJfWGxM4JdYho0jE5BtCvE5OjgRX6ri91gKiKoHMkMB6bm kkkWpCl8VW6vpkDivhx3Xuq1QZc+9z4JBglwk9CtKN84ymZIhc4O/mmR4XZ2ZCsWi813 y7FeJ0UmiTvRwE8gWQldMVxciziA2+tEC3Sug9LME7Dd3fE0zr9Q02OseIcqNuyOgskO xWjQ== 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-type; bh=SieAg/EOQmW0Jfl+Wj/QxM8k7ovAZb/TsfM1C43mhjU=; b=i3ameVpqOMDGhJJZuSboHqDFmhzH1ej4WziYbJ+h5ZS9iXEwP0QxZyHsiJ6S0PR8/6 mqFZiIvjixlNCQtcRxx9KPSvtoRQAz+rf678oYETmx9uZwdsQZv6ScwsI03jW5PZrz5q dBPJw3z8/bLOclHkJE07kzpjPtrQ+acysGsdkCT3AOJNov4ZQEwkja9Oijch3nJPQ6r4 42ENMRENcxNTCoXCJqoZbnDetmhocqc8IMrhSyxAuRRfVAVMWNHAEp5Y6D7wcyV7eBSa 03uIF5wriBcYlkzVU/ynTzh1jbpALsi8SrwfogPAFV2kWD6DHQCaFSN+v6/msCsPB3dC d7Ww== X-Gm-Message-State: ALoCoQkmqahe1Lo+Y/kbuLaCKD442U8dfYWqJVjE1w5Yc7ZPfexlGNYifR8Zs+iBLU9JqgnVqJx5 X-Received: by 10.140.42.13 with SMTP id b13mr19708598qga.43.1427394209243; Thu, 26 Mar 2015 11:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.72 with HTTP; Thu, 26 Mar 2015 11:23:09 -0700 (PDT) In-Reply-To: <20150326191106.42c1a9ac@envy.fud.no> References: <550F1F1F.3060703@cernet.edu.cn> <20150326191106.42c1a9ac@envy.fud.no> From: Erik Kline Date: Thu, 26 Mar 2015 13:23:09 -0500 Message-ID: To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 18:23:34 -0000 >> > Yes, I recognize that entirely shifting the burden of supporting >> > IPv4 onto the operating system developers, into the unforeseeable >> > future, while the network operators get a clean transition to >> > IPv6-only, can seem like a "solution" from certain bell-shaped >> > perspectives, but there is still a world outside that perspective >> > where some of us are trying to make a living. >> >> As someone who does maintain a 464xlat implementation for the >> purposes of supporting IPv4, I don't think it's an unreasonable >> burden. > > Agreed. Yeah, I think we're in a "perfect is the enemy of the good" situation. From nobody Thu Mar 26 11:36:09 2015 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 429FB1A92E0 for ; Thu, 26 Mar 2015 11:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EY-xo0vKdjn4 for ; Thu, 26 Mar 2015 11:36:00 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 74AC31B2A59 for ; Thu, 26 Mar 2015 11:35:55 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,474,1422939600"; d="scan'208";a="667135973" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Mar 2015 14:22:08 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 26 Mar 2015 14:35:53 -0400 From: "Howard, Lee" To: "Templin, Fred L" , Tore Anderson , Philip Matthews Date: Thu, 26 Mar 2015 14:35:53 -0400 Thread-Topic: [v6ops] Should we use "unnumbered" in IPv6? Thread-Index: AdBn87CxlUxyF/ZFTrSRWxNws0e3Cw== Message-ID: References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 18:36:02 -0000 On 3/26/15, 8:53 AM, "Templin, Fred L" wrote: >> We seemed to have rough consensus on link-local-address-only. > >The consensus alternative I recall seeing was "link-local-only" (three >words separated by two dashes). You're right. I abbreviated to LLA-only in my notes, but these were the options in Philip's slides: 1.=B3unnumbered interface=B2 2.=B3link-local-only interface=B2 3.=B3administratively unnumbered interface=B2 4.=B3locally-numbered interface=B2 5.=B3link-numbered interface=B2 6.=B3administratively link-local only interface=B2 I heard many people say, "Number two." Lee > >Thanks - Fred >fred.l.templin@boeing.com > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee >> Sent: Thursday, March 26, 2015 5:04 AM >> To: Tore Anderson; Philip Matthews >> Cc: v6ops list >> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >> >> We seemed to have rough consensus on link-local-address-only. >> >> Lee >> >> On 3/26/15, 2:56 AM, "Tore Anderson" wrote: >> >> >* Philip Matthews >> > >> >> What does the WG think? Should we use the "unnumbered" terms, or >> >> should we use just the "... with only link-local address" terms? Is >> >> it acceptable to mix the two sets of terms? >> > >> >I didn't quite catch on the Meetecho if a final decision was reached >> >yesterday, but in case not here's my suggestions: >> > >> >- Link-scoped (IPv6) interface >> > >> >vs >> > >> >- Global-scoped (IPv6) interface >> > >> >The global scope includes the link scope, so the latter wouldn't mean >> >"no link local address". >> > >> >(Or maybe it's better to say "globally" and "scope", my English isn't >> >good enough to know which of these nuances would be 100% correct.) >> > >> >Tore >> >who finally succumbed to the bikeshedding temptation >> > >> >_______________________________________________ >> >v6ops mailing list >> >v6ops@ietf.org >> >https://www.ietf.org/mailman/listinfo/v6ops >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or >> subject to copyright belonging to Time Warner Cable. This E-mail is >>intended solely for the use of the individual or entity to which it is >> addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, >> or action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >> received this E-mail in error, please notify the sender immediately and >>permanently delete the original and any copy of this E-mail and >> any printout. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Thu Mar 26 11:57:45 2015 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 0EA881A9026 for ; Thu, 26 Mar 2015 11:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 DzHL2B8TI5n9 for ; Thu, 26 Mar 2015 11:57:42 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 06BAF1A8791 for ; Thu, 26 Mar 2015 11:57:41 -0700 (PDT) Received: from delong-dhcp214.delong.com (delong-dhcp14 [192.159.10.214]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t2QIrkFr006200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Mar 2015 11:53:46 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t2QIrkFr006200 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1427396026; bh=gGz1SgcZiEafEfdITpJbkvM+xNc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=jpIvFFoWY4gyc91Gu30IRFi6BvAWaIjYst+x0ibtw7/vIfqWAMt+MfZOzh79BbDm3 qY0rzhBk0l3xlKm1roe7JDx5cVfIcLuqQmEHw65kX869MHEoNLITnQz35Sf/R+f8sz Tfq/F054nGLP4CXjTZitna70AdAjzakq01k24fvI= Content-Type: multipart/alternative; boundary="Apple-Mail=_B7976E8A-3982-44DD-A142-3AC5CFA74BDF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Owen DeLong In-Reply-To: Date: Thu, 26 Mar 2015 11:53:46 -0700 Message-Id: <9F564C11-AB8E-40E4-A04B-293CF3DB0E68@delong.com> References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> To: "Howard, Lee" X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 26 Mar 2015 11:53:46 -0700 (PDT) Archived-At: Cc: Tore Anderson , Philip Matthews , v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 18:57:44 -0000 --Apple-Mail=_B7976E8A-3982-44DD-A142-3AC5CFA74BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Limited to those choices, I would pick number 2 as well. However, as = stated previously, I prefer to remove the word interface as it really = isn=92t applicable. Owen > On Mar 26, 2015, at 11:35 , Howard, Lee = wrote: >=20 >=20 >=20 > On 3/26/15, 8:53 AM, "Templin, Fred L" > wrote: >=20 >>> We seemed to have rough consensus on link-local-address-only. >>=20 >> The consensus alternative I recall seeing was "link-local-only" = (three >> words separated by two dashes). >=20 > You're right. I abbreviated to LLA-only in my notes, but these were = the > options in Philip's slides: > 1.=B3unnumbered interface=B2 > 2.=B3link-local-only interface=B2 > 3.=B3administratively unnumbered interface=B2 > 4.=B3locally-numbered interface=B2 > 5.=B3link-numbered interface=B2 > 6.=B3administratively link-local only interface=B2 >=20 >=20 > I heard many people say, "Number two." >=20 > Lee >=20 >>=20 >> Thanks - Fred >> fred.l.templin@boeing.com >>=20 >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee >>> Sent: Thursday, March 26, 2015 5:04 AM >>> To: Tore Anderson; Philip Matthews >>> Cc: v6ops list >>> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >>>=20 >>> We seemed to have rough consensus on link-local-address-only. >>>=20 >>> Lee >>>=20 >>> On 3/26/15, 2:56 AM, "Tore Anderson" wrote: >>>=20 >>>> * Philip Matthews >>>>=20 >>>>> What does the WG think? Should we use the "unnumbered" terms, or >>>>> should we use just the "... with only link-local address" terms? = Is >>>>> it acceptable to mix the two sets of terms? >>>>=20 >>>> I didn't quite catch on the Meetecho if a final decision was = reached >>>> yesterday, but in case not here's my suggestions: >>>>=20 >>>> - Link-scoped (IPv6) interface >>>>=20 >>>> vs >>>>=20 >>>> - Global-scoped (IPv6) interface >>>>=20 >>>> The global scope includes the link scope, so the latter wouldn't = mean >>>> "no link local address". >>>>=20 >>>> (Or maybe it's better to say "globally" and "scope", my English = isn't >>>> good enough to know which of these nuances would be 100% correct.) >>>>=20 >>>> Tore >>>> who finally succumbed to the bikeshedding temptation >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>> This E-mail and any of its attachments may contain Time Warner Cable >>> proprietary information, which is privileged, confidential, or >>> subject to copyright belonging to Time Warner Cable. This E-mail is >>> intended solely for the use of the individual or entity to which it = is >>> addressed. If you are not the intended recipient of this E-mail, you >>> are hereby notified that any dissemination, distribution, copying, >>> or action taken in relation to the contents of and attachments to = this >>> E-mail is strictly prohibited and may be unlawful. If you have >>> received this E-mail in error, please notify the sender immediately = and >>> permanently delete the original and any copy of this E-mail and >>> any printout. >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_B7976E8A-3982-44DD-A142-3AC5CFA74BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Limited to those choices, I would pick number 2 as well. = However, as stated previously, I prefer to remove the word interface as = it really isn=92t applicable.

Owen

On Mar 26, 2015, at 11:35 , = Howard, Lee <lee.howard@twcable.com> wrote:



On 3/26/15, 8:53 AM, "Templin, Fred L" = <Fred.L.Templin@boeing.com> wrote:

We seemed to have rough consensus on = link-local-address-only.

The = consensus alternative I recall seeing was "link-local-only" (three
words separated by two dashes).

You're right. I abbreviated to LLA-only in my = notes, but these were the
options in Philip's = slides:
1.=B3unnumbered = interface=B2
2.=B3link-local-only = interface=B2
3.=B3administratively = unnumbered interface=B2
4.=B3locally-numbered = interface=B2
5.=B3link-numbered = interface=B2
6.=B3administratively = link-local only interface=B2


I heard many people say, = "Number two."

Lee


Thanks - = Fred
fred.l.templin@boeing.com

-----Original = Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] = On Behalf Of Howard, Lee
Sent: Thursday, March 26, 2015 = 5:04 AM
To: Tore Anderson; Philip Matthews
Cc:= v6ops list
Subject: Re: [v6ops] Should we use = "unnumbered" in IPv6?

We seemed to have = rough consensus on link-local-address-only.

Lee

On 3/26/15, 2:56 AM, "Tore = Anderson" <tore@fud.no> wrote:

* Philip Matthews = <philip_matthews@magma.ca>

What does the WG think?  Should we use the = "unnumbered" terms, or
should we use just the "... with = only link-local address" terms?  Is
it acceptable to = mix the two sets of terms?

I = didn't quite catch on the Meetecho if a final decision was reached
yesterday, but in case not here's my suggestions:

- Link-scoped (IPv6) interface
vs

- Global-scoped (IPv6) = interface

The global scope includes the = link scope, so the latter wouldn't mean
"no link local = address".

(Or maybe it's better to say = "globally" and "scope", my English isn't
good enough to = know which of these nuances would be 100% correct.)

Tore
who finally succumbed to the bikeshedding = temptation

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


This E-mail and = any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, = or
subject to copyright belonging to Time Warner Cable. = This E-mail is
intended solely for the use of the = individual or entity to which it is
addressed. If you are = not the intended recipient of this E-mail, you
are hereby = notified that any dissemination, distribution, copying,
or = action taken in relation to the contents of and attachments to this
E-mail is strictly prohibited and may be unlawful. If you = have
received this E-mail in error, please notify the = sender immediately and
permanently delete the original and = any copy of this E-mail and
any printout.

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


This E-mail and any of its = attachments may contain Time Warner Cable proprietary information, which = is privileged, confidential, or subject to copyright belonging to Time = Warner Cable. This E-mail is intended solely for the use of the = individual or entity to which it is addressed. If you are not the = intended recipient of this E-mail, you are hereby notified that any = dissemination, distribution, copying, or action taken in relation to the = contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please = notify the sender immediately and permanently delete the original and = any copy of this E-mail and any printout.

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

= --Apple-Mail=_B7976E8A-3982-44DD-A142-3AC5CFA74BDF-- From nobody Thu Mar 26 14:00:02 2015 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 AE2621B2EF9 for ; Thu, 26 Mar 2015 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 FKZ0JAzP3c3p for ; Thu, 26 Mar 2015 13:59:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EDF1A89E1 for ; Thu, 26 Mar 2015 13:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3550; q=dns/txt; s=iport; t=1427403599; x=1428613199; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:mime-version; bh=PQ9Axuq8lbczSUa6qNpJmN/U/gDEQZlSUvOpejjVzWY=; b=b/CH1ZCeLYgRyXRySfrKL/1lF176I2TaFH61n/htUYNoJWjYfrtVfBLV VQwXSJwUs8dN1Dp8JiLuJLUXH17eUzEyBfaZzI8L2JojrqAjKm3IucW/F NPOwnzHsFEt+6YygLj6HBgDilpXV4ZpBFoDnIqe1s7wVZkagqiKIzL+5R s=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQD/cRRV/49dJa1cgwZSWgSDDrRGjVuFcwKBYUwBAQEBAQF9hBQBAQEDASNLCwULAgEIGCoCAjIlAgQOBQ4GiBMIDbFahlOTZQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyiEeAeCaC+BFgWEUjmLRYFpgTIFT4QAggCBG4MwglqJQYNHIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,474,1422921600"; d="asc'?scan'208";a="407334491" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 26 Mar 2015 20:59:58 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2QKxwd6015301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 20:59:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 15:59:58 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: Discussion: IPv4 as a Service Thread-Index: AQHQaAfQjzft5CJX0ky6SJP3H9kyTQ== Date: Thu, 26 Mar 2015 20:59:57 +0000 Message-ID: <8EF27210-0C56-4F6D-81FD-B27EE34ED444@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.12.130] Content-Type: multipart/signed; boundary="Apple-Mail=_1B3680CA-B944-476E-A084-1CED1A062D7E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops-ads@tools.ietf.org" , V6ops Chairs , "softwire-chairs@tools.ietf.org" , "sunset4-ads@tools.ietf.org" , "sunset4-chairs@tools.ietf.org" Subject: Re: [v6ops] Discussion: IPv4 as a Service X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: IPv6 Ops WG List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:00:00 -0000 --Apple-Mail=_1B3680CA-B944-476E-A084-1CED1A062D7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It came to my attention last night that the link I sent yesterday is = read-only. This should allow you to comment (e.g., you can change the = document, but it shows up under change control; Lee, Joel, and I are = editors on it). = https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwoUWdz6psyEb4= 56c3A/edit?usp=3Dsharing I=E2=80=99d appreciate any comments you have on this being edited into = the file or in a reply to the list or to the chairs. > On Mar 25, 2015, at 6:48 PM, Fred Baker wrote: >=20 > Lee and I opened a discussion in the v6ops meeting today on a topic = that I believe that the IETF, in cooperation with the *NOGs, needs to = address. My slide is at = https://www.ietf.org/proceedings/92/slides/slides-92-v6ops-9.pptx. = Sunset4 and softwire chairs, please feel free to forward this to your = mailing lists. >=20 > In short, we are starting to see the deployment of IPv6-only networks. = In most cases, these are existing IPv4 networks that have become dual = stack, and are somewhere in the process of shutting IPv4 down. These = include Facebook, which (regardless of whether you view it as an = enterprise or a content network) has been public about the fact, several = mobile networks that treat IPv6-capable telephones as an IPv6-only = network and use 464xlat as an operational methodology dealing with that, = and some research networks, notably CERNET2, which has been running = IPv6-only for ten years now. We also see green-field networks, such as = Reliance JIO Infocomm Ltd; Suprita Sah presented on that topic today. >=20 > I am of the opinion, and there seemed to be agreement in the room, = that the Internet community would be well served if we collected = deployment experience with these technologies, and the considered advice = of deploying operators. We have tried to guide the deployment of IPv6, = and gathered experience and mitigations for that. Now, as IPv4 begins to = fade, we need to take a leadership role in that. >=20 > I have opened a document on Google Docs, and given folks the ability = to view it. That is at = https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwoUWdz6psyEb4= 56c3A. I have included an initial list of relevant technologies, and an = initial list of the questions that we would want discussed in experience = documents. I guarantee that there is an important question not asked, = and while I hope otherwise, there may be some technology I have = overlooked. So I invite discussion to flesh out that initial phase. --Apple-Mail=_1B3680CA-B944-476E-A084-1CED1A062D7E 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 iQEVAwUBVRRv7J9ieig10VPpAQKOJggAqNVIGqtp4pa3Hd5ue57opmO9Xbr6nSJE o4OIYb90lq4z9Iw0hRZxAZ+Dj4UEjqtwwZ9UOA4xdexNyodwYejxW+s4xSr+8dWz /1Ee7mQmXvhDxag0EeLUAZlVbMRdWSKp0vOY5A+tA+Rb9rwPIb5oIoB0EC9M69WU mXwyDt9QbnIfITiQfw2nchyXcGvJ5ivg9bBL0WCneSikg2RM2v6ZV+NnZexO5pyo ASBY3aupq2Zonp2F0LVRUUz0Wx1QTLFuZkkcALB7qa+BEa2mtZam3XFnYaSy5pzH jRuiocY6vdMlVKPIwuIlvYGs9gvyeWmsOD2/2u/n+XrsRZdX2abCHA== =rOJS -----END PGP SIGNATURE----- --Apple-Mail=_1B3680CA-B944-476E-A084-1CED1A062D7E-- From nobody Thu Mar 26 15:05:02 2015 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 C87281A0004 for ; Thu, 26 Mar 2015 15:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 xu5UKU1w0q7C for ; Thu, 26 Mar 2015 15:04:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081041B2FD2 for ; Thu, 26 Mar 2015 15:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2693; q=dns/txt; s=iport; t=1427407496; x=1428617096; h=from:to:subject:date:message-id:mime-version; bh=gLfb0df1TI+L9IzqL8WbnoHHgD5WIB5t8IwDy1tY9Cc=; b=gmCvoGf5BbZ+rTfyq/AKenHH8q9nsvXonetCATz3hxkdqQRIRoyPlCEd cOdF9K8V/CQBX7G/+FoaDPfYgmmQtOV1KVzv6wtPN78HK3vlNHnTSOj4A ZRSBnC/6mro4qqxAfIoVYZThFaL5oKJgQVk3hV/P/KNxNNmI6tXkBB2Vb 4=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQDpgRRV/40NJK1cgwZSXoMOwh+HP0wBAQEBAQF9hBsdBmgBSgI0JwQhiCENogiPTJpAAQEBAQEBBAEBAQEBAQEXBJMPL4EWBZBQgWmBMlSGAAGBGoMwiG2GdSKDboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,475,1422921600"; d="asc'?scan'208";a="135786429" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP; 26 Mar 2015 22:04:55 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2QM4s0w012262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Mar 2015 22:04:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 17:04:54 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: Verification on the list Thread-Index: AQHQaBDj34nGpgaLcE+byBta0PP2Kg== Date: Thu, 26 Mar 2015 22:04:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.12.130] Content-Type: multipart/signed; boundary="Apple-Mail=_CC4B6343-0B3A-4843-9559-FB025491AF65"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Verification on the list 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, 26 Mar 2015 22:05:00 -0000 --Apple-Mail=_CC4B6343-0B3A-4843-9559-FB025491AF65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have three drafts relevant to scalable use of translation in a = datacenter environment: https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-eam "Explicit Address Mappings for Stateless IP/ICMP Translation", tore, 2015-01-08 https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments", tore, 2014-12-18 https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat "SIIT-DC: Dual Translation Mode", tore, 2015-01-27, In discussion today in v6ops, we agreed to 1) adopt draft-anderson-v6ops-siit-eam as draft-ietf-v6ops-siit-eam 2) excise that algorithm from draft-ietf-v6ops-siit-dc and instead = insert a reference 3) similarly refer to -eam in draft-ietf-v6ops-siit-dc-2xlat The question for the house is =E2=80=9Cdo you agree with the above?=E2=80=9D= . The chairs will presume that we agree, but invite people to disabuse = us of the notion. Tore is looking for review of each and hopefully a co-author for each. = Please post reviews to the list. One comment raised in the WG meeting is that this is a minor update to = either RFC 6145 (giving the option of specifying a mapping between an = IPv4 and an IPv6 address as opposed to using an RFC 6052 IPv6 address) = or RFC 6146 (which already has the option of a static mapping, but is = fairly insistent on per-flow state as opposed to per-address = preconfiguration). It should not be construed as yet another mechanism, = calling for a blizzard of evaluation and guidance documents. If RFC 6145 = is updated at some point in the future, this document and any other = updates and errata would be incorporated into the revision. --Apple-Mail=_CC4B6343-0B3A-4843-9559-FB025491AF65 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 iQEVAwUBVRSChJ9ieig10VPpAQLnVQf9EqgMEKsR9NtVAUDtDolY4C7lKviXsmvR Tf2X1z/8m7IDA/eg/U8MramfoqseWUef6x1kFQ66jXdyLKce+u8dm0mRq3+kjVcA vi9CYJAaEKgnzCSFYsryJBrDbGFJb5pBt92p121pk/OtyYKDXNCTJ7q8M3mTMC3f 3bnNe65f/gAcxRH+72yOaZ67t7AOp4lrSRFh2Ob20TkemIW2e12gz0t7gA/pEZx0 8E+DiRUmAG7XXuAJ2OkjT3H7W3j9FRzvu85M3jNMJ7SL65cvCyzfEiBLATW6J9AN DVndeKyLvLSK12eXsnrXw3wVN9YB1F7Vhc8pvVqTrsXpTNPPN+mskA== =mNFR -----END PGP SIGNATURE----- --Apple-Mail=_CC4B6343-0B3A-4843-9559-FB025491AF65-- From nobody Thu Mar 26 15:07:58 2015 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 485CB1A0060 for ; Thu, 26 Mar 2015 15:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 0ZBWHXseD8Gp for ; Thu, 26 Mar 2015 15:07:53 -0700 (PDT) Received: from tor-smtp-02.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 830671A000F for ; Thu, 26 Mar 2015 15:07:53 -0700 (PDT) Received: from bas5-ottawa10-1177910549.dsl.bell.ca ([70.53.125.21] helo=[10.0.1.23]) by tor-smtp-02.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1YbFwL-0003fj-Kp; Thu, 26 Mar 2015 18:07:50 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-2-276385400 From: Philip Matthews In-Reply-To: <9F564C11-AB8E-40E4-A04B-293CF3DB0E68@delong.com> Date: Thu, 26 Mar 2015 18:07:47 -0400 Message-Id: References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> <9F564C11-AB8E-40E4-A04B-293CF3DB0E68@delong.com> To: "Howard, Lee" , "Templin, Fred L" , Tore Anderson , Owen DeLong X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas5-ottawa10-1177910549.dsl.bell.ca ([10.0.1.23]) [70.53.125.21] Archived-At: Cc: v6ops list Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 22:07:56 -0000 --Apple-Mail-2-276385400 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Indeed, there seemed to be a strong consensus for #2 in the WG session = yesterday. To address Owen's comment, our (the authors) intention was to have an = adjective phrase that could be applied to an interface or a link. As in = "Interface X is a link-local-only interface" or "Would you shutdown the = link-local-only interface?". The only problem is that I don't know what phrase we are going to use = for the converse. The draft currently talks about "numbered" vs = "unnumbered" interfaces -- if I replace the latter with = "link-local-only" then I am unsure what to use for the former. Sigh ... Philip On 2015-03-26, at 14:53 , Owen DeLong wrote: > Limited to those choices, I would pick number 2 as well. However, as = stated previously, I prefer to remove the word interface as it really = isn=92t applicable. >=20 > Owen >=20 >> On Mar 26, 2015, at 11:35 , Howard, Lee = wrote: >>=20 >>=20 >>=20 >> On 3/26/15, 8:53 AM, "Templin, Fred L" = wrote: >>=20 >>>> We seemed to have rough consensus on link-local-address-only. >>>=20 >>> The consensus alternative I recall seeing was "link-local-only" = (three >>> words separated by two dashes). >>=20 >> You're right. I abbreviated to LLA-only in my notes, but these were = the >> options in Philip's slides: >> 1.=B3unnumbered interface=B2 >> 2.=B3link-local-only interface=B2 >> 3.=B3administratively unnumbered interface=B2 >> 4.=B3locally-numbered interface=B2 >> 5.=B3link-numbered interface=B2 >> 6.=B3administratively link-local only interface=B2 >>=20 >>=20 >> I heard many people say, "Number two." >>=20 >> Lee >>=20 >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>>=20 >>>> -----Original Message----- >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, = Lee >>>> Sent: Thursday, March 26, 2015 5:04 AM >>>> To: Tore Anderson; Philip Matthews >>>> Cc: v6ops list >>>> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >>>>=20 >>>> We seemed to have rough consensus on link-local-address-only. >>>>=20 >>>> Lee >>>>=20 >>>> On 3/26/15, 2:56 AM, "Tore Anderson" wrote: >>>>=20 >>>>> * Philip Matthews >>>>>=20 >>>>>> What does the WG think? Should we use the "unnumbered" terms, or >>>>>> should we use just the "... with only link-local address" terms? = Is >>>>>> it acceptable to mix the two sets of terms? >>>>>=20 >>>>> I didn't quite catch on the Meetecho if a final decision was = reached >>>>> yesterday, but in case not here's my suggestions: >>>>>=20 >>>>> - Link-scoped (IPv6) interface >>>>>=20 >>>>> vs >>>>>=20 >>>>> - Global-scoped (IPv6) interface >>>>>=20 >>>>> The global scope includes the link scope, so the latter wouldn't = mean >>>>> "no link local address". >>>>>=20 >>>>> (Or maybe it's better to say "globally" and "scope", my English = isn't >>>>> good enough to know which of these nuances would be 100% correct.) >>>>>=20 >>>>> Tore >>>>> who finally succumbed to the bikeshedding temptation >>>>>=20 >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>>=20 >>>> This E-mail and any of its attachments may contain Time Warner = Cable >>>> proprietary information, which is privileged, confidential, or >>>> subject to copyright belonging to Time Warner Cable. This E-mail is >>>> intended solely for the use of the individual or entity to which it = is >>>> addressed. If you are not the intended recipient of this E-mail, = you >>>> are hereby notified that any dissemination, distribution, copying, >>>> or action taken in relation to the contents of and attachments to = this >>>> E-mail is strictly prohibited and may be unlawful. If you have >>>> received this E-mail in error, please notify the sender immediately = and >>>> permanently delete the original and any copy of this E-mail and >>>> any printout. >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >> This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail-2-276385400 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

The only problem is that I don't = know what phrase we are going to use for the converse. The draft = currently talks about "numbered" vs "unnumbered" interfaces -- if I = replace the latter with "link-local-only" then I am unsure what to use = for the former.  Sigh = ...

Philip

On = 2015-03-26, at 14:53 , Owen DeLong wrote:

Limited to those choices, I would pick number 2 as well. = However, as stated previously, I prefer to remove the word interface as = it really isn=92t applicable.

Owen

On Mar 26, 2015, at 11:35 , = Howard, Lee <lee.howard@twcable.com> wrote:



On 3/26/15, 8:53 AM, "Templin, Fred L" = <Fred.L.Templin@boeing.com> wrote:

We seemed to have rough consensus on = link-local-address-only.

The = consensus alternative I recall seeing was "link-local-only" (three
words separated by two dashes).

You're right. I abbreviated to LLA-only in my = notes, but these were the
options in Philip's = slides:
1.=B3unnumbered = interface=B2
2.=B3link-local-only = interface=B2
3.=B3administratively = unnumbered interface=B2
4.=B3locally-numbered = interface=B2
5.=B3link-numbered = interface=B2
6.=B3administratively = link-local only interface=B2


I heard many people say, = "Number two."

Lee


Thanks - = Fred
fred.l.templin@boeing.com

-----Original = Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] = On Behalf Of Howard, Lee
Sent: Thursday, March 26, 2015 = 5:04 AM
To: Tore Anderson; Philip Matthews
Cc:= v6ops list
Subject: Re: [v6ops] Should we use = "unnumbered" in IPv6?

We seemed to have = rough consensus on link-local-address-only.

Lee

On 3/26/15, 2:56 AM, "Tore = Anderson" <tore@fud.no> = wrote:

*= Philip Matthews <philip_matthews@magma.ca><= br class=3D"">
What = does the WG think?  Should we use the "unnumbered" terms, or
should we use just the "... with only link-local address" = terms?  Is
it acceptable to mix the two sets of = terms?

I didn't quite catch on = the Meetecho if a final decision was reached
yesterday, = but in case not here's my suggestions:

- = Link-scoped (IPv6) interface

vs

- Global-scoped (IPv6) interface

The global scope includes the link scope, so = the latter wouldn't mean
"no link local address".

(Or maybe it's better to say "globally" and = "scope", my English isn't
good enough to know which of = these nuances would be 100% correct.)

Torewho finally succumbed to the bikeshedding temptation

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


This E-mail and = any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, = or
subject to copyright belonging to Time Warner Cable. = This E-mail is
intended solely for the use of the = individual or entity to which it is
addressed. If you are = not the intended recipient of this E-mail, you
are hereby = notified that any dissemination, distribution, copying,
or = action taken in relation to the contents of and attachments to this
E-mail is strictly prohibited and may be unlawful. If you = have
received this E-mail in error, please notify the = sender immediately and
permanently delete the original and = any copy of this E-mail and
any printout.

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


This E-mail and any of its = attachments may contain Time Warner Cable proprietary information, which = is privileged, confidential, or subject to copyright belonging to Time = Warner Cable. This E-mail is intended solely for the use of the = individual or entity to which it is addressed. If you are not the = intended recipient of this E-mail, you are hereby notified that any = dissemination, distribution, copying, or action taken in relation to the = contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please = notify the sender immediately and permanently delete the original and = any copy of this E-mail and any printout.

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


= --Apple-Mail-2-276385400-- From nobody Thu Mar 26 15:11:10 2015 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 4ECB91A00BD for ; Thu, 26 Mar 2015 15:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 zhsgX0Oktvxk for ; Thu, 26 Mar 2015 15:11:07 -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 7ABCD1A0097 for ; Thu, 26 Mar 2015 15:11:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QMB4gG015549 for ; Thu, 26 Mar 2015 23:11:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3D38205233 for ; Thu, 26 Mar 2015 23:11:49 +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 DB21E205230 for ; Thu, 26 Mar 2015 23:11:49 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.14]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QMB2t3030568 for ; Thu, 26 Mar 2015 23:11:03 +0100 Message-ID: <551483F6.4050103@gmail.com> Date: Thu, 26 Mar 2015 17:11:02 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> <9F564C11-AB8E-40E4-A04B-293CF3DB0E68@delong.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 22:11:09 -0000 Le 26/03/2015 17:07, Philip Matthews a écrit : > Indeed, there seemed to be a strong consensus for #2 in the WG session > yesterday. > > To address Owen's comment, our (the authors) intention was to have an > adjective phrase that could be applied to an interface or a link. As in > "Interface X is a link-local-only interface" or "Would you shutdown the > link-local-only interface?". One can't say an interface is a link-local-only interface because there's at least the MAC address on it as well. You could say: don't ever shutdown the interface which doesnt have a global address on it, because it has at least one link-local address on it. Alex > > The only problem is that I don't know what phrase we are going to use > for the converse. The draft currently talks about "numbered" vs > "unnumbered" interfaces -- if I replace the latter with > "link-local-only" then I am unsure what to use for the former. Sigh ... > > Philip > > On 2015-03-26, at 14:53 , Owen DeLong wrote: > >> Limited to those choices, I would pick number 2 as well. However, as >> stated previously, I prefer to remove the word interface as it really >> isn’t applicable. >> >> Owen >> >>> On Mar 26, 2015, at 11:35 , Howard, Lee >> > wrote: >>> >>> >>> >>> On 3/26/15, 8:53 AM, "Templin, Fred L" >> > wrote: >>> >>>>> We seemed to have rough consensus on link-local-address-only. >>>> >>>> The consensus alternative I recall seeing was "link-local-only" (three >>>> words separated by two dashes). >>> >>> You're right. I abbreviated to LLA-only in my notes, but these were the >>> options in Philip's slides: >>> 1.³unnumbered interface² >>> 2.³link-local-only interface² >>> 3.³administratively unnumbered interface² >>> 4.³locally-numbered interface² >>> 5.³link-numbered interface² >>> 6.³administratively link-local only interface² >>> >>> >>> I heard many people say, "Number two." >>> >>> Lee >>> >>>> >>>> Thanks - Fred >>>> fred.l.templin@boeing.com >>>> >>>>> -----Original Message----- >>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Howard, Lee >>>>> Sent: Thursday, March 26, 2015 5:04 AM >>>>> To: Tore Anderson; Philip Matthews >>>>> Cc: v6ops list >>>>> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? >>>>> >>>>> We seemed to have rough consensus on link-local-address-only. >>>>> >>>>> Lee >>>>> >>>>> On 3/26/15, 2:56 AM, "Tore Anderson" >>>> > wrote: >>>>> >>>>>> * Philip Matthews >>>>> > >>>>>> >>>>>>> What does the WG think? Should we use the "unnumbered" terms, or >>>>>>> should we use just the "... with only link-local address" terms? Is >>>>>>> it acceptable to mix the two sets of terms? >>>>>> >>>>>> I didn't quite catch on the Meetecho if a final decision was reached >>>>>> yesterday, but in case not here's my suggestions: >>>>>> >>>>>> - Link-scoped (IPv6) interface >>>>>> >>>>>> vs >>>>>> >>>>>> - Global-scoped (IPv6) interface >>>>>> >>>>>> The global scope includes the link scope, so the latter wouldn't mean >>>>>> "no link local address". >>>>>> >>>>>> (Or maybe it's better to say "globally" and "scope", my English isn't >>>>>> good enough to know which of these nuances would be 100% correct.) >>>>>> >>>>>> Tore >>>>>> who finally succumbed to the bikeshedding temptation >>>>>> >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>>> This E-mail and any of its attachments may contain Time Warner Cable >>>>> proprietary information, which is privileged, confidential, or >>>>> subject to copyright belonging to Time Warner Cable. This E-mail is >>>>> intended solely for the use of the individual or entity to which it is >>>>> addressed. If you are not the intended recipient of this E-mail, you >>>>> are hereby notified that any dissemination, distribution, copying, >>>>> or action taken in relation to the contents of and attachments to this >>>>> E-mail is strictly prohibited and may be unlawful. If you have >>>>> received this E-mail in error, please notify the sender immediately and >>>>> permanently delete the original and any copy of this E-mail and >>>>> any printout. >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>> proprietary information, which is privileged, confidential, or >>> subject to copyright belonging to Time Warner Cable. This E-mail is >>> intended solely for the use of the individual or entity to which it >>> is addressed. If you are not the intended recipient of this E-mail, >>> you are hereby notified that any dissemination, distribution, >>> copying, or action taken in relation to the contents of and >>> attachments to this E-mail is strictly prohibited and may be >>> unlawful. If you have received this E-mail in error, please notify >>> the sender immediately and permanently delete the original and any >>> copy of this E-mail and any printout. >>> >>> _______________________________________________ >>> 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 Thu Mar 26 15:23:31 2015 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 DFC591A0282 for ; Thu, 26 Mar 2015 15:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 sBMFWI5SWmKV for ; Thu, 26 Mar 2015 15:23:27 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 A2F561A0302 for ; Thu, 26 Mar 2015 15:23:26 -0700 (PDT) Received: by oigz129 with SMTP id z129so17141426oig.1 for ; Thu, 26 Mar 2015 15:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=G0R4HSEge5DNsfbK2lyDNVdZtwJzmqSu06zeVq672fw=; b=BTbyjN8PV5pykgAu3Ds52U2dCnUCEgyevsQJSal4QBMJ9aJKcG12xhzm/VDlKqbIGo 4XQAQhbf2nkklfrLfL7ovb26w8AQYoAnEaqTjIqBcuozIxUD0PvgdjCSoSGs3jP8Ro04 Zh17tTSS50wP7rjuirWiNelN9V/xrzKCmeRCo= 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:content-type; bh=G0R4HSEge5DNsfbK2lyDNVdZtwJzmqSu06zeVq672fw=; b=hJQ6FZTa883Bo3LBPE0htirEMaeVR/wB1amU8aSSvaWsar1ZC12Wg7+atkUa+SOKMx rmGuTvLyMW2xvgcqt8ThhtWkSDViQbHOyw5XZRclGFZq1gT5KNwxzIT2ZjAkJuJCkr// X4AIS2x/kk3r1LdQFYdjUSoUwSudTLgWreDN1Ywdo3WeuKx4FbLoaDiHUQPnY+crHZBC 1LKJzHQEqUDYzuGLL7P7H+cUY70nTjbv6EBJyz4bCRjmhiwz78QqlI2uZE7x8sThLlLB oyZBbfu8oMTJw++yTJ4oMJdfyCdUgnENExFUrlKHRmBCt9nk6TbrA8tYRpH9NC0HE/2f LeLA== X-Gm-Message-State: ALoCoQmrf/9l3IUeseEunzVEa1EvulSuIQAmriJx9KC6ErLiiF5Pu7iO4FiTClLSxMIp0qLUpuvq MIME-Version: 1.0 X-Received: by 10.182.88.136 with SMTP id bg8mr14007727obb.86.1427408606124; Thu, 26 Mar 2015 15:23:26 -0700 (PDT) Received: by 10.76.150.2 with HTTP; Thu, 26 Mar 2015 15:23:25 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Thu, 26 Mar 2015 17:23:25 -0500 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=089e0111bd76eaf40e05123876f2 Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 22:23:29 -0000 --089e0111bd76eaf40e05123876f2 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 26, 2015 at 11:56 AM, Lorenzo Colitti wrote: > On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt wrote: > > Yes, I recognize that entirely shifting the burden of supporting IPv4 onto >> the operating system developers, into the unforeseeable future, while the >> network operators get a clean transition to IPv6-only, can seem like a >> "solution" from certain bell-shaped perspectives, but there is still a >> world outside that perspective where some of us are trying to make a living. >> > > As someone who does maintain a 464xlat implementation for the purposes of > supporting IPv4, I don't think it's an unreasonable burden. > > It's true that if we have compatibility solutions in place, we might never > completely get rid of IPv4 until all IPv4-only apps are obsolete. But if > the cost of maintaining such solutions is low, what's the harm? > I sympathize with your position, Lorenzo, I really do. Nevertheless, I also hope that Apple continues to resist the pressure it must be experiencing today to bring 464XLAT to iOS and OS X. Let me explain why. There is only one thing applying any pressure of any kind to developers currently using IPv4 literals in their application protocols: that their applications FAIL on Apple operating systems when those devices connect to IPv6-only+NAT64 networks. If Apple caves on this, as every other major vendor of mobile device operating systems has already caved, then developers will continue to rely on the viability of IPv4 literals as a protocol element for the foreseeable future. Those applications that do so will continue shipping with a reliance on 464XLAT for years to come, and they will continue to be used in critical processes for years after that when they are no longer under maintenance. There are people today scrubbing web pages and application protocols of their IPv4 literals, and they are mainly motivated to continue doing this by the need to deal with the fact that 464XLAT isn't universally deployed on all the major mobile platforms yet. Apple is the last noteworthy holdout. Publishing a BCP that entails telling developers that IPv4 literals are legitimate for use as application protocol elements is unnecessary and counter-productive to the interests of the IETF in promoting adoption of IPv6. Instead it would communicate to developers that IETF is capitulating on IPv6, that it doesn't really believe in it anymore, and application developers should feel safe ignoring it for the foreseeable future. -- james woodyatt Nest Labs, Communications Engineering --089e0111bd76eaf40e05123876f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 26, 2015 at 11:56 AM, Lorenzo Colitti <lorenzo@google.com>= wrote:
On Thu, Mar 2= 6, 2015 at 11:29 AM, James Woodyatt <jhw@nestlabs.com> wrote:= =C2=A0
=
Yes, I recognize that entirely shif= ting the burden of supporting IPv4 onto the operating system developers, in= to the unforeseeable future, while the network operators get a clean transi= tion to IPv6-only, can seem like a "solution" from certain bell-s= haped perspectives, but there is still a world outside that perspective whe= re some of us are trying to make a living.

As someone who does maintain a 464xlat implementation for the= purposes of supporting IPv4, I don't think it's an unreasonable bu= rden.

It's true that if we have compatibility = solutions in place, we might never completely get rid of IPv4 until all IPv= 4-only apps are obsolete. But if the cost of maintaining such solutions is = low, what's the harm?

I sympathize with your position, Lorenzo, I really d= o. Nevertheless, I also hope that Apple continues to resist the pressure it= must be experiencing today to bring 464XLAT to iOS and OS X. Let me explai= n why.

There is only one thing applying any pressure of any kind to developers cu= rrently using IPv4 literals in their application protocols: that their appl= ications FAIL on Apple operating systems when those devices connect to IPv6= -only+NAT64 networks.

If Apple caves on this, as every other major vendor of mob= ile device operating systems has already caved, then developers will contin= ue to rely on the viability of IPv4 literals as a protocol element for the = foreseeable future. Those applications that do so will continue shipping wi= th a reliance on 464XLAT for years to come, and they will continue to be us= ed in critical processes for years after that when they are no longer under= maintenance. There are people today scrubbing web pages and application pr= otocols of their IPv4 literals, and they are mainly motivated to continue d= oing this by the need to deal with the fact that 464XLAT isn't universa= lly deployed on all the major mobile platforms yet. Apple is the last notew= orthy holdout.

Publishing a BCP that entails telling developers that IPv4 literal= s are legitimate for use as application protocol elements is unnecessary an= d counter-productive to the interests of the IETF in promoting adoption of = IPv6. Instead it would communicate to developers that IETF is capitulating = on IPv6, that it doesn't really believe in it anymore, and application = developers should feel safe ignoring it for the foreseeable future.


--
james woodyatt <jhw@nestlabs.com>
Nest Labs,= Communications Engineering
--089e0111bd76eaf40e05123876f2-- From nobody Thu Mar 26 15:52:52 2015 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 C08241A049A for ; Thu, 26 Mar 2015 15:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 lh2Qs8bBwX6Z for ; Thu, 26 Mar 2015 15:52:49 -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 C650D1A19E3 for ; Thu, 26 Mar 2015 15:52:49 -0700 (PDT) Received: from dhcp-b52a.meeting.ietf.org (dhcp-b52a.meeting.ietf.org [31.133.181.42]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t2QMqcuU011637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 26 Mar 2015 22:52:40 GMT (envelope-from joelja@bogus.com) To: Merike Kaeo , "Eric Vyncke (evyncke)" references: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> From: joel jaeggli message-id: <55148DB6.9000204@bogus.com> Date: Thu, 26 Mar 2015 17:52:38 -0500 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0 mime-version: 1.0 in-reply-to: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nvaIhHqiSmJSmm6E2Cl7rQQhx8RPqGvcI" Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 26 Mar 2015 22:52:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nvaIhHqiSmJSmm6E2Cl7rQQhx8RPqGvcI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/26/15 9:47 AM, Merike Kaeo wrote: > Sounds good. >=20 > Warren/Joel=85I think resurrecting work on Why Operators Filter Fragmen= ts (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a = good idea :) it might be time, though I expect it won't be super warmly received eithe= r. > - merike >=20 > [list may get duplicate of this message since first attempt was blocked= due to using email I didn't use to subscribe to list=85..apologies in ad= vance] >=20 > On Mar 26, 2015, at 7:37 AM, "Eric Vyncke (evyncke)" wrote: >=20 >> Merike and Fernando, >> >> As I wrote a couple of comments on the methodology, I do not mind join= ing >> your test campaign ;-) >> >> Let's talk perhaps here in Dallas? >> >> -=E9ric >> >> On 17/03/15 15:10, "Merike Kaeo" wrote: >> >>> >>> On Mar 17, 2015, at 6:52 AM, Mikael Abrahamsson wr= ote: >>> >>>> On Mon, 16 Mar 2015, sthaug@nethelp.no wrote: >>>> >>>>>>> Lets live in the real world shall we? >>>>>>> >>>>>>> http://customer.comcast.com/help-and-support/internet/email-port-= 25-no >>>>>>> -longer-supported/ >>>>>> >>>>>> Ah, so the reason that an ISP would enforce ACLs is because of a >>>>>> protocol with a lousy security model that is only fixable (and eve= n >>>>>> then, not very) with the help of firewalls. Fair enough--I had >>>>>> developed a blind spot about this issue because it's been broken f= or >>>>>> so long and we've been reflexively avoiding the brokenness for so = long. >>>>>> >>>>>> But essentially what's happening here is that we are seeing a desi= gn >>>>>> flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we >>>>>> should stop reflexively working around this problem and seriously >>>>>> figure out how fix it, so that twenty years from now we no longer = need >>>>>> a broken layer 3. >>>>> >>>>> I'm all for that. However, I cannot afford to wait 20 years for a f= ix >>>>> to the problems. My priorities, as I see them: >>>>> >>>>> 1. Protect my network. >>>>> 2. Within reason, protect my customers. >>>>> 3. Move traffic to and from my customers, in a semi-optimal way. >>>> >>>> Please also add 4. "Protect the Internet from your customers". This = is >>>> something too many miss. >>> >>> I for one am really glad that we are getting operational reality inpu= t. >>> Thank you. FWIW, I'm sitting next to Fernando at a security conferen= ce >>> we are both at >>> and I had offered to help with this draft. This was a few months ago= =2E >>> What I see is that we are in need of some additional measurements and= that >>> will happen. I would love to see some added input on this list in ho= w to >>> improve measurements rather than the criticism of just how current >>> measurements >>> have been done. Collectively gathering operational realities is a go= od >>> thing for added input on how to deal with EHs. And FWIW, I am not in= >>> favor of >>> deprecating EHs since that is too drastic but we as a community have = to >>> understand where they are practically used and where they are dropped= for >>> reasons that some deem as necessary. >>> >>> - merike >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --nvaIhHqiSmJSmm6E2Cl7rQQhx8RPqGvcI 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUUjbYACgkQ8AA1q7Z/VrIlXwCdHjZ5ouEUUYPliDrF4hKymBCY ZaUAn1m2t1/+Db5RMn7ZAn92FJbVvrWY =YSxx -----END PGP SIGNATURE----- --nvaIhHqiSmJSmm6E2Cl7rQQhx8RPqGvcI-- From nobody Thu Mar 26 15:58:27 2015 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 682031A1A60 for ; Thu, 26 Mar 2015 15:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 vcOVCzMUyzUN for ; Thu, 26 Mar 2015 15:58:23 -0700 (PDT) Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by ietfa.amsl.com (Postfix) with SMTP id B3E331A1A7D for ; Thu, 26 Mar 2015 15:58:22 -0700 (PDT) Received: (qmail 3389 messnum 13078391 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 26 Mar 2015 22:58:21 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail02.svc.cra.dublin.eircom.net (qp 3389) with SMTP; 26 Mar 2015 22:58:21 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id 8NyH1q00R4BK5ly01NyMAX; Thu, 26 Mar 2015 22:58:21 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_3C637D70-7B69-4D4D-B320-9487ED4F03BD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ross Chandler In-Reply-To: Date: Thu, 26 Mar 2015 22:59:15 +0000 Message-Id: <8FBFF2D9-FE90-4B69-BFF7-0E3292C6F741@eircom.net> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> To: James Woodyatt X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 22:58:25 -0000 --Apple-Mail=_3C637D70-7B69-4D4D-B320-9487ED4F03BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Mar 2015, at 22:23, James Woodyatt wrote: >=20 >=20 > I sympathize with your position, Lorenzo, I really do. Nevertheless, I = also hope that Apple continues to resist the pressure it must be = experiencing today to bring 464XLAT to iOS and OS X. Let me explain why. >=20 > There is only one thing applying any pressure of any kind to = developers currently using IPv4 literals in their application protocols: = that their applications FAIL on Apple operating systems when those = devices connect to IPv6-only+NAT64 networks. >=20 > If Apple caves on this, as every other major vendor of mobile device = operating systems has already caved, then developers will continue to = rely on the viability of IPv4 literals as a protocol element for the = foreseeable future. Those applications that do so will continue shipping = with a reliance on 464XLAT for years to come, and they will continue to = be used in critical processes for years after that when they are no = longer under maintenance. There are people today scrubbing web pages and = application protocols of their IPv4 literals, and they are mainly = motivated to continue doing this by the need to deal with the fact that = 464XLAT isn't universally deployed on all the major mobile platforms = yet. Apple is the last noteworthy holdout. >=20 > Publishing a BCP that entails telling developers that IPv4 literals = are legitimate for use as application protocol elements is unnecessary = and counter-productive to the interests of the IETF in promoting = adoption of IPv6. Instead it would communicate to developers that IETF = is capitulating on IPv6, that it doesn=E2=80=99t really believe in it = anymore, and application developers should feel safe ignoring it for the = foreseeable future. IPv6-only+NAT64 networks are not deployed by ISPs. Without the CLAT the = only option is IPv4+IPv6. There=E2=80=99s roughly the same low incentive = to fix IPv4 literals with IPv4+IPv6 as with 464xlat. That doesn=E2=80=99t makes sense as Apple=E2=80=99s motivation for not = yet supporting 464xlat. It just harms IPv6 deployment.=20 Ross --Apple-Mail=_3C637D70-7B69-4D4D-B320-9487ED4F03BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26 Mar 2015, at 22:23, James Woodyatt <jhw@nestlabs.com> = wrote:


I sympathize with your position, = Lorenzo, I really do. Nevertheless, I also hope that Apple continues to = resist the pressure it must be experiencing today to bring 464XLAT to = iOS and OS X. Let me explain why.

There is only one thing = applying any pressure of any kind to developers currently using IPv4 = literals in their application protocols: that their applications FAIL on = Apple operating systems when those devices connect to IPv6-only+NAT64 = networks.

If Apple caves on this, as every other major = vendor of mobile device operating systems has already caved, then = developers will continue to rely on the viability of IPv4 literals as a = protocol element for the foreseeable future. Those applications that do = so will continue shipping with a reliance on 464XLAT for years to come, = and they will continue to be used in critical processes for years after = that when they are no longer under maintenance. There are people today = scrubbing web pages and application protocols of their IPv4 literals, = and they are mainly motivated to continue doing this by the need to deal = with the fact that 464XLAT isn't universally deployed on all the major = mobile platforms yet. Apple is the last noteworthy holdout.

Publishing a BCP that entails telling developers = that IPv4 literals are legitimate for use as application protocol = elements is unnecessary and counter-productive to the interests of the = IETF in promoting adoption of IPv6. Instead it would communicate to = developers that IETF is capitulating on IPv6, that it doesn=E2=80=99t = really believe in it anymore, and application developers should feel = safe ignoring it for the foreseeable = future.

IPv6-only+NAT64 networks are not deployed by ISPs. = Without the CLAT the only option is IPv4+IPv6. There=E2=80=99s roughly = the same low incentive to fix IPv4 literals with IPv4+IPv6 as with = 464xlat.

That doesn=E2=80=99t makes = sense as Apple=E2=80=99s motivation for not yet supporting 464xlat. It =  just harms IPv6 deployment. 


Ross

= --Apple-Mail=_3C637D70-7B69-4D4D-B320-9487ED4F03BD-- From nobody Thu Mar 26 15:58:42 2015 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 9AD591A1B20 for ; Thu, 26 Mar 2015 15:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eUblKpSX1HZK for ; Thu, 26 Mar 2015 15:58:38 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5543F1A1B12 for ; Thu, 26 Mar 2015 15:58:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BF926A1; Thu, 26 Mar 2015 23:58:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1427410714; bh=wV0OZg6dw0kBNtOnhAC/P9atqrU+hYKFelrUdgiVwjg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oRFLIVBvRhFl4MizJnUOeFa8VohtM2LML4Qe3PNlesRWbFG9wFmmDjgfWBiHs60+9 Df2s9EzBAVNXtVkQCZ+2XGS/W6jtmvQoN7ci1fm1+dROvXjhc3J4clx5cN0wKE+3Hq 9y9Lvo9kdBSLY4HF0fg6T2L3v6hcSn5J47x+1YyU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B700A9F; Thu, 26 Mar 2015 23:58:34 +0100 (CET) Date: Thu, 26 Mar 2015 23:58:34 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <551483F6.4050103@gmail.com> Message-ID: References: <40CC9375-B748-4A37-B9E5-FEE3003C1DC4@magma.ca> <20150326085644.47d1e85a@echo.ms.redpill-linpro.com> <2134F8430051B64F815C691A62D9831832E2A5C5@XCH-BLV-504.nw.nos.boeing.com> <9F564C11-AB8E-40E4-A04B-293CF3DB0E68@delong.com> <551483F6.4050103@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? 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, 26 Mar 2015 22:58:39 -0000 On Thu, 26 Mar 2015, Alexandru Petrescu wrote: > One can't say an interface is a link-local-only interface because > there's at least the MAC address on it as well. MAC address is at L2, we're talking L3 here. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 26 16:44:39 2015 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 DD4ED1A6F3A for ; Thu, 26 Mar 2015 16:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 746f3gt8R-1v for ; Thu, 26 Mar 2015 16:44:36 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.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 BF19C1A6F33 for ; Thu, 26 Mar 2015 16:44:36 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id B3B58DA00B8; Thu, 26 Mar 2015 23:44:36 +0000 (UTC) Received: from [IPv6:2001:67c:1231:998:10e8:9613:32d4:700c] (31.130.238.53) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 26 Mar 2015 16:44:36 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 26 Mar 2015 18:44:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> To: James Woodyatt X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.53] Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 26 Mar 2015 23:44:38 -0000 On Mar 26, 2015, at 5:23 PM, James Woodyatt wrote: > If Apple caves on this, as every other major vendor of mobile device = operating systems has already caved, then developers will continue to = rely on the viability of IPv4 literals as a protocol element for the = foreseeable future. Just to be clear, am I correct in understanding that this is only an = issue for IPv4 literals sent to from the IPv4-only service provider to = the IPv6-only host? It seems to me that there is no way to make it = work in the other direction. From nobody Thu Mar 26 17:36:57 2015 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 D25941A87F1 for ; Thu, 26 Mar 2015 17:36:55 -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 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 eRyTczXdR8N6 for ; Thu, 26 Mar 2015 17:36:53 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [46.182.8.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 CEB021A1B34 for ; Thu, 26 Mar 2015 17:36:52 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org ([IPv6:2001:4d68:2002:100:0:0:0:16b]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t2R0ZWNo078261 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2015 00:35:33 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:16b] claimed to be crumpet.foobar.org Message-ID: <5514A5D4.9080506@foobar.org> Date: Fri, 27 Mar 2015 00:35:32 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: joel jaeggli , Merike Kaeo , "Eric Vyncke (evyncke)" References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <55148DB6.9000204@bogus.com> In-Reply-To: <55148DB6.9000204@bogus.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 27 Mar 2015 00:36:56 -0000 On 26/03/2015 22:52, joel jaeggli wrote: > On 3/26/15 9:47 AM, Merike Kaeo wrote: >> Sounds good. >> >> Warren/Joel…I think resurrecting work on Why Operators Filter Fragments (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a good idea :) > > it might be time, though I expect it won't be super warmly received either. I'm interested in seeing this document revived if the data in draft-gont-v6ops-ipv6-ehs-in-real-world can establish with reasonable confidence that there is a problem. If a problem is established, then the scope of this document should be widened to include all ipv6 EHs rather than solely concentrating on fragments. Nick From nobody Thu Mar 26 22:16:51 2015 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 CE5591A8ABB for ; Thu, 26 Mar 2015 22:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 RqdVTu4mEEWB for ; Thu, 26 Mar 2015 22:16:48 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA731A005F for ; Thu, 26 Mar 2015 22:16:47 -0700 (PDT) Received: from [127.0.0.1] (unknown [31.133.138.159]) by centos (Coremail) with SMTP id AQAAf3DrJAVb5hRVFhIpAA--.677S5; Fri, 27 Mar 2015 13:10:54 +0800 (CST) Message-ID: <5514E616.7070005@cernet.edu.cn> Date: Fri, 27 Mar 2015 13:09:42 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ross Chandler References: <550F1F1F.3060703@cernet.edu.cn> <8FBFF2D9-FE90-4B69-BFF7-0E3292C6F741@eircom.net> In-Reply-To: <8FBFF2D9-FE90-4B69-BFF7-0E3292C6F741@eircom.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3DrJAVb5hRVFhIpAA--.677S5 X-Coremail-Antispam: 1UD129KBjvJXoW7KFWxJFyDXF15Xw13uw18AFb_yoW5Jr4UpF W3Kr1Skw4xGr17tw12qw18GFn0kryktwsrAwn8Xr1kC34qyFnFyF48tr1fJa47JrZ5KF1j qrWjkayUC3WUZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUDKb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW8Jr 0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj 6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr 0_Gr1lF7xvr2IY64vIr41l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC2 0s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMI IF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF 0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87 Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUg0eHDUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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: Fri, 27 Mar 2015 05:16:50 -0000 Ross Chandler 写é“: > >> On 26 Mar 2015, at 22:23, James Woodyatt > > wrote: >> >> >> >> I sympathize with your position, Lorenzo, I really do. Nevertheless, >> I also hope that Apple continues to resist the pressure it must be >> experiencing today to bring 464XLAT to iOS and OS X. Let me explain why. >> >> There is only one thing applying any pressure of any kind to >> developers currently using IPv4 literals in their application >> protocols: that their applications FAIL on Apple operating systems >> when those devices connect to IPv6-only+NAT64 networks. >> >> If Apple caves on this, as every other major vendor of mobile device >> operating systems has already caved, then developers will continue to >> rely on the viability of IPv4 literals as a protocol element for the >> foreseeable future. Those applications that do so will continue >> shipping with a reliance on 464XLAT for years to come, and they will >> continue to be used in critical processes for years after that when >> they are no longer under maintenance. There are people today >> scrubbing web pages and application protocols of their IPv4 literals, >> and they are mainly motivated to continue doing this by the need to >> deal with the fact that 464XLAT isn't universally deployed on all the >> major mobile platforms yet. Apple is the last noteworthy holdout. >> >> Publishing a BCP that entails telling developers that IPv4 literals >> are legitimate for use as application protocol elements is >> unnecessary and counter-productive to the interests of the IETF in >> promoting adoption of IPv6. Instead it would communicate to >> developers that IETF is capitulating on IPv6, that it doesn’t really >> believe in it anymore, and application developers should feel safe >> ignoring it for the foreseeable future. > > IPv6-only+NAT64 networks are not deployed by ISPs. Without the CLAT > the only option is IPv4+IPv6. There’s roughly the same low incentive > to fix IPv4 literals with IPv4+IPv6 as with 464xlat. > > That doesn’t makes sense as Apple’s motivation for not yet supporting > 464xlat. It just harms IPv6 deployment. +1. xing > > > Ross > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 26 22:17:05 2015 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 0B6071A8FD2 for ; Thu, 26 Mar 2015 22:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 eKsR-K_ymKIA for ; Thu, 26 Mar 2015 22:17:02 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3957D1A005F for ; Thu, 26 Mar 2015 22:17:02 -0700 (PDT) Received: from [127.0.0.1] (unknown [31.133.138.159]) by centos (Coremail) with SMTP id AQAAf3AbtwZX5hRVFRIpAA--.553S5; Fri, 27 Mar 2015 13:10:52 +0800 (CST) Message-ID: <5514E437.9080500@cernet.edu.cn> Date: Fri, 27 Mar 2015 13:01:43 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Lorenzo Colitti References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3AbtwZX5hRVFRIpAA--.553S5 X-Coremail-Antispam: 1UD129KBjvdXoWrKF4ruw47XFWkAw4DGF15urg_yoWkXwb_uF y0kFs3Xr4UZrZxKr4qyrn0yryfJr1jgr1UJFyDtr47ur17ZF1DJr4DAFW7ZF1rWa4UJr1D Grn5Gr4jyFW7AjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb8xYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWx JwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJV WxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvEwIxGrwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I 3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIx AIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAI cVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4 A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07j189NUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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: Fri, 27 Mar 2015 05:17:04 -0000 Lorenzo Colitti 写é“: > On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt > wrote: > > Yes, I recognize that entirely shifting the burden of supporting > IPv4 onto the operating system developers, into the unforeseeable > future, while the network operators get a clean transition to > IPv6-only, can seem like a "solution" from certain bell-shaped > perspectives, but there is still a world outside that perspective > where some of us are trying to make a living. > > > As someone who does maintain a 464xlat implementation for the purposes > of supporting IPv4, I don't think it's an unreasonable burden. > > It's true that if we have compatibility solutions in place, we might > never completely get rid of IPv4 until all IPv4-only apps are > obsolete. But if the cost of maintaining such solutions is low, what's > the harm? +1 xing > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Mar 27 06:50:41 2015 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 02A1E1ACE0D for ; Fri, 27 Mar 2015 06:50:38 -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_HELO_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 fzuH4V0NLLjP for ; Fri, 27 Mar 2015 06:50:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974F41ACE5E for ; Fri, 27 Mar 2015 06:50:11 -0700 (PDT) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB586.namprd04.prod.outlook.com (10.141.196.145) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 27 Mar 2015 13:49:50 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0118.022; Fri, 27 Mar 2015 13:49:50 +0000 From: "Metzler, Dan J" To: Merike Kaeo , Jen Linkova Thread-Topic: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) Thread-Index: AQHQWs7kouJtZq0s+0K1fEm+dExqtp0Y1R8AgAAPIACAABdXAIAAYkoAgAAEeoCAAAowgIAABUOAgAACKYCAAATDgIAA9HuYgAC4p4CAA6sygIAADNEAgAAfPQCAAAbPAIAAJ/0AgAABwICAACuMgIAAC+CAgAFYmACAAAUYAIAOLHKAgAAC2oCAAAF0gIAADKaAgAFq4BA= Date: Fri, 27 Mar 2015 13:49:49 +0000 Message-ID: References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> In-Reply-To: <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:0:e50:1001:a156:b2da:fd8f:a40] authentication-results: merike.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB586; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(164054003)(377454003)(24454002)(77096005)(76576001)(74316001)(93886004)(106116001)(15975445007)(102836002)(92566002)(2656002)(87936001)(99286002)(86362001)(88552001)(76176999)(50986999)(33656002)(2900100001)(2950100001)(77156002)(54356999)(62966003)(19580405001)(122556002)(230783001)(89122001)(19580395003)(75432002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB586; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO2PR04MB586; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB586; x-forefront-prvs: 0528942FD8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 13:49:49.8284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB586 Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 27 Mar 2015 13:50:38 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Merike Kaeo > Sent: Thursday, March 26, 2015 10:38 AM > To: Jen Linkova > Cc: silvia.hagen@sunny.ch; fgont@si6networks.com; v6ops@ietf.org; > fernando@gont.com.ar > Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notific= ation > for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) >=20 >=20 > On Mar 26, 2015, at 7:53 AM, Jen Linkova wrote: >=20 > > On Thu, Mar 26, 2015 at 3:47 PM, Merike Kaeo wrote: > >> Sounds good. > >> > >> Warren/Joel...I think resurrecting work on Why Operators Filter > >> Fragments > >> (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a > >> good idea :) > > > > Do we really need to resurrect a draft which covers one particular EH > > filtering while we are working on a draft which covers EHs in general? >=20 > :) There's the option of resurrecting and expanding on the document tha= t > describes why EHs in general are dropped and does not only speak to > Fragmentation Headers. >=20 > IFF there is interest in more work on general case of Why Operators Filte= r EHs - > probably best to keep as separate document. I think. I was debating wit= h > myself as to whether I'd prefer to read it in one single document (here i= s what's > measured, here's why EHs are dropped in practice by operators, advice on > operational practices). =20 I'd like to see information about "why" Operators Filter EHs as well, and t= o what extent each operator in the survey does this. I don't think that's = represented well in any past discussions or documents. However, that infor= mation can't be gathered by just probing to see where they are dropped. Th= ere would have to be significant effort put into tracking down the "why". I think we all know there is a lot of fear and uncertainty focused around E= Hs in general. (Some of it might be warranted, and some not.) I'm a littl= e apprehensive about drawing conclusions simply based on the fact that filt= ering exists, without regard to the consideration of why the filtering happ= ens, and who is pushing the filtering. A more constructive outcome, if a problem exists, would lead to only filter= ing or whitelisting EHs of specific desired types, and perhaps recommendati= ons of when it is appropriate to filter a specific EH, and then ultimately = when it's not appropriate to filter EHs. =20 The ultimate question is, should such an effort show that there is a proble= m, will anything actually be done to try to improve the situation. If that= is not part of the goal, then I have a lot less interest. Thanks, - Dan Metzler From nobody Fri Mar 27 07:01:02 2015 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 407211ACE8C for ; Fri, 27 Mar 2015 07:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 4HOIwjV7skAh for ; Fri, 27 Mar 2015 07:00:52 -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 A9B4D1ACE6F for ; Fri, 27 Mar 2015 07:00:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2RE0nKi023412 for ; Fri, 27 Mar 2015 15:00:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 09AE8200DC0 for ; Fri, 27 Mar 2015 15:01:36 +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 00AE920547F for ; Fri, 27 Mar 2015 15:01:36 +0100 (CET) Received: from [127.0.0.1] ([132.166.85.14]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2RE0ks4002742 for ; Fri, 27 Mar 2015 15:00:48 +0100 Message-ID: <5515628D.7020306@gmail.com> Date: Fri, 27 Mar 2015 09:00:45 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] why IPv6 EHs in the Real World 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: Fri, 27 Mar 2015 14:00:54 -0000 Le 27/03/2015 08:49, Metzler, Dan J a écrit : > > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Merike Kaeo >> Sent: Thursday, March 26, 2015 10:38 AM >> To: Jen Linkova >> Cc: silvia.hagen@sunny.ch; fgont@si6networks.com; v6ops@ietf.org; >> fernando@gont.com.ar >> Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification >> for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) >> >> >> On Mar 26, 2015, at 7:53 AM, Jen Linkova wrote: >> >>> On Thu, Mar 26, 2015 at 3:47 PM, Merike Kaeo wrote: >>>> Sounds good. >>>> >>>> Warren/Joel...I think resurrecting work on Why Operators Filter >>>> Fragments >>>> (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a >>>> good idea :) >>> >>> Do we really need to resurrect a draft which covers one particular EH >>> filtering while we are working on a draft which covers EHs in general? >> >> :) There's the option of resurrecting and expanding on the document that >> describes why EHs in general are dropped and does not only speak to >> Fragmentation Headers. >> >> IFF there is interest in more work on general case of Why Operators Filter EHs - >> probably best to keep as separate document. I think. I was debating with >> myself as to whether I'd prefer to read it in one single document (here is what's >> measured, here's why EHs are dropped in practice by operators, advice on >> operational practices). > > I'd like to see information about "why" Operators Filter EHs as well, I dont work for an Operator, but it is reasonable to expect operators to filter Routing Headers. These are not used by any application and open a signficant security risk. I personally see it as a valuable feature (RH) for flexibility, yet often operators think differently, sometimes to end-user benefit. Alex and to what extent each operator in the survey does this. I don't think that's represented well in any past discussions or documents. However, that information can't be gathered by just probing to see where they are dropped. There would have to be significant effort put into tracking down the "why". > I think we all know there is a lot of fear and uncertaintyfocused around EHs in general. (Some of it might be warranted, and some not.) I'm a little apprehensive about drawing conclusions simply based on the fact that filtering exists, without regard to the consideration of why the filtering happens, and who is pushing the filtering. > > A more constructive outcome, if a problem exists, would lead to only filtering or whitelisting EHs of specific desired types, and perhaps recommendations of when it is appropriate to filter a specific EH, and then ultimately when it's not appropriate to filter EHs. > > The ultimate question is, should such an effort show that there is a problem, will anything actually be done to try to improve the situation. If that is not part of the goal, then I have a lot less interest. > > Thanks, > > - Dan Metzler > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Mar 27 08:02:18 2015 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 2B60A1ACEE8 for ; Fri, 27 Mar 2015 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 icmed-KMcspb for ; Fri, 27 Mar 2015 08:02:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5C21ACEDC for ; Fri, 27 Mar 2015 08:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1064; q=dns/txt; s=iport; t=1427468527; x=1428678127; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rhIPeEasFjPQooa7s48905vDmsSRwhdH14df0ftE3c4=; b=Np4eLcyMj40VFLBHDUNumNmJ5Ok/7JOMqZ2JxWiZTasocMpGIaa+ajYW RYT2syUNRyFPKaUFvsNhBIfbJPQ7x47XBNz7ysIVLcKtojRKPxnwCzHTA 7a8YMoluW4Ilka5DKZju1gY9CWiu2E0FIbsax1xlsiIQ5DcoqnrsxQQct k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQB5cBVV/5tdJa1cgwaBLASDD8giAhyBG0wBAQEBAQF9hBUBAQQjEVUCAQgYAgImAgICHxEVEAIEARKIGwMRshKUXQ2FQwEBAQEBAQEBAQEBAQEBAQEBAQEZgSGKB4JHghYigmiBRQEEkFeII4FNjgaGKyKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,479,1422921600"; d="scan'208";a="407194439" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 27 Mar 2015 15:02:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2RF260s006088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 15:02:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.130]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 10:02:02 -0500 From: "Eric Vyncke (evyncke)" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] why IPv6 EHs in the Real World Thread-Index: AQHQaJaQDEeJX1IhFkuJa08fNykKPp0wbMkA Date: Fri, 27 Mar 2015 15:02:01 +0000 Message-ID: References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> <5515628D.7020306@gmail.com> In-Reply-To: <5515628D.7020306@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.89.11.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] why IPv6 EHs in the Real World 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: Fri, 27 Mar 2015 15:02:10 -0000 DQoNCk9uIDI3LzAzLzE1IDA5OjAwLCAiQWxleGFuZHJ1IFBldHJlc2N1IiA8YWxleGFuZHJ1LnBl dHJlc2N1QGdtYWlsLmNvbT4NCndyb3RlOg0KPg0KPkkgZG9udCB3b3JrIGZvciBhbiBPcGVyYXRv ciwgYnV0IGl0IGlzIHJlYXNvbmFibGUgdG8gZXhwZWN0IG9wZXJhdG9ycyB0bw0KPmZpbHRlciBS b3V0aW5nIEhlYWRlcnMuDQoNCkFuZCBibG9ja2luZyBhbnkgbmV3IGRlcGxveW1lbnQgb2YgbW9i aWxlIElQdjYgb3IgYW5vdGhlciBvbmU/IEkgZ3Vlc3MNCnRoYXQgeW91IGFjdHVhbGx5IHdhbnRl ZCB0byB3cml0ZSBSSC0wIChSRkMgNTA5NSkgOi0pDQoNCj4NCj5UaGVzZSBhcmUgbm90IHVzZWQg YnkgYW55IGFwcGxpY2F0aW9uIGFuZCBvcGVuIGEgc2lnbmZpY2FudCBzZWN1cml0eSByaXNrLg0K DQpGb3IgYSB0cmFuc2l0IHByb3ZpZGVyIHdoaWNoIGRvZXMgbm90IG5lZWQgdG8gaW5zcGVjdC9w YXJzZSB0aGUgRUgsIHRoZQ0KcmlzayBpcyByZWR1Y2VkIHRvIHdlbGwgaWRlbnRpZmllZCB0aHJl YXRzOg0KLSBIYkggY2F1c2luZyBDUFUgdXNhZ2UgKGJ1dCBjb250cm9sIHBsYW5lIHBvbGljaW5n IG9yIHNpbXBseSBpZ25vcmluZw0KdGhlbSBhcmUgZ29vZCBtaXRpZ2F0aW9uIHRlY2huaXF1ZXMp DQotIElGIGEgbGF5ZXItNCBBQ0wgaXMgcmVxdWlyZWQsIFRIRU4gaW5kZWVkIEVIIHBhcnNpbmcg Y2FuIGNhdXNlIHByb2JsZW0NCm9uIHNvbWUgcm91dGVycy4NCg0KSW4gc2hvcnQsIHRoaXMgdG9w aWMgaXMgb2YgaGlnaCBpbnRlcmVzdA0KDQotw6lyaWMNCg0K From nobody Fri Mar 27 08:24:00 2015 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 0A5131ACDF1 for ; Fri, 27 Mar 2015 08:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 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_27=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 3E4HIbec85v3 for ; Fri, 27 Mar 2015 08:23:51 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53F01A802A for ; Fri, 27 Mar 2015 08:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3380; q=dns/txt; s=iport; t=1427469830; x=1428679430; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vtILlCakn9DnGcOf5ERcTERp6CNS+4XOSanJiU1EAIA=; b=GYq5ar82d9P/XBXUEKqXvO3izuji0oSbbr8RzUXXnawW5VuD1cg/U1nY Psc3tOhdQhAJncx6e76IvQuRvedgTzTl1l9FxBsWvCYeTrLg9p3AtOY6C Dy9PjbtEdBpV+GzM5ch2Y0y5NXKGeE/+x13jZS1OPKKvfrYuwua7qtXqa Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B8BAAQdRVV/5xdJa1ZAw6CeIEsBIMPwFgGh0QCHIEbOBQBAQEBAQEBfIQVAQEDASMRQwIQAgECBhoCHwcCAgIwFRACBAENBYgnCLIfmisBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKB4RFGAsQBwQNgleBRQEEkFeJcJQxIoIyfz1vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,479,1422921600"; d="scan'208";a="135964321" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 27 Mar 2015 15:23:50 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2RFNoZm009316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 15:23:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.130]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 10:23:49 -0500 From: "Eric Vyncke (evyncke)" To: "Metzler, Dan J" , Merike Kaeo , Jen Linkova Thread-Topic: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) Thread-Index: AQHQWs7PxLq1VIcV1E6/+HsVS3BBAZ0Y1R8AgAAPIACAABdXAIAAYkoAgAAEeoCAAAowgIAABUOAgAACKYCAAATDgIAA9HuYgAC4p4CAA6sygIAADNEAgAAfPQCAAAbPAIAAJ/0AgAABwICAACuMgIAAC+CAgAFYmACAAAUYAIAOLHKAgAAC2oCAAAF0gIAADKaAgAFq4BCAACElAA== Importance: low X-Priority: 5 Date: Fri, 27 Mar 2015 15:23:49 +0000 Message-ID: References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.89.12.26] Content-Type: text/plain; charset="utf-8" Content-ID: <35FBC0E84F840D4F8FEB8ACA2C8D153B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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: Fri, 27 Mar 2015 15:23:58 -0000 QW5kLCBhcyBJIGNvdWxkIG5vdCByZWZyYWluIGZyb20gc2VuZGluZyBzb21lIHBhY2tldHMgZnJv bSB0aGUgSW50ZXJuZXQgdG8NCm15IGxhcHRvcCB1c2luZyB0aGUgVFdDIGNvbm5lY3Rpdml0eSBh bmQgcGFja2V0cyB3aXRoIEVIIGFyZSBhY3R1YWxseQ0KZHJvcHBlZCBieSBUV0MgOi1PDQoNClNl ZSBiZWxvdw0KLSBSSCB3aXRoIGEgbmV3IHR5cGUgPT4gSUNNUCBpcyBnZW5lcmF0ZWQgKGRpc2Fw cG9pbnRpbmcpDQotIFJIIHdpdGggdHlwZSAwID0+IGRyb3BwZWQgKGV4Y2VsbGVudCkNCi0gSGJI ID0+IGRyb3BwZWQgKGV4Y2VsbGVudCkNCi0gRGVzdGluYXRpb24gT3B0aW9uID0+IGRyb3BwZWQg KGRpc2FwcG9pbnRpbmcpDQoNCjIwMDE6MTk5ODowOjg6OmYgdGhlIHJvdXRlciBnZW5lcmF0aW5n IHRoZSBJQ01QIChhbmQgcHJvYmFibHkgZHJvcHBpbmcgdGhlDQpvdGhlciBvbmVzKSB1c2VzIGFu IGFkZHJlc3Mgb2YgVFdDIDstKQ0KDQoNClNvcnJ5IExlZSA6LSkNCg0KLcOpcmljDQoNCj4+PiBp Y21wX2RhdGE9IlRlc3QgU1JIIGVyaWNAdnluY2tlLm9yZyINCj4+PiANCj4+PiByb3V0ZT1bXQ0K Pj4+IHJvdXRlLmFwcGVuZCgiMjAwMTpkYjg6OmRlYWQ6YmVlZiIpDQo+Pj4gcm91dGUuYXBwZW5k KGRzdCkNCj4+PiANCj4+PiANCj4+PiANCj4+PnBhY2tldD1JUHY2KGRzdD1kc3QsaGxpbT0yNTUp L0lQdjZFeHRIZHJSb3V0aW5nKGFkZHJlc3Nlcz1yb3V0ZSxzZWdsZWZ0PQ0KPj4+MCx0eXBlPTQp L0lDTVB2NkVjaG9SZXF1ZXN0KGRhdGE9aWNtcF9kYXRhLGlkPVJhbmRTaG9ydCgpKQ0KPj4+IHNy MShwYWNrZXQscmV0cnk9MCwgdGltZW91dD0yKQ0KQmVnaW4gZW1pc3Npb246DQouRmluaXNoZWQg dG8gc2VuZCAxIHBhY2tldHMuDQouLi4uLi4uLi4uLi4uLi4qDQpSZWNlaXZlZCAxNyBwYWNrZXRz LCBnb3QgMSBhbnN3ZXJzLCByZW1haW5pbmcgMCBwYWNrZXRzDQo8SVB2NiAgdmVyc2lvbj02TCB0 Yz0wTCBmbD0wTCBwbGVuPTEyMCBuaD1JQ01QdjYgaGxpbT01MA0Kc3JjPTIwMDE6MTk5ODowOjg6 OmYgZHN0PTIwMDE6NDFkMDo4OmUxYTI6OjEyODAgfDxJQ01QdjZEZXN0VW5yZWFjaA0KdHlwZT1E ZXN0aW5hdGlvbiB1bnJlYWNoYWJsZSBjb2RlPUNvbW11bmljYXRpb24gd2l0aCBkZXN0aW5hdGlv bg0KYWRtaW5pc3RyYXRpdmVseSBwcm9oaWJpdGVkIGNrc3VtPTB4NDhkNyB1bnVzZWQ9MHgwIHw8 SVBlcnJvcjYgIHZlcnNpb249NkwNCnRjPTBMIGZsPTBMIHBsZW49NzIgbmg9Um91dGluZyBIZWFk ZXIgaGxpbT0yNDQgc3JjPTIwMDE6NDFkMDo4OmUxYTI6OjEyODANCmRzdD0yMDAxOjY3YzozNzA6 MTUyOjE2MTA6OWZmZjpmZWQ4OmIwNjMgfDxJUHY2RXh0SGRyUm91dGluZw0Kbmg9SUNNUHY2bGVu PTQgdHlwZT00IHNlZ2xlZnQ9MCByZXNlcnZlZD0wTCBhZGRyZXNzZXM9Ww0KMjAwMTpkYjg6OmRl YWQ6YmVlZiwgMjAwMTo2N2M6MzcwOjE1MjoxNjEwOjlmZmY6ZmVkODpiMDYzIF0NCnw8SUNNUHY2 RWNob1JlcXVlc3QgIHR5cGU9RWNobyBSZXF1ZXN0IGNvZGU9MCBja3N1bT0weDczMTcgaWQ9MHg0 NjkNCnNlcT0weDAgZGF0YT0nVGVzdCBTUkggZXJpY0B2eW5ja2Uub3JnJyB8Pj4+Pj4NCj4+PiAN Cj4+PiANCj4+PnBhY2tldD1JUHY2KGRzdD1kc3QsaGxpbT0yNTUpL0lQdjZFeHRIZHJSb3V0aW5n KGFkZHJlc3Nlcz1yb3V0ZSxzZWdsZWZ0PQ0KPj4+MCx0eXBlPTApL0lDTVB2NkVjaG9SZXF1ZXN0 KGRhdGE9aWNtcF9kYXRhLGlkPVJhbmRTaG9ydCgpKQ0KPj4+IHNyMShwYWNrZXQscmV0cnk9MCwg dGltZW91dD0yKQ0KQmVnaW4gZW1pc3Npb246DQpGaW5pc2hlZCB0byBzZW5kIDEgcGFja2V0cy4N ClJlY2VpdmVkIDI4NyBwYWNrZXRzLCBnb3QgMCBhbnN3ZXJzLCByZW1haW5pbmcgMSBwYWNrZXRz DQo+Pj4gDQo+Pj4gDQo+Pj5wYWNrZXQ9SVB2Nihkc3Q9ZHN0LGhsaW09MjU1KS9JUHY2RXh0SGRy SG9wQnlIb3Aob3B0aW9ucz1QYWROKG9wdGRhdGE9J0ENCj4+PicqMjApKS9JQ01QdjZFY2hvUmVx dWVzdChkYXRhPWljbXBfZGF0YSxpZD1SYW5kU2hvcnQoKSkNCj4+PiBzcjEocGFja2V0LHJldHJ5 PTAsIHRpbWVvdXQ9MikNCkJlZ2luIGVtaXNzaW9uOg0KLkZpbmlzaGVkIHRvIHNlbmQgMSBwYWNr ZXRzLg0KUmVjZWl2ZWQgNDQzIHBhY2tldHMsIGdvdCAwIGFuc3dlcnMsIHJlbWFpbmluZyAxIHBh Y2tldHMNCj4+PiANCj4+PiANCj4+PnBhY2tldD1JUHY2KGRzdD1kc3QsaGxpbT0yNTUpL0lQdjZF eHRIZHJEZXN0T3B0KG9wdGlvbnM9UGFkTihvcHRkYXRhPSdBJw0KPj4+KjIwKSkvSUNNUHY2RWNo b1JlcXVlc3QoZGF0YT1pY21wX2RhdGEsaWQ9UmFuZFNob3J0KCkpDQo+Pj4gc3IxKHBhY2tldCxy ZXRyeT0wLCB0aW1lb3V0PTIpDQpCZWdpbiBlbWlzc2lvbjoNCi4uLi4uRmluaXNoZWQgdG8gc2Vu ZCAxIHBhY2tldHMuDQpSZWNlaXZlZCA2NzYgcGFja2V0cywgZ290IDAgYW5zd2VycywgcmVtYWlu aW5nIDEgcGFja2V0cw0KDQo= From nobody Fri Mar 27 12:01:48 2015 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 F1A821A8EA9 for ; Fri, 27 Mar 2015 12:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 sM_SECH6BBZI for ; Fri, 27 Mar 2015 12:01:44 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52D71A90B0 for ; Fri, 27 Mar 2015 12:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2025; q=dns/txt; s=iport; t=1427482890; x=1428692490; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3nazzsyiagRideOcmAMMr9MNev3Xye/Kzf4dQ9esgTY=; b=ZlOcyApMg4SC4D1z/RTonPsCuLzU8Cvpva29ASV/oerl+wmIrv6P5fx4 LRmNjyVbrGQZVXg4lk+UMxgtscLiEmlQ9UxPvq3BkWkRDX5hvWjGbUVlh TAoYm7PXRs9BqYPSwzbk19auGPN0YXgjOtkrmbGnSUKhJAdMq8SNp1933 8=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DoBADGqBVV/49dJa1cgwaBMMNwh0QCgTk4FAEBAQEBAQF8hBUBAQMBeQULAgEIRjIlAgQOE4gZCMxbAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4shhHUHgxeBFgWQT4FpgTGGU5QpIoNugjN/AQEB X-IronPort-AV: E=Sophos;i="5.11,480,1422921600"; d="asc'?scan'208";a="135960189" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP; 27 Mar 2015 19:01:30 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2RJ1UmR005993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 19:01:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 14:01:29 -0500 From: "Fred Baker (fred)" To: Alexandru Petrescu Thread-Topic: [v6ops] why IPv6 EHs in the Real World Thread-Index: AQHQaMBuCCOHYKW+40KU80BKRy30WQ== Date: Fri, 27 Mar 2015 19:01:29 +0000 Message-ID: <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> <5515628D.7020306@gmail.com> In-Reply-To: <5515628D.7020306@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.12.130] Content-Type: multipart/signed; boundary="Apple-Mail=_E03757FD-BF7E-4B23-BDBF-001FA6AD4429"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] why IPv6 EHs in the Real World 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: Fri, 27 Mar 2015 19:01:46 -0000 --Apple-Mail=_E03757FD-BF7E-4B23-BDBF-001FA6AD4429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > I dont work for an Operator, but it is reasonable to expect operators = to filter Routing Headers. >=20 > These are not used by any application and open a signficant security = risk. I understand the security risk, I think; that=92s discussed in RFC 5095. = I=92ll note, however, that the RFC doesn=92t address =93routing = headers=94; it addresses =93routing headers of type 0=94. The Segment = Routing header is a Routing Header, and trashing all Segment Routing = traffic because we have an issue with RH0 traffic seems a trifle = extreme. I get a little antsy is it being filtered by a system other than the one = in the destination address or a system acting as a firewall. The = operator doesn=92t necessarily know what network the address is in, or = whether there might be a private arrangement between networks that use = his network as transit to communicate. I would want the transit domains = to not be applying transitive policy to their customer=92s or peer=92s = traffic without their knowledge. --Apple-Mail=_E03757FD-BF7E-4B23-BDBF-001FA6AD4429 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 iQEVAwUBVRWNkp9ieig10VPpAQICpwf+J61hSl0ncG4u4Fqyy6FqvfZIRNHIRDbU cDUw9MjGPw875uhb0hRa0Tzxyu7Vl1M6oedWT2QRaigYfMDCneLs1PWGlzYJ4lNq pAVjiFVkeylRzr2eMTYRwKyqvyrdDijq658UfqheQXPMlcgsRYPm5Jt8wFRc+h6R 6e5lL2IeWzx2SyvkNQ6VXbT1Y1+u7xll1rgPGnio+LIAur6osmBcxg5wltAKpIKu JG0rwRl+zdmtdRGoleauc1wOun93bp9EF6Cy5xQcOUKSgTOfYPNU7trkIBCgszwy 6h0+/OfDuhDynf+zOrmOaE92Gg+461okam0pQXJ1PDqqpKNXeBR4Xg== =RVQM -----END PGP SIGNATURE----- --Apple-Mail=_E03757FD-BF7E-4B23-BDBF-001FA6AD4429-- From nobody Fri Mar 27 12:06:07 2015 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 17E181A8F51 for ; Fri, 27 Mar 2015 12:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1N6YuQGbczVc for ; Fri, 27 Mar 2015 12:06:04 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (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 A5FD61A8BB5 for ; Fri, 27 Mar 2015 12:06:04 -0700 (PDT) Received: by padcy3 with SMTP id cy3so103709442pad.3 for ; Fri, 27 Mar 2015 12:06:04 -0700 (PDT) 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:content-type; bh=W0lR14cq6kawe/TXM0OzV0x7JFQG2IJpFPjwpxsABTo=; b=UC47h/xWnZScyV2qaNad0VhWQXtUS4lNiBs/gU5i4Z7QOAO7by+drKZC5lyIWDjod7 n0NwfGV5uC88Y9HT55F47lsdpK/L+AYQmjKMiRXEZdmwGEklc6KR11TYMSjohi8/wYak TSU8gHT0I4AjhIvyXhfLARW9Z35FnGOg3p4HdXer/ir7vy9nVy4bfnKMyOPCA8v3B9AF bdNuh3cC3rvng3BFmfe9xHCbor9YZKsvvfikLs5uCpYX5lgmqWxp6vgPquLAcQ2pGqmX lOxznXR0Vt+obIaGBN/5AYmhgtPjEfEnsG1vZoeM3BPh21og7FULGlqZWXCQEIYHAqoC os0w== X-Gm-Message-State: ALoCoQmInC2Imnt1VkX8BaAu3RKG2D1Dedw5A1uP96lrzzg11DfcYivjest4nFRYcHaU3JhZ2eV3 MIME-Version: 1.0 X-Received: by 10.68.223.130 with SMTP id qu2mr38231850pbc.116.1427483164036; Fri, 27 Mar 2015 12:06:04 -0700 (PDT) Received: by 10.70.138.36 with HTTP; Fri, 27 Mar 2015 12:06:03 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:d8e7:7ce8:404a:7b7f] In-Reply-To: <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> Date: Fri, 27 Mar 2015 14:06:03 -0500 Message-ID: From: George Michaelson To: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ffba0ebea6866051249d279 Archived-At: Subject: Re: [v6ops] why IPv6 EHs in the Real World 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: Fri, 27 Mar 2015 19:06:06 -0000 --e89a8ffba0ebea6866051249d279 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 27, 2015 at 2:01 PM, Fred Baker (fred) wrote: > > I get a little antsy is it being filtered by a system other than the one > in the destination address or a system acting as a firewall. The operator > doesn=E2=80=99t necessarily know what network the address is in, or wheth= er there > might be a private arrangement between networks that use his network as > transit to communicate. I would want the transit domains to not be applyi= ng > transitive policy to their customer=E2=80=99s or peer=E2=80=99s traffic w= ithout their > knowledge. > Well said. +1 to sentiment. That said, the work exposing the risks of EH right now are pretty extreme. If you release packets into the wild with EH, you can expect significant packetloss. And its not apparent how you can know in advance the risk. -G --e89a8ffba0ebea6866051249d279 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 27, 2015 at 2:01 PM, Fred Baker (fred) &l= t;fred@cisco.com>= ; wrote:

I get a little antsy is it being filtered by a system other than the one in= the destination address or a system acting as a firewall. The operator doe= sn=E2=80=99t necessarily know what network the address is in, or whether th= ere might be a private arrangement between networks that use his network as= transit to communicate. I would want the transit domains to not be applyin= g transitive policy to their customer=E2=80=99s or peer=E2=80=99s traffic w= ithout their knowledge.

Well said. +1 t= o sentiment.

That said, the work exposing the risk= s of EH right now are pretty extreme. If you release packets into the wild = with EH, you can expect significant packetloss. And its not apparent how yo= u can know in advance the risk.

-G=C2=A0
--e89a8ffba0ebea6866051249d279-- From nobody Fri Mar 27 19:54:59 2015 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 0AEAE1ACF04 for ; Thu, 26 Mar 2015 07:44:43 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 hFjyFhc022-5 for ; Thu, 26 Mar 2015 07:44:41 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 E27B81ACEAC for ; Thu, 26 Mar 2015 07:44:15 -0700 (PDT) Received: from dhcp-b13c.meeting.ietf.org (dhcp-b13c.meeting.ietf.org [31.133.177.60]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2QEi0I1004230 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Mar 2015 07:44:01 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_610D6FD6-5B24-4AC4-B3C3-9EF4285099CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: Date: Thu, 26 Mar 2015 07:43:55 -0700 Message-Id: <3461E738-46B8-4886-AC09-230E4E5B3F7A@doubleshotsecurity.com> References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.1510) X-Sonic-CAuth: UmFuZG9tSVZ6zPDXIZnp9YDjlOCQLhOJc3k1Jr8feYJ56B9ev2HzrMcAHXzHns9MY0aukGFb35kPjMTTh8iFpMt/AGNL0q+t X-Sonic-ID: C;OqhnisbT5BGgQKSqki+G8Q== M;3O/misbT5BGgQKSqki+G8Q== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-Mailman-Approved-At: Fri, 27 Mar 2015 19:54:58 -0700 Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 26 Mar 2015 14:44:43 -0000 --Apple-Mail=_610D6FD6-5B24-4AC4-B3C3-9EF4285099CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sounds good. Warren/Joel=85I think resurrecting work on Why Operators Filter = Fragments (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) = may be a good idea :) - merike On Mar 26, 2015, at 7:37 AM, "Eric Vyncke (evyncke)" = wrote: > Merike and Fernando, >=20 > As I wrote a couple of comments on the methodology, I do not mind = joining > your test campaign ;-) >=20 > Let's talk perhaps here in Dallas? >=20 > -=E9ric >=20 > On 17/03/15 15:10, "Merike Kaeo" wrote: >=20 >>=20 >> On Mar 17, 2015, at 6:52 AM, Mikael Abrahamsson = wrote: >>=20 >>> On Mon, 16 Mar 2015, sthaug@nethelp.no wrote: >>>=20 >>>>>> Lets live in the real world shall we? >>>>>>=20 >>>>>> = http://customer.comcast.com/help-and-support/internet/email-port-25-no >>>>>> -longer-supported/ >>>>>=20 >>>>> Ah, so the reason that an ISP would enforce ACLs is because of a >>>>> protocol with a lousy security model that is only fixable (and = even >>>>> then, not very) with the help of firewalls. Fair enough--I had >>>>> developed a blind spot about this issue because it's been broken = for >>>>> so long and we've been reflexively avoiding the brokenness for so = long. >>>>>=20 >>>>> But essentially what's happening here is that we are seeing a = design >>>>> flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we >>>>> should stop reflexively working around this problem and seriously >>>>> figure out how fix it, so that twenty years from now we no longer = need >>>>> a broken layer 3. >>>>=20 >>>> I'm all for that. However, I cannot afford to wait 20 years for a = fix >>>> to the problems. My priorities, as I see them: >>>>=20 >>>> 1. Protect my network. >>>> 2. Within reason, protect my customers. >>>> 3. Move traffic to and from my customers, in a semi-optimal way. >>>=20 >>> Please also add 4. "Protect the Internet from your customers". This = is >>> something too many miss. >>=20 >> I for one am really glad that we are getting operational reality = input. >> Thank you. FWIW, I'm sitting next to Fernando at a security = conference >> we are both at >> and I had offered to help with this draft. This was a few months = ago. >> What I see is that we are in need of some additional measurements and = that >> will happen. I would love to see some added input on this list in = how to >> improve measurements rather than the criticism of just how current >> measurements >> have been done. Collectively gathering operational realities is a = good >> thing for added input on how to deal with EHs. And FWIW, I am not in >> favor of >> deprecating EHs since that is too drastic but we as a community have = to >> understand where they are practically used and where they are dropped = for >> reasons that some deem as necessary. >>=20 >> - merike >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_610D6FD6-5B24-4AC4-B3C3-9EF4285099CB 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 iQEcBAEBCgAGBQJVFBswAAoJEA7gPO9LJuahbmoH/05Sht15TuLkObG1p4epakAN qgN7wAIMAwaP9Y9t9MOT87miJnRXD/1AacyxOUPv2NHVgrjA1SRkPxD4nOeo/WNA yYUfiDMqFrpXis5EvVlswogbLFKwiys8h2bOWfn2CxUT5GGPtGNV00KOv/Nw9EUt WC9HrNIXeYMzStbA3T/tEY3D312d/WafE/buTNXrvcAQeQpbCDLCaox/Agd5jdE5 IILS0ektHDOThNfY+iC/YAM68yEs7EA3hYQobcyp1uLgnS7SUaxj2kB0XRMgipXG Hbd+b9eZItzN9+4UQrkYCqYH9iCWYKytdt9c0DCKFuQoeWyfSUQbGKNGFYJD4kk= =jEhd -----END PGP SIGNATURE----- --Apple-Mail=_610D6FD6-5B24-4AC4-B3C3-9EF4285099CB-- From nobody Fri Mar 27 20:00:29 2015 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 875331A1B5E for ; Fri, 27 Mar 2015 20:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 tO_Wu9YBnwAy for ; Fri, 27 Mar 2015 20:00: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 AC87E1A1A90 for ; Fri, 27 Mar 2015 20:00:25 -0700 (PDT) Received: from mb-aye.local ([12.130.116.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t2S2xqQs022271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 28 Mar 2015 02:59:59 GMT (envelope-from joelja@bogus.com) To: Merike Kaeo , "Eric Vyncke (evyncke)" references: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <3461E738-46B8-4886-AC09-230E4E5B3F7A@doubleshotsecurity.com> From: joel jaeggli message-id: <55161913.5020901@bogus.com> Date: Fri, 27 Mar 2015 21:59:31 -0500 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0 mime-version: 1.0 in-reply-to: <3461E738-46B8-4886-AC09-230E4E5B3F7A@doubleshotsecurity.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tt9Sasvgj5nf9Q0TTHcixPEPIuNVWv0E9" Archived-At: Cc: "silvia.hagen@sunny.ch" , "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt) 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, 28 Mar 2015 03:00:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Tt9Sasvgj5nf9Q0TTHcixPEPIuNVWv0E9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable yeah understood On 3/26/15 9:43 AM, Merike Kaeo wrote: > Sounds good. >=20 > Warren/Joel=85I think resurrecting work on Why Operators Filter Fragmen= ts (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a = good idea :) >=20 > - merike >=20 > On Mar 26, 2015, at 7:37 AM, "Eric Vyncke (evyncke)" wrote: >=20 >> Merike and Fernando, >> >> As I wrote a couple of comments on the methodology, I do not mind join= ing >> your test campaign ;-) >> >> Let's talk perhaps here in Dallas? >> >> -=E9ric >> >> On 17/03/15 15:10, "Merike Kaeo" wrote: >> >>> >>> On Mar 17, 2015, at 6:52 AM, Mikael Abrahamsson wr= ote: >>> >>>> On Mon, 16 Mar 2015, sthaug@nethelp.no wrote: >>>> >>>>>>> Lets live in the real world shall we? >>>>>>> >>>>>>> http://customer.comcast.com/help-and-support/internet/email-port-= 25-no >>>>>>> -longer-supported/ >>>>>> >>>>>> Ah, so the reason that an ISP would enforce ACLs is because of a >>>>>> protocol with a lousy security model that is only fixable (and eve= n >>>>>> then, not very) with the help of firewalls. Fair enough--I had >>>>>> developed a blind spot about this issue because it's been broken f= or >>>>>> so long and we've been reflexively avoiding the brokenness for so = long. >>>>>> >>>>>> But essentially what's happening here is that we are seeing a desi= gn >>>>>> flaw at layer 7 forcing brokenness at layer 3. Oops. Maybe we >>>>>> should stop reflexively working around this problem and seriously >>>>>> figure out how fix it, so that twenty years from now we no longer = need >>>>>> a broken layer 3. >>>>> >>>>> I'm all for that. However, I cannot afford to wait 20 years for a f= ix >>>>> to the problems. My priorities, as I see them: >>>>> >>>>> 1. Protect my network. >>>>> 2. Within reason, protect my customers. >>>>> 3. Move traffic to and from my customers, in a semi-optimal way. >>>> >>>> Please also add 4. "Protect the Internet from your customers". This = is >>>> something too many miss. >>> >>> I for one am really glad that we are getting operational reality inpu= t. >>> Thank you. FWIW, I'm sitting next to Fernando at a security conferen= ce >>> we are both at >>> and I had offered to help with this draft. This was a few months ago= =2E >>> What I see is that we are in need of some additional measurements and= that >>> will happen. I would love to see some added input on this list in ho= w to >>> improve measurements rather than the criticism of just how current >>> measurements >>> have been done. Collectively gathering operational realities is a go= od >>> thing for added input on how to deal with EHs. And FWIW, I am not in= >>> favor of >>> deprecating EHs since that is too drastic but we as a community have = to >>> understand where they are practically used and where they are dropped= for >>> reasons that some deem as necessary. >>> >>> - merike >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Tt9Sasvgj5nf9Q0TTHcixPEPIuNVWv0E9 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUWGRMACgkQ8AA1q7Z/VrKfKACbBGO7nu8StqjF1QWSj3kEJkCh WC8AoICQzX/2SwGr1Y1JExBYLkfxfi0r =AYSj -----END PGP SIGNATURE----- --Tt9Sasvgj5nf9Q0TTHcixPEPIuNVWv0E9-- From nobody Fri Mar 27 20:22:36 2015 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 B8DC31A023E for ; Fri, 27 Mar 2015 20:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 T1BN6fC6ShKd for ; Fri, 27 Mar 2015 20:22:32 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::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 DA2BD1A01E2 for ; Fri, 27 Mar 2015 20:22:32 -0700 (PDT) Received: by pdbop1 with SMTP id op1so114485349pdb.2 for ; Fri, 27 Mar 2015 20:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5+rtJdj3612WI6kWKAfsIatgWdFzuAD9AODITRy+XuA=; b=soGcHmufyLtDSk/FCPMwsw8+TkxelzKpaKtNiMwL6jdJNZKJcw9b1NSIfl4QC1gBVy tmS3FnETlO1OylXAvunE+UTzFeHdiuMdzTVTd+p7ukwYp/UmmDipYau18ktiS0gjb63u eXysVpGAyYu2Z9OAleZb1e4x6zZpAJiaFDbZlYmAgdZVSh3WDFztEeEAa5b42ihxjp0u qxsRoo/W1u1Hs0X9xzKNjVBrEthYQ8vL8CdrD0BrYzfbqywvDO3CdG5TymvZpJyDWmr7 ODKDND1tURkJAWDJ37R2CvOUWJViEckowHGdUR04ImecoEc8BvST4m/kSrYVYxLGV9M1 8ruQ== X-Received: by 10.70.123.65 with SMTP id ly1mr40006357pdb.102.1427512952501; Fri, 27 Mar 2015 20:22:32 -0700 (PDT) Received: from [192.168.206.29] ([205.129.7.189]) by mx.google.com with ESMTPSA id gy3sm3524613pbb.42.2015.03.27.20.22.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2015 20:22:31 -0700 (PDT) Message-ID: <55161E85.8020806@gmail.com> Date: Sat, 28 Mar 2015 16:22:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Alexandru Petrescu References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> In-Reply-To: <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] why IPv6 EHs in the Real World 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, 28 Mar 2015 03:22:34 -0000 On 28/03/2015 08:01, Fred Baker (fred) wrote: >> I dont work for an Operator, but it is reasonable to expect operators = to filter Routing Headers. >> >> These are not used by any application and open a signficant security r= isk. >=20 > >=20 > I understand the security risk, I think; that=E2=80=99s discussed in RF= C 5095. I=E2=80=99ll note, however, that the RFC doesn=E2=80=99t address = =E2=80=9Crouting headers=E2=80=9D; it addresses =E2=80=9Crouting headers = of type 0=E2=80=9D. The Segment Routing header is a Routing Header, and t= rashing all Segment Routing traffic because we have an issue with RH0 tra= ffic seems a trifle extreme. This is laid out precisely in RFC 7045*, so you can tell any operator that trashes all RH packets that they are in violation and the protocol police are very angry with them. Brian * "The IPv6 Routing Header Types 0 and 1 have been deprecated. Note that Type 0 was deprecated by [RFC5095]. However, this does not mean that the IPv6 Routing Header can be unconditionally dropped by forwarding nodes. Packets containing standardised and undeprecated Routing Headers SHOULD be forwarded by default. At the time of writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the experimental Routing Header Types 253 and 254 [RFC4727]. Others may be defined in the future." >=20 > I get a little antsy is it being filtered by a system other than the on= e in the destination address or a system acting as a firewall. The operat= or doesn=E2=80=99t necessarily know what network the address is in, or wh= ether there might be a private arrangement between networks that use his = network as transit to communicate. I would want the transit domains to no= t be applying transitive policy to their customer=E2=80=99s or peer=E2=80= =99s traffic without their knowledge. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sat Mar 28 06:34:43 2015 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 A73C81A8794 for ; Sat, 28 Mar 2015 06:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.61 X-Spam-Level: X-Spam-Status: No, score=-112.61 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 m5pcYm1CNO1Z for ; Sat, 28 Mar 2015 06:34:40 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FCF1A878B for ; Sat, 28 Mar 2015 06:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8133; q=dns/txt; s=iport; t=1427549679; x=1428759279; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=S0x1I2WjKx9+Z5hUtc4WoaiPh/UijtBSMCe4pDINTDo=; b=HEKEFwVzY0Br8H5WK6H817YUJsKKb4pItI9x0NikzMUtdxsRaU/bPTSW Bh3kSNWAy/kt4yid+9eanMQQEQpzGKiFrj0XyTDwDigcYIJV9QpEOiviY A2P4vfsw5t+yPmBZcTohAc5C4uGgMixqm/JZKBUTn9oFzfx7EmjeWHoRM Y=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQDAqxZV/4sNJK1cgkNDgS4Egw/ILQKBKUwBAQEBAQF9hBQBAQEDASNWBQsCAQgYIwcCAjIlAgQOBQ4NiAwIsjOZWQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLKYR4B4JoL4EWBZBcgWuBMoJ6g12BHI9Rg0giggIcFIE8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,484,1422921600"; d="asc'?scan'208,217";a="136232745" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 28 Mar 2015 13:27:37 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2SDRb3D009839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Mar 2015 13:27:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sat, 28 Mar 2015 08:27:36 -0500 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AQHQaVr0o1LCFyMFfEeH4Ad9ZBE/xg== Date: Sat, 28 Mar 2015 13:27:36 +0000 Message-ID: <25CE7ECC-A27E-47F7-9DA0-9A11F4DC543E@cisco.com> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.0.121] Content-Type: multipart/signed; boundary="Apple-Mail=_8A615676-60B6-4A45-96C1-74E4CB584F5A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 28 Mar 2015 13:34:41 -0000 --Apple-Mail=_8A615676-60B6-4A45-96C1-74E4CB584F5A Content-Type: multipart/alternative; boundary="Apple-Mail=_C68BFCF2-9215-42A0-9717-7E2E9E3102FC" --Apple-Mail=_C68BFCF2-9215-42A0-9717-7E2E9E3102FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 24, 2015, at 10:26 AM, Lorenzo Colitti = wrote: >=20 > I'm not sure that's true. We have four scenarios, in order of = decreasing incentives (from 100% to 0%) to write IPv4-only code: > IPv4-only device > Dual-stack device (native IPv6 and NAT44 or NAT444) > IPv6-only device with "compatibility quality" IPv4 (e.g., 464xlat). > IPv6-only device > Based on personal experience, I know that #3 provides less incentives = to write IPv4-only code than #2. I've heard developers say multiple = times, "Double NAT and 464xlat? (i.e., #3.) Man, that sounds pretty = flaky, and high latency too. What do I need to do to fix my code to = support IPv6?" In contrast, #2 is seen as, "well, we still have IPv4 = right? So we can just continue to use it. You say IPv6 has no NAT? But = we deal with NAT today, and it works fine..." > I think the real discussion here is whether going from #2 to #4 = without passing through #3 is possible at all. If you believe that it's = possible, then #2 makes sense. If you believe it's not possible, then = the only thing that makes sense is to do #3 ASAP. =46rom my perspective, I would agree. That said, when dual stack was = proposed, I think your #2 and #3 would have both been called =E2=80=9Cdual= stack=E2=80=9D; I know Tony Hain saw it coming and commented = (negatively) on it. But the choices, from the perspective then, were = IPv4 (your #1), IPv4+IPv6 (#2+#3), and IPv6 (#4). =46rom an evangelistic perspective, I think we=E2=80=99re past the time = that telling people NAT is bad. I have been telling people how much = money it takes to deploy an application that has to traverse one. = Client-Server applications aren=E2=80=99t too hard if the server is on = the public side of the NAT, which most are. If you have to cross the NAT = from the outside, you have to have one pf three things: 1) persistent presence on the outside that things on the inside can = connect to and have their sessions co-opted by the incoming call, 2) something akin to RSIP, or 3) application-specific ALG support in the middleware. The first takes money, the second takes a standard that ADM providers = can find in open source software, and the third takes convincing ODM = providers and/or your corporate IT department. And having IPv6 on bypasses all that. Yes, I think we have to get to a point in which people that authorize = monetary expenditures believe that an IPv6 network works better. We=E2=80=99= re going to have to go through a phase in which IPv4 works worse, as = perceived by the person using it. --Apple-Mail=_C68BFCF2-9215-42A0-9717-7E2E9E3102FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 24, 2015, at 10:26 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:

I'm = not sure that's true. We have four scenarios, in order of decreasing = incentives (from 100% to 0%) to write IPv4-only code:
  1. IPv4-only device
  2. Dual-stack device (native IPv6 and NAT44 = or NAT444)
  3. IPv6-only device with "compatibility = quality" IPv4 (e.g., 464xlat).
  4. IPv6-only = device
  1. Based= on personal experience, I know that #3 provides less incentives to = write IPv4-only code than #2. I've heard developers say multiple times, = "Double NAT and 464xlat? (i.e., #3.) Man, that sounds pretty flaky, and = high latency too. What do I need to do to fix my code to support IPv6?" = In contrast, #2 is seen as, "well, we still have IPv4 right? So we can = just continue to use it. You say IPv6 has no NAT? But we deal with NAT = today, and it works fine..."
I think the real discussion here is whether going from = #2 to #4 without passing through #3 is possible at all. If you believe = that it's possible, then #2 makes sense. If you believe it's not = possible, then the only thing that makes sense is to do #3 = ASAP.

=46rom my = perspective, I would agree. That said, when dual stack was proposed, I = think your #2 and #3 would have both been called =E2=80=9Cdual stack=E2=80= =9D; I know Tony Hain saw it coming and commented (negatively) on it. = But the choices, from the perspective then, were IPv4 (your #1), = IPv4+IPv6 (#2+#3), and IPv6 (#4). 

=46rom an evangelistic perspective, I = think we=E2=80=99re past the time that telling people NAT is bad. I have = been telling people how much money it takes to deploy an application = that has to traverse one. Client-Server applications aren=E2=80=99t too = hard if the server is on the public side of the NAT, which most are. If = you have to cross the NAT from the outside, you have to have one pf = three things:
1) persistent presence on the outside = that things on the inside can connect to and have their sessions = co-opted by the incoming call, 
2) something = akin to RSIP, or 
3) application-specific ALG = support in the middleware. 

The first takes money, the second takes = a standard that ADM providers can find in open source software, and the = third takes convincing ODM providers and/or your corporate IT = department.

And = having IPv6 on bypasses all that. 

Yes, I think we have to get to a point = in which people that authorize monetary expenditures believe that an = IPv6 network works better. We=E2=80=99re going to have to go through a = phase in which IPv4 works worse, as perceived by the person using = it.
= --Apple-Mail=_C68BFCF2-9215-42A0-9717-7E2E9E3102FC-- --Apple-Mail=_8A615676-60B6-4A45-96C1-74E4CB584F5A 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 iQEVAwUBVRaYP59ieig10VPpAQJnJggAilsxgIoajgWc04yek1wXvaeaWdt4Sb0l qrf/HuNcjqjTBBtigRUllseP//Su/CKIkFc47XyHZeRA97CYX3oodsa5HPpm/afO 7kZ8nVowCI+uPNjY7GY0UvZ9slMUqsf+st+O0exy9oll6Us7W6n822xfUdusKVx7 tIxAr2b7WQr9GSNEKe4rHRTkCqP2bOP6kk4BiCVH1N30JXwtmpfN6H9iENMQ4/pN kGo4I9rB0Y1cEafoaEQjqI71X8nUz70iAku4sf5cTrqgU2bG79zg+Dh0lVDmIFF4 ilcGvjGDn4JdhsMM3xyY+SJVb1sbIjiqKTtonQEMXVHecDu5VQq1Ow== =Degy -----END PGP SIGNATURE----- --Apple-Mail=_8A615676-60B6-4A45-96C1-74E4CB584F5A-- From nobody Sat Mar 28 08:16:23 2015 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 333921A88CB for ; Sat, 28 Mar 2015 08:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 4hpA503dlmGW for ; Sat, 28 Mar 2015 08:16:19 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 895A81A88C0 for ; Sat, 28 Mar 2015 08:16:19 -0700 (PDT) Received: by oiag65 with SMTP id g65so97605893oia.2 for ; Sat, 28 Mar 2015 08:16: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:from:date:message-id:subject:to :cc:content-type; bh=woPpsJUteOPNfGs5verOzaOZghEdN2bM/uoLmBBKQCc=; b=FIW7PVgJrQcA2HPuvnep2WRXzX8057RzFhe++CBTg14Bum2MbJYwJ6zQqFwlFwTuL2 e5deEVTKIbERarLnEWYzJAe1jfJBlTOgceojv4IogcLPbqTzC+4kypx0gwF9lpkMNmjG Tw1dPVK8BWUNmtGG9qeLmISiKpsUyxyvCF3zW3htJNlo0jOwv9NQCpdQJ2JzP/IRCZUQ jphHm2xYs0n973bm5B60KURndkoXrh9l/fccooQcXl3Ai3EKfmQRdgGkJ9ME124wnuUY jLaV/U15d/VN2xCl+qFI/vju2rN7pByaN93tpYfXiAbd8ceqASkZGb+7TLed7996tW6t a65Q== X-Received: by 10.202.75.76 with SMTP id y73mr6503301oia.32.1427555778999; Sat, 28 Mar 2015 08:16:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.227.201 with HTTP; Sat, 28 Mar 2015 08:15:38 -0700 (PDT) In-Reply-To: <8EF27210-0C56-4F6D-81FD-B27EE34ED444@cisco.com> References: <8EF27210-0C56-4F6D-81FD-B27EE34ED444@cisco.com> From: "Mukom Akong T." Date: Sat, 28 Mar 2015 10:15:38 -0500 Message-ID: To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11c183b21abd5c05125abb46 Archived-At: Cc: V6ops Chairs Subject: Re: [v6ops] Discussion: IPv4 as a Service 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, 28 Mar 2015 15:16:21 -0000 --001a11c183b21abd5c05125abb46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fred, On Thu, Mar 26, 2015 at 3:59 PM, Fred Baker (fred) wrote: > > https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwoUWdz6psyEb= 456c3A/edit?usp=3Dsharing I added a few suggestions to the documents. Other things I didn't add but wondered whether they were appropriate for such a document were: - Business justification (goal): what business problem were you trying to solve? (the boiler-plate answer might be 'deal with v4 exhaustion' but perhaps the specific triggers might be useful?) - Post mortem: did the deployment address the business concern you set out to solve? --=20 Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --001a11c183b21abd5c05125abb46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fred,


On Thu, Mar 26, 2015 at 3:59 PM, Fred Baker (fred) <= ;fred@cisco.com>= wrote:
https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMA= woUWdz6psyEb456c3A/edit?usp=3Dsharing

I added a f= ew suggestions to the documents. Other things I didn't add but wondered= whether they were appropriate for such a document were:


- Business justification (goal): what business proble= m were you trying to solve? (the boiler-plate=C2=A0answer might be 'dea= l with v4 exhaustion' but perhaps the specific triggers might be useful= ?)


- Post mortem: did the deployment address the busi= ness concern you set out to solve?=C2=A0


--

Mukom Akong T.

http://about.me/perfexcellence | =C2= =A0twitter: @perfexcellent
---------------------------------------= ---------------------------------------------------------------------------= ------------------------
=E2=80=9CWhen you work, you are the FLUTE throu= gh whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gi= bran
-------------------------------------------------------------------= ------------------------------------------------------------------------
--001a11c183b21abd5c05125abb46-- From nobody Sat Mar 28 08:22:12 2015 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 466C41A88E9 for ; Sat, 28 Mar 2015 08:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 sHq9dRChWEDe for ; Sat, 28 Mar 2015 08:22:10 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225191A88E7 for ; Sat, 28 Mar 2015 08:22:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A2A9120863 for ; Sat, 28 Mar 2015 11:22:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 28 Mar 2015 11:22:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Knbq4y+xzop9joV qX9WRIz95ak8=; b=hIjgMfZ3+3+fpTUJTzxGCXt2TB1kvEdDizrUMzVSTdcpVma tDs+dBlwP5UYgWkIz9SOn55K0VEfwQdRVVVS/i7d9f+lFI66hLLio7CDN5OwSbk/ XK8783/GYuVd/6ipHfUBX/rj01wAmxcC+O50K/f3Bm4Dr4IcMh6NmABka30U= X-Sasl-enc: Da2hfhByrpj5Lcd3cp9WEAQNYEFtZNEZ8nUc4jvUyjoJ 1427556129 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 3DA1FC00011; Sat, 28 Mar 2015 11:22:09 -0400 (EDT) Message-ID: <5516C71F.3020606@network-heretics.com> Date: Sat, 28 Mar 2015 11:22:07 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 28 Mar 2015 15:22:11 -0000 On 03/26/2015 12:29 PM, James Woodyatt wrote: > The IPv4 literals will never die, and IPv4 as a service will never be > sunset. Yep. Just like I still see .BITNET email addresses everywhere. (except that, come to think of it, I don't) Keith From nobody Mon Mar 30 11:20:33 2015 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 1F7D91A923C for ; Mon, 30 Mar 2015 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.52 X-Spam-Level: ** X-Spam-Status: No, score=2.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_20_30=1.999, 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 hUMPnTuZY_Bg for ; Mon, 30 Mar 2015 11:20:31 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 C26171A9239 for ; Mon, 30 Mar 2015 11:20:31 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so69167589obb.1 for ; Mon, 30 Mar 2015 11:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cMuqqy2ld3pCi4cUUqbfX9ZcfyOjeriA6Qh7Qus8y+c=; b=a4g+QcpEWXcCxNXibeFkZSvkuWoYMJVycrYk0oqPE/ZcDL3Kkjlj6fRhzGs3JGNMN6 N7Zj0yG4rXbtC9iIDD4oK+U1/Jjz4ezEddGofmYDersUxYrquvPKrHiXE/hpReyZA/sj Y2UGCpCipY9U4UB/3bm0LzFVNLmoFUA/ujT/o= 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-type; bh=cMuqqy2ld3pCi4cUUqbfX9ZcfyOjeriA6Qh7Qus8y+c=; b=PLe1ltcQ/g8ANIDXgWr8vuvrgHolrhEgMr/+95jrQu0elAfe7cdQ0yuWLrmLX/KCzJ T3UIP3TKbEadP8Lh3IYHhmScb+rLzVjama4Lrtc9ux7G9O4W4QoIywvDsqo0AqZlmaPz EW2bRA1qY/PUzLoAPvnf+har1QW/UgsXMtjXV8YJz7OLmNk+avxf0dtxIVHKjNSzAXwQ kfLkcKOzZQ6QI4blFsSRjHR8uOnhdzTlmWwphlPxPNXDbjFT1V0zKSiYucobVT1xEE/Q FqEdQ70u0dwyQNTPBMVZuaDcQr04a+QFo84SjxwlmB2JVy5qt2Hlihn1FeVFZ2Ayyyju 8uWw== X-Gm-Message-State: ALoCoQmJmeN7x+MUy8jcVdf+MEUGyUjcJoRuT6UpeyPY7c99kNUX7Hwy3JGHgpK09UM1Jk58sdZ+ MIME-Version: 1.0 X-Received: by 10.182.137.136 with SMTP id qi8mr14466420obb.51.1427739631130; Mon, 30 Mar 2015 11:20:31 -0700 (PDT) Received: by 10.76.177.229 with HTTP; Mon, 30 Mar 2015 11:20:30 -0700 (PDT) In-Reply-To: <5516C71F.3020606@network-heretics.com> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> <5516C71F.3020606@network-heretics.com> Date: Mon, 30 Mar 2015 13:20:30 -0500 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11c352368bb108051285894b Archived-At: Cc: Keith Moore Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 30 Mar 2015 18:20:33 -0000 --001a11c352368bb108051285894b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Keith=E2=80=94=E2=80=8B I would have drawn that comparison to Appletalk not BITNET, except strangely enough=E2=80=94 maybe not so strangely=E2=80=94 I don't remember = seeing a lot of Appletalk literal addresses littering source code the way you see IPv4 literals still so widely used today. Hmm, I wonder what lessons might be drawn from such a comparison. --001a11c352368bb108051285894b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Keith=E2=80=94=E2=80=8B

I would have drawn that comparison to Appletalk not BITNET, except= strangely enough=E2=80=94 maybe not so strangely=E2=80=94 I don't reme= mber seeing a lot of Appletalk literal addresses littering source code the = way you see IPv4 literals still so widely used today. Hmm, I wonder what le= ssons might be drawn from such a comparison.
--001a11c352368bb108051285894b-- From nobody Mon Mar 30 11:37:38 2015 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 90ED91A6F38 for ; Mon, 30 Mar 2015 11:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 U-J6h5FEkui2 for ; Mon, 30 Mar 2015 11:37:35 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8181A916F for ; Mon, 30 Mar 2015 11:37:34 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 715CD20B7D for ; Mon, 30 Mar 2015 14:37:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 30 Mar 2015 14:37:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=u6xSRQrOu2TdtRh 4sJ++tRWiqno=; b=jok7xP5lxj+rnxEh+TLsjBzWgJl4WL77aYSYMSctBFQc02E 0TG6Gnfa9TAu6Jcn2D2F56IkZfour/TBshTW/xf5q1QvMnbqhP1EEb1S3XP/QCdm WLwg9/x2p63hyocFzjvKewHFv4DwBO5hJlrhmv6RvUuRCfcv2gRzPR8TrJ0M= X-Sasl-enc: nsWtmQvHnB0SIUIarBS+7nRtPb+ANTHGklLeQ2vz1awD 1427740652 Received: from [21.151.212.93] (unknown [66.87.152.93]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A530C00023; Mon, 30 Mar 2015 14:37:32 -0400 (EDT) References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> <5516C71F.3020606@network-heretics.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-E28701C9-5158-47E6-9F83-F5A26914DF6D Message-Id: X-Mailer: iPhone Mail (12D508) From: Keith Moore Date: Mon, 30 Mar 2015 14:37:28 -0400 To: James Woodyatt Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient 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, 30 Mar 2015 18:37:36 -0000 --Apple-Mail-E28701C9-5158-47E6-9F83-F5A26914DF6D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Of course, AppleTalk name/service discovery didn't have to work at Internet s= cale. But maybe I should try to write an informational RFC on the myriad wa= ys that DNS fails to be an adequate and reliable name lookup service. Sent from my iPhone > On Mar 30, 2015, at 2:20 PM, James Woodyatt wrote: >=20 > Keith=E2=80=94=E2=80=8B >=20 > I would have drawn that comparison to Appletalk not BITNET, except strange= ly enough=E2=80=94 maybe not so strangely=E2=80=94 I don't remember seeing a= lot of Appletalk literal addresses littering source code the way you see IP= v4 literals still so widely used today. Hmm, I wonder what lessons might be d= rawn from such a comparison. --Apple-Mail-E28701C9-5158-47E6-9F83-F5A26914DF6D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Of course, AppleTalk name/service disc= overy didn't have to work at Internet scale.  But maybe I should try to= write an informational RFC on the myriad ways that DNS fails to be an adequ= ate and reliable name lookup service.

Sent from my iPhone
<= br>On Mar 30, 2015, at 2:20 PM, James Woodyatt <jhw@nestlabs.com> wrote:

Keith=E2=80=94=E2=80=8B<= div>
I would have drawn that comparison to Appletalk not BITNE= T, except strangely enough=E2=80=94 maybe not so strangely=E2=80=94 I don't r= emember seeing a lot of Appletalk literal addresses littering source code th= e way you see IPv4 literals still so widely used today. Hmm, I wonder what l= essons might be drawn from such a comparison.
= --Apple-Mail-E28701C9-5158-47E6-9F83-F5A26914DF6D-- From nobody Mon Mar 30 12:54:31 2015 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 E54D11A86FD; Mon, 30 Mar 2015 12:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.612 X-Spam-Level: X-Spam-Status: No, score=-112.612 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Ch-3xM2PlS11; Mon, 30 Mar 2015 12:54:26 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD371A1BCB; Mon, 30 Mar 2015 12:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1710; q=dns/txt; s=iport; t=1427745265; x=1428954865; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1jm2BvX4d0eY2LYL2841Np+19uuE0kAoa4Hy+7ZdZF8=; b=EVOaZbS+DQZjMEcCmKRiPTkdmYKp9yPYPqhFT0XP49G1goL3ofugyURU XFiqnRmQtqiqhybGExSXvDDQ+fchdjmwWPAY2uJUZI6GsYY4mj6WSagQv o6Y9bHugM8CK7P3zqG7O7inLh6AR5jvxU1w1nzabqmMEJXdXPCXf/D97X k=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtBQB4qRlV/5ldJa1cgwZSYIMPwi+FcQKBOkwBAQEBAQF9hBUBAQMBI1sLAgEIQgICMiUCBAEgiBkIDbJumQIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsphH+CaC+BFgWQXIFrgTJUhgOUNSKDboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,496,1422921600"; d="asc'?scan'208";a="136736739" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 30 Mar 2015 19:54:17 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2UJsHVh009122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Mar 2015 19:54:17 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.131]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 30 Mar 2015 14:54:17 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG , "sunset4@ietf.org" Thread-Topic: [v6ops] Discussion: IPv4 as a Service Thread-Index: AQHQayNOg4kWwf156ESqrMiINuhM1g== Date: Mon, 30 Mar 2015 19:54:16 +0000 Message-ID: <95C21895-305F-46BD-A571-925FBD838EEA@cisco.com> References: <8EF27210-0C56-4F6D-81FD-B27EE34ED444@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_81BE3B01-FFB9-451F-A0E9-7AA9AD1F702A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Discussion: IPv4 as a Service 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, 30 Mar 2015 19:54:28 -0000 --Apple-Mail=_81BE3B01-FFB9-451F-A0E9-7AA9AD1F702A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Over the weekend, we crowd-sourced a number of pretty good questions. I = took the liberty, this morning, of reorganizing the text a bit. The = "list of technologies" and "list of questions" remain, but I have added = "possible (classes of) documents to be developed" and a first cut at a = proposed outline, with the questions from above pulled in to make it = clear what I might hope the section might comment on. Collecting comments and thoughts. I guarantee there is something we = haven=E2=80=99t thought of (as I was reorganizing, several points popped = out, and I=E2=80=99m sure I=E2=80=99m not that smart). > = https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwoUWdz6psyEb4= 56c3A/edit?usp=3Dsharing --Apple-Mail=_81BE3B01-FFB9-451F-A0E9-7AA9AD1F702A 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 iQEVAwUBVRmpFp9ieig10VPpAQLmPwgAgDB7y6doWpo5MosbOORV1E1duIvlN8tM EJ94K4NCNCFxKQDUELMFQ56BDXfqoWFOgxj0g3J0GDx8qPBTDWRlzhmLu9kic6Og GqK/5sYggcWrDAXlf+ceZ6feLgY4C+m/LThY0pVdo5oXmYb4lbkYi6Zz0gHdFK2u 92NB+NqKUPAqY1g1HZK+GanLaGgj2/95h3W9On7+c8Npnyu9+3Q9DpI79exyIoZK pWn8iU4YEWGEW7yKz4XECqkYLK1dsOaiSqruTk/c+/6Bb3CEdQTU0cXZZ7IB+rGf GMWZKrLPltxRpU/H9hdapMbS0p1qxeCpd2R2UjxJyx81wmAPdmDrLA== =oKgf -----END PGP SIGNATURE----- --Apple-Mail=_81BE3B01-FFB9-451F-A0E9-7AA9AD1F702A-- From nobody Mon Mar 30 14:43:43 2015 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 C613E1A033A; Mon, 30 Mar 2015 14:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.138 X-Spam-Level: * X-Spam-Status: No, score=1.138 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 V8yVFjC2sjxg; Mon, 30 Mar 2015 14:43:41 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02411A00F3; Mon, 30 Mar 2015 14:43:40 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id t2ULhPGR059279; Mon, 30 Mar 2015 23:43:25 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201503302143.t2ULhPGR059279@givry.fdupont.fr> From: Francis Dupont To: ipv6@ietf.org, v6ops@ietf.org Date: Mon, 30 Mar 2015 23:43:25 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: Subject: [v6ops] IPv6 is 20 year old! 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, 30 Mar 2015 21:43:41 -0000 Exactly 20 years ago the first interconnection between two independent IPv6 implementations succeeded between sipper.pa-x.dec.com and ottawa.inria.fr. Regards Francis.Dupont@fdupont.fr PS: IPv4-compatible IPv6 addresses were used (I thought this defunct type of addresses was only used for this kind of early tests), the first "native" IPv6 (and Neighbor Discovery) was during the 33th IETF at Stockholm in July 1995. PPS: I can give or put somewhere details, including the typescript of the second connection I kept for this kind of occasions, just ask. From nobody Mon Mar 30 22:35:54 2015 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 2A7411B2AA4 for ; Mon, 30 Mar 2015 22:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.612 X-Spam-Level: X-Spam-Status: No, score=-112.612 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 CCiwmcJgB_Vf for ; Mon, 30 Mar 2015 22:35:50 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499D31B2AA0 for ; Mon, 30 Mar 2015 22:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4881; q=dns/txt; s=iport; t=1427780150; x=1428989750; h=from:to:subject:date:message-id:mime-version; bh=WwzxKTja01S+mqWVPJrENDqQXbypP/Tp7/k6oUQY+pk=; b=HGODvLxk/hVoUTPfSsjldR0OEB2HHELoUKoU0oF1NMytUFr25DRkdh5b yP4JprNQEBLglR5dNCd9R6HYBh7wBG/Bb9bMUUZR7kaN3jKOtY4ef7Zx4 h7ySEcPeBELFPCjvkromFoKrvyz8Cvs6xY3C/1ZU6ul9opVJjjtKX0a2p A=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DmBADdMBpV/5pdJa1cgwaBMIMMwHuJAzgUAQEBAQEBAXyEFgQBI0QXDQFKAjQnBCGIGQijV49MmiIBAQEBAQUBAQEBAQEBG5MFL4EWBZBPgWmBMYZTgRuGCYk+g0cig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,498,1422921600"; d="asc'?scan'208";a="136762066" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 31 Mar 2015 05:35:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2V5Znd7002767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 31 Mar 2015 05:35:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.131]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 00:35:49 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: IPv4 trajectory Thread-Index: AQHQa3SKOP355mCtYUCyFmxhLNVm0A== Date: Tue, 31 Mar 2015 05:35:48 +0000 Message-ID: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_C8C8D8F0-9DFF-47A6-B66E-DE2E260DEA82"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] IPv4 trajectory 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, 31 Mar 2015 05:35:52 -0000 --Apple-Mail=_C8C8D8F0-9DFF-47A6-B66E-DE2E260DEA82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the course of the Google Doc =E2=80=9Ctowards IPv4 as a service=E2=80=9D= discussion, Brian Carpenter wrote > Scope question: do we need to distinguish edge networks from Tier 3 = provider networks? Are we making the assumption that transit and core = carriers remain dual-stack? Listing LISP suggests that we might not be = making that assumption exactly. Let me give you my thought process. Happy to be told I am wrong. As I read RFC 4213, the transition process was envisioned as taking = three steps: 1) IPv4-only 2) IPv4+IPv6 Dual Stack 3) IPv6-only Had the transition started five or ten years ago, that might have been = reasonable. Where things stand, though, I don=E2=80=99t think it is. = =46rom my perspective, the process over some amount of time into the = future (amount of time is anybody=E2=80=99s guess) will take six steps: 1) IPv4-only network 2) IPv4 with bits of IPv6 here and there, in some combination of overlay = and native 3) IPv4+IPv6 (native) dual stack network 4) IPv6+IPv4 non-native, translated or overlay (e.g., as a service) 5) IPv6 with little bits of IPv4 here and there; your printer might be = an example 6) IPv6-only In steps 1 and 2, it is an IPv4 network, possibly with some toys in it = playing IPv6. We might have toys playing AppleTalk and DECNet too. IPv4 = is the workhorse, and toys is toys. In step 3, every host in the network has an IPv4 address and an IPv6 = address, or constructively could have if it wants one, and every router = is carrying IPv4 routing as well as IPv6 routing. It=E2=80=99s likely = multiplexing IPv4 addresses, and IPv4 is increasingly broken. But the = big question is what applications and providers support IPv6; as long as = a big one (Skype?) is not making the transition, people have a business = reason to keep IPv4 going. As applications become dual stack, traffic = levels approach a 50/50 distribution, barring some specific reason they = would be forced to IPv4 or IPv6. Right now, most networks are still in step 1, and those that have a clue = are somewhere between step 2 and step 3. But some are moving, or at = least experimenting, with step 4. steps 4-6 are fundamentally about an IPv6 network. In step 4, the network is optimizing configurations and costs by making = IPv4 a translation or an overlay, but IPv4 remains an important aspect = of the network. Obvious examples include anything listed. IPv4 might = reach the host one way or another, or be translated some distance away, = but a client using IPv4 can reach an IPv4-only server, and it can reply, = and part of the path in between is IPv6-only. In step 5, IPv4 has taken a place comparable to AppleTalk; yes, = there=E2=80=99s some there, but where, precisely? And in step 6, we have = finally turned IPv4 off entirely, and with it probably Bisync and X.25. Now, what assumptions am I making? I believe that an IPv4 packet can = make it end to end until step 5; it might spend part of that as a = translated IPv6 packet or in a tunnel of some kind, but it can get = there. As of step 5, that is no longer the case. Exactly how that = happens is Not My Department. Note that many core networks don=E2=80=99t = describe themselves as IPv4, IPv6, or dual stack networks; they describe = themselves as MPLS networks that carry IP as a payload. Listing LISP... to me, LISP is yet another encapsulation, a tunnel = broker, and one that is particularly complex. It can carry IPv6 across = an IPv4 network or IPv4 over an IPv6 network. Someone suggested it = should be on the list, and it=E2=80=99s on the list. One thing I = actually expect is that the list of technologies we might invite = deployment reports regarding is longer than the list of technologies = people actually use. We might learn something from that. Is anyone=E2=80=99s head exploding yet? --Apple-Mail=_C8C8D8F0-9DFF-47A6-B66E-DE2E260DEA82 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 iQEVAwUBVRotT59ieig10VPpAQL7uwf/ahXbqKh+0fWhFRh0jnRNlaryhCDfphDC dJ4cQoBXTlDqO5YDjAGzOsFqVMxKGfMCgqaxFwRVGZPhwEwUYDaDbtibcm2SJAsU +0zS3jeBZRiCHegdc03dHZcy3nQTJIvJHpPlCuhSvKjyffWwOuRexSdVv/NwJZko pDej/mgytT7c1D0/BLlEVSgaj6tplWbcir4xVgGkW26ykT1y0PC4h8pJyuvUJKJ8 E9F1aeS+LN3FWvwgkayYEF3uawF6xatR07iyqgDR26CytMMb1WvEIXxnbsafKoJC XlCD0KTB4n0palYMte2yGDr9HHEVF7feoHalGHNNoHoD30IqtOhjtw== =i5Ud -----END PGP SIGNATURE----- --Apple-Mail=_C8C8D8F0-9DFF-47A6-B66E-DE2E260DEA82-- From nobody Tue Mar 31 04:37:50 2015 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 B102F1A9008 for ; Tue, 31 Mar 2015 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 uZDECrkftzzM for ; Tue, 31 Mar 2015 04:37:47 -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 886581A901E for ; Tue, 31 Mar 2015 04:37:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2VBbi4i026360 for ; Tue, 31 Mar 2015 13:37:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8CAE9203F1D for ; Tue, 31 Mar 2015 13:38:36 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7B362203E76 for ; Tue, 31 Mar 2015 13:38:36 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2VBbgSu025708 for ; Tue, 31 Mar 2015 13:37:44 +0200 Message-ID: <551A8706.4070409@gmail.com> Date: Tue, 31 Mar 2015 13:37:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201503302143.t2ULhPGR059279@givry.fdupont.fr> In-Reply-To: <201503302143.t2ULhPGR059279@givry.fdupont.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 is 20 year old! 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, 31 Mar 2015 11:37:48 -0000 Le 30/03/2015 23:43, Francis Dupont a écrit : > Exactly 20 years ago the first interconnection between two independent > IPv6 implementations succeeded between sipper.pa-x.dec.com and > ottawa.inria.fr. > > Regards > > Francis.Dupont@fdupont.fr > > PS: IPv4-compatible IPv6 addresses were used (I thought this defunct > type of addresses was only used for this kind of early tests), the > first "native" IPv6 (and Neighbor Discovery) was during the 33th IETF > at Stockholm in July 1995. > PPS: I can give or put somewhere details, including the typescript > of the second connection I kept for this kind of occasions, just ask. I ask. Among the places where this can be put (if you dont already have one) one can think of isoc's deploy360 or simply github. Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Mar 31 04:45:22 2015 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 B4EB41A9075 for ; Tue, 31 Mar 2015 04:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.764 X-Spam-Level: X-Spam-Status: No, score=-93.764 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_ALMOST_IP=1.889, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, 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 rob2LsSXyPbA for ; Tue, 31 Mar 2015 04:45:19 -0700 (PDT) Received: from mail.consulintel.com (154.Red-80-32-113.staticIP.rima-tde.net [80.32.113.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F3B1A900B for ; Tue, 31 Mar 2015 04:45:18 -0700 (PDT) Received: from [10.10.10.100] by mail.consulintel.com (MDaemon PRO v11.0.3) with ESMTP id md50000248331.msg for ; Tue, 31 Mar 2015 13:45:14 +0200 X-Spam-Processed: mail.consulintel.com, Tue, 31 Mar 2015 13:45:14 +0200 (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=1532132a30=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 31 Mar 2015 13:45:00 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] IPv6 is 20 year old! References: <201503302143.t2ULhPGR059279@givry.fdupont.fr> <551A8706.4070409@gmail.com> In-Reply-To: <551A8706.4070409@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6 is 20 year old! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 31 Mar 2015 11:45:21 -0000 A few years ago, Bob Hinden, Tony Hain, Brian Haberman, myself and a few others from my team, started the site: http://www.ipv6-to-standard.org In order to =B3compile=B2 products using IPv6 related RFCs (1981, 2460, 2461, 2462, 4291, 4443) to probe that can be updated to STD status. I guess this may be still useful, at least as a starting point. Regards, Jordi -----Mensaje original----- De: Alexandru Petrescu Responder a: Fecha: martes, 31 de marzo de 2015, 12:37 Para: Asunto: Re: [v6ops] IPv6 is 20 year old! >Le 30/03/2015 23:43, Francis Dupont a =E9crit : >> Exactly 20 years ago the first interconnection between two independent >> IPv6 implementations succeeded between sipper.pa-x.dec.com and >> ottawa.inria.fr. >> >> Regards >> >> Francis.Dupont@fdupont.fr >> >> PS: IPv4-compatible IPv6 addresses were used (I thought this defunct >> type of addresses was only used for this kind of early tests), the >> first "native" IPv6 (and Neighbor Discovery) was during the 33th IETF >> at Stockholm in July 1995. >> PPS: I can give or put somewhere details, including the typescript >> of the second connection I kept for this kind of occasions, just ask. > >I ask. > >Among the places where this can be put (if you dont already have one) >one can think of isoc's deploy360 or simply github. > >Alex > >> >> _______________________________________________ >> 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 Tue Mar 31 06:49:49 2015 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 5B5121ACD3C for ; Tue, 31 Mar 2015 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 SgTf3exld6wH for ; Tue, 31 Mar 2015 06:49:46 -0700 (PDT) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id BE0F21ACD14 for ; Tue, 31 Mar 2015 06:49:46 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t2VDnj1c002706 for ; Tue, 31 Mar 2015 09:49:45 -0400 Received: (qmail 30619 invoked by uid 0); 31 Mar 2015 13:49:45 -0000 X-TCPREMOTEIP: 204.235.115.161 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.71.36.49?) (lee@asgard.org@204.235.115.161) by 0 with ESMTPA; 31 Mar 2015 13:49:45 -0000 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 31 Mar 2015 09:49:41 -0400 From: Lee Howard To: "Fred Baker (fred)" , IPv6 Ops WG Message-ID: Thread-Topic: [v6ops] IPv4 trajectory Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv4 trajectory 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, 31 Mar 2015 13:49:48 -0000 On 3/31/15, 1:35 AM, "Fred Baker (fred)" wrote: >In the course of the Google Doc =B3towards IPv4 as a service=B2 discussion, >Brian Carpenter wrote > >> Scope question: do we need to distinguish edge networks from Tier 3 >>provider networks? Are we making the assumption that transit and core >>carriers remain dual-stack? Listing LISP suggests that we might not be >>making that assumption exactly. > >Let me give you my thought process. Happy to be told I am wrong. > >As I read RFC 4213, the transition process was envisioned as taking three >steps: > >1) IPv4-only >2) IPv4+IPv6 Dual Stack >3) IPv6-only > >Had the transition started five or ten years ago, that might have been >reasonable. Where things stand, though, I don=B9t think it is. From my >perspective, the process over some amount of time into the future (amount >of time is anybody=B9s guess) will take six steps: > >1) IPv4-only network >2) IPv4 with bits of IPv6 here and there, in some combination of overlay >and native >3) IPv4+IPv6 (native) dual stack network >4) IPv6+IPv4 non-native, translated or overlay (e.g., as a service) >5) IPv6 with little bits of IPv4 here and there; your printer might be an >example >6) IPv6-only Exactly. Note that networks do not move monotonically. That is, for an eyeball or mobile network, their work may be complete when only 30% of users have IPv6, and they have to wait for IPv6-incapable user equipment to age out. That could be step 2, or step 3, or even a messy combination in which: a. Some users have native IPv4-only b. Some users have native dual-stack c. Some users have native IPv6 with IPv4 and an overlay d. In cases where 6rd (mostly) was used, some users have native IPv4, with IPv6 as an overlay Those may all exist in a single network. > >In steps 1 and 2, it is an IPv4 network, possibly with some toys in it >playing IPv6. We might have toys playing AppleTalk and DECNet too. IPv4 >is the workhorse, and toys is toys. > >In step 3, every host in the network has an IPv4 address and an IPv6 >address, or constructively could have if it wants one, and every router >is carrying IPv4 routing as well as IPv6 routing. It=B9s likely >multiplexing IPv4 addresses, and IPv4 is increasingly broken. But the big >question is what applications and providers support IPv6; as long as a >big one (Skype?) is not making the transition, people have a business >reason to keep IPv4 going. As applications become dual stack, traffic >levels approach a 50/50 distribution, barring some specific reason they >would be forced to IPv4 or IPv6. Fewer and fewer networks will be doing step 3. If they aren't close to rolling out, they simply won't have the IPv4 address space to do native dual-stack. I think we will start seeing networks skipping steps. But again, these will co-exist; existing customers or installations will probably remain IPv4-only, with new devices being enabled with IPv6, with IPv4 as a service. The rest will be transition by attrition. >... > > >Listing LISP... to me, LISP is yet another encapsulation, a tunnel >broker, and one that is particularly complex. It can carry IPv6 across an >IPv4 network or IPv4 over an IPv6 network. Someone suggested it should be >on the list, and it=B9s on the list. One thing I actually expect is that >the list of technologies we might invite deployment reports regarding is >longer than the list of technologies people actually use. We might learn >something from that. We would also learn something if we get no deployment reports for certain technologies. > >Is anyone=B9s head exploding yet? I was wondering what that sound was. Lee From nobody Tue Mar 31 07:02:08 2015 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 2A1281ACD63 for ; Tue, 31 Mar 2015 07:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 D5TMz48hY7Kp for ; Tue, 31 Mar 2015 07:02:03 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 D5AFE1ACD58 for ; Tue, 31 Mar 2015 07:02:02 -0700 (PDT) Received: by igcau2 with SMTP id au2so18963331igc.0 for ; Tue, 31 Mar 2015 07:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bXX44i7OVz8yZhBiuBErOCg60fUlcgDCmeVD9UQhUbw=; b=yJYNwHMPqJmYCPcuGAK/UcU/L1DP88/xTQuRNirhoFYFT6A64CciznSoNC4PYcBHit YvqpM/0Ct+6LVM0SwWLW0kUCq/sURlFrzGmlSnVxdclXb2MzMgjoG1cuTYRo3BvKP85h 5g3tKHKIGxnCt2Hxe3OLb17NtgQShiCI+tcWvqHBnliKIDcrGaHyWRTX97UhFoGtUM14 rEb2DjyQFXoCG0YYzM0j+r61oAUVgJ70yCxd9gUt+L7V3ZG634ir083sfhahvSCajm+N 7MZzXfL0nmzZ46ueKBMwgG8yhwaO+s9WXWzjzz9mZeh8XnG7vavE3bpvcxOWYP6I9jiC R6Tw== MIME-Version: 1.0 X-Received: by 10.60.134.199 with SMTP id pm7mr22987137oeb.36.1427810522334; Tue, 31 Mar 2015 07:02:02 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.202.176.130 with HTTP; Tue, 31 Mar 2015 07:02:02 -0700 (PDT) In-Reply-To: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> Date: Tue, 31 Mar 2015 10:02:02 -0400 X-Google-Sender-Auth: U5AAEZacX8vSYWjjp2c75EGdA_U Message-ID: From: Erik Nygren To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7b41cd34fd8d2f0512960abb Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 31 Mar 2015 14:02:06 -0000 --047d7b41cd34fd8d2f0512960abb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 31, 2015 at 1:35 AM, Fred Baker (fred) wrote: > Let me give you my thought process. Happy to be told I am wrong. Thank you for writing this up! It makes total sense to me. I wonder if it would be useful to turn an expanded version of this into a draft, especially as this story is one that will be helpful to explain more broadly? > Now, what assumptions am I making? I believe that an IPv4 packet can make it end to end until step 5 The primary exception to this is NAT44 environments where the only IPv4 exists in (overlapping) private address space bubbles. This has been the norm rather than the exception for a long time now in many enterprise networks, and with an acceleration of step 4 it may become even more common. Perhaps the revised version would be "IPv4 packet can make it end to end to globally routable services until step 5, but many hosts require the assistance of services such as STUN to reach each other directly." Erik As I read RFC 4213, the transition process was envisioned as taking three > steps: > > 1) IPv4-only > 2) IPv4+IPv6 Dual Stack > 3) IPv6-only > > Had the transition started five or ten years ago, that might have been > reasonable. Where things stand, though, I don=E2=80=99t think it is. From= my > perspective, the process over some amount of time into the future (amount > of time is anybody=E2=80=99s guess) will take six steps: > > 1) IPv4-only network > 2) IPv4 with bits of IPv6 here and there, in some combination of overlay > and native > 3) IPv4+IPv6 (native) dual stack network > 4) IPv6+IPv4 non-native, translated or overlay (e.g., as a service) > 5) IPv6 with little bits of IPv4 here and there; your printer might be an > example > 6) IPv6-only > > In steps 1 and 2, it is an IPv4 network, possibly with some toys in it > playing IPv6. We might have toys playing AppleTalk and DECNet too. IPv4 i= s > the workhorse, and toys is toys. > > In step 3, every host in the network has an IPv4 address and an IPv6 > address, or constructively could have if it wants one, and every router i= s > carrying IPv4 routing as well as IPv6 routing. It=E2=80=99s likely multip= lexing > IPv4 addresses, and IPv4 is increasingly broken. But the big question is > what applications and providers support IPv6; as long as a big one (Skype= ?) > is not making the transition, people have a business reason to keep IPv4 > going. As applications become dual stack, traffic levels approach a 50/50 > distribution, barring some specific reason they would be forced to IPv4 o= r > IPv6. > > Right now, most networks are still in step 1, and those that have a clue > are somewhere between step 2 and step 3. But some are moving, or at least > experimenting, with step 4. > > steps 4-6 are fundamentally about an IPv6 network. > > In step 4, the network is optimizing configurations and costs by making > IPv4 a translation or an overlay, but IPv4 remains an important aspect of > the network. Obvious examples include anything listed. IPv4 might reach t= he > host one way or another, or be translated some distance away, but a clien= t > using IPv4 can reach an IPv4-only server, and it can reply, and part of t= he > path in between is IPv6-only. > > In step 5, IPv4 has taken a place comparable to AppleTalk; yes, there=E2= =80=99s > some there, but where, precisely? And in step 6, we have finally turned > IPv4 off entirely, and with it probably Bisync and X.25. > > > Now, what assumptions am I making? I believe that an IPv4 packet can make > it end to end until step 5; it might spend part of that as a translated > IPv6 packet or in a tunnel of some kind, but it can get there. As of step > 5, that is no longer the case. Exactly how that happens is Not My > Department. Note that many core networks don=E2=80=99t describe themselve= s as IPv4, > IPv6, or dual stack networks; they describe themselves as MPLS networks > that carry IP as a payload. > > > Listing LISP... to me, LISP is yet another encapsulation, a tunnel broker= , > and one that is particularly complex. It can carry IPv6 across an IPv4 > network or IPv4 over an IPv6 network. Someone suggested it should be on t= he > list, and it=E2=80=99s on the list. One thing I actually expect is that t= he list of > technologies we might invite deployment reports regarding is longer than > the list of technologies people actually use. We might learn something fr= om > that. > > > Is anyone=E2=80=99s head exploding yet? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b41cd34fd8d2f0512960abb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 31, 2015 at 1:35 AM, Fred Baker= (fred) <fred@cisco.com> wrote:
> Let me give you my thought process. Happy to be told I am wrong.

Thank you for writing this up!=C2=A0 It makes total sense to me.=C2=A0 = I wonder if it would be useful to turn an expanded version of this into a d= raft, especially as this story is one that will be helpful to explain more = broadly?

> Now, what assumptions am I making? I believe that an I= Pv4 packet can make it end to end until step 5

The primary exc= eption to this is NAT44 environments where the only IPv4 exists in (overlap= ping) private address space bubbles.
This has been the norm rather= than the exception for a long time now in many enterprise networks, and wi= th an acceleration of step 4 it may become even more common.=C2=A0 Perhaps = the revised version would be "IPv4 packet can make it end to end to gl= obally routable services until step 5, but many hosts require the assistanc= e of services such as STUN to reach each other directly."

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik



As I read RFC 4213, the transition process was envisioned as taking three s= teps:

1) IPv4-only
2) IPv4+IPv6 Dual Stack
3) IPv6-only

Had the transition started five or ten years ago, that might have been reas= onable. Where things stand, though, I don=E2=80=99t think it is. From my pe= rspective, the process over some amount of time into the future (amount of = time is anybody=E2=80=99s guess) will take six steps:

1) IPv4-only network
2) IPv4 with bits of IPv6 here and there, in some combination of overlay an= d native
3) IPv4+IPv6 (native) dual stack network
4) IPv6+IPv4 non-native, translated or overlay (e.g., as a service)
5) IPv6 with little bits of IPv4 here and there; your printer might be an e= xample
6) IPv6-only

In steps 1 and 2, it is an IPv4 network, possibly with some toys in it play= ing IPv6. We might have toys playing AppleTalk and DECNet too. IPv4 is the = workhorse, and toys is toys.

In step 3, every host in the network has an IPv4 address and an IPv6 addres= s, or constructively could have if it wants one, and every router is carryi= ng IPv4 routing as well as IPv6 routing. It=E2=80=99s likely multiplexing I= Pv4 addresses, and IPv4 is increasingly broken. But the big question is wha= t applications and providers support IPv6; as long as a big one (Skype?) is= not making the transition, people have a business reason to keep IPv4 goin= g. As applications become dual stack, traffic levels approach a 50/50 distr= ibution, barring some specific reason they would be forced to IPv4 or IPv6.=

Right now, most networks are still in step 1, and those that have a clue ar= e somewhere between step 2 and step 3. But some are moving, or at least exp= erimenting, with step 4.

steps 4-6 are fundamentally about an IPv6 network.

In step 4, the network is optimizing configurations and costs by making IPv= 4 a translation or an overlay, but IPv4 remains an important aspect of the = network. Obvious examples include anything listed. IPv4 might reach the hos= t one way or another, or be translated some distance away, but a client usi= ng IPv4 can reach an IPv4-only server, and it can reply, and part of the pa= th in between is IPv6-only.

In step 5, IPv4 has taken a place comparable to AppleTalk; yes, there=E2=80= =99s some there, but where, precisely? And in step 6, we have finally turne= d IPv4 off entirely, and with it probably Bisync and X.25.


Now, what assumptions am I making? I believe that an IPv4 packet can make i= t end to end until step 5; it might spend part of that as a translated IPv6= packet or in a tunnel of some kind, but it can get there. As of step 5, th= at is no longer the case. Exactly how that happens is Not My Department. No= te that many core networks don=E2=80=99t describe themselves as IPv4, IPv6,= or dual stack networks; they describe themselves as MPLS networks that car= ry IP as a payload.


Listing LISP... to me, LISP is yet another encapsulation, a tunnel broker, = and one that is particularly complex. It can carry IPv6 across an IPv4 netw= ork or IPv4 over an IPv6 network. Someone suggested it should be on the lis= t, and it=E2=80=99s on the list. One thing I actually expect is that the li= st of technologies we might invite deployment reports regarding is longer t= han the list of technologies people actually use. We might learn something = from that.


Is anyone=E2=80=99s head exploding yet?

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


--047d7b41cd34fd8d2f0512960abb-- From nobody Tue Mar 31 08:08:47 2015 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 6F3B01ACDCE for ; Tue, 31 Mar 2015 08:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] 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 hTEEej7wCvHN for ; Tue, 31 Mar 2015 08:08:44 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 4772B1ACDCA for ; Tue, 31 Mar 2015 08:08:43 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id CA478102CA4 for ; Tue, 31 Mar 2015 10:08:42 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 4D080132CFD; Tue, 31 Mar 2015 10:08:42 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 787A74FE138; Tue, 31 Mar 2015 11:05:11 -0400 (EDT) Received: from pwn401ea105.ent.corp.bcbsm.com (unknown [10.64.102.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva1.bcbsm.com (Postfix) with ESMTP id 5B3F34FF1E9; Tue, 31 Mar 2015 11:05:11 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Tue, 31 Mar 2015 11:08:41 -0400 From: "Ackermann, Michael" To: "Fred Baker (fred)" , IPv6 Ops WG Thread-Topic: IPv4 trajectory Thread-Index: AQHQa3SKOP355mCtYUCyFmxhLNVm0J02rPyQ Date: Tue, 31 Mar 2015 15:08:40 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CD95876@PWN401EA160.ent.corp.bcbsm.com> References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> In-Reply-To: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] x-tm-as-product-ver: SMEX-10.2.0.3262-7.500.1018-21438.000 x-tm-as-result: No--42.958900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 477713d4-2e56-44c7-9233-e24da3eb6c86 X-VPM-MSG-ID: 59999b42-911d-46bb-976a-cbcc739e95ff X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [v6ops] IPv4 trajectory 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, 31 Mar 2015 15:08:46 -0000 RnJlZA0KDQpUaGFua3Mgc28gbXVjaCBmb3IgdGhpcyB1cGRhdGUgdG8gdGhlIHRyYW5zaXRp b24gc3RlcHMsIGFzIGl0IG1vcmUgYWNjdXJhdGVseSBkZXBpY3RzIHdoYXQgSSBzZWUgaW4g Q29ycG9yYXRlL0VudGVycHJpc2UgbmV0d29ya3MgdG9kYXkuICAod2hpY2ggaXMgZnJlcXVl bnRseSAgZGlmZmVyZW50IHRoYW4gSSBoZWFyIHdoZW4gYXQgSUVURikuICAgDQoNCkkgaGF2 ZSAzIHJlbGF0ZWQgY29tbWVudHM6IA0KDQoqICBJIHdvdWxkIHNlcGFyYXRlIHN0ZXAgMiBp bnRvIDJhIGFuZCAyYiwgIHdoZXJlIDJhIGlzICBJUHY2IGV4aXN0aW5nICBpbiBhIGxhYiBv ciBpc29sYXRlZCBuZXR3b3JrIG9ubHkuICAgMmIgcmVtYWlucyBhcyB5b3UgZGVzY3JpYmVk IDIuICAgICAgICAgIE1hbnkgSSBrbm93IGFyZSBjdXJyZW50bHkgY2F1Z2h0IGJldHdlZW4g MmEgYW5kIDJiLiAgIA0KKiAgQ29ycG9yYXRlL0VudGVycHJpc2UgbmV0d29ya3MgIGRvIGEg bG90IG9mIFByaXZhdGUgKGludGVybmFsKSB0byBQdWJsaWMgKGV4dGVybmFsKSBJUHY0IE5B VHMuICAgVW5mb3J0dW5hdGVseSBJIHNlZSB0aGlzIGNvbnRpbnVpbmcgZm9yIGEgbG9uZyB0 aW1lIHRvIGNvbWUsIGFzIGl0IGludm9sdmVzIGlzc3VlcyBmcmVxdWVudGx5IGJleW9uZCB0 aGUgY29udHJvbCBvZiBvbmUgZW50ZXJwcmlzZS4gICAgIFRodXMgNSBtYXkgYmUgbG9uZ2Vy IGFuZCBsYXJnZXIgIkxpdHRsZSBCaXRzIiAgdGhhbiBtb3N0IG9mIHVzIHdvdWxkIGxpa2Uu ICAgICBQZXJoYXBzIHdlIGNhbiB0aGluayBvZiBmYWNpbGl0YXRpbmcgdHJhbnNpdGlvbiBy YXRpb25hbGUgJiAgdG9vbHMgdG8gYWRkcmVzcyB0aGlzPyAgICANCiogIFRvIGdldCBmcm9t IHN0ZXAgNSB0byA2LCB0aGVyZSB3aWxsIGJlIGEgbG90IG9mIGludGVybmFsIElQdjQgYWRk cmVzc2VzIHRoYXQgc2VlbWluZ2x5IGhhdmUgTk8gUkVBU09OIFRPIENPTlZFUlQgdG8gSVB2 Ni4gICAgSSB3b3VsZCBsaWtlIHRvIHJldmVyc2UgdGhpcyB0aGlua2luZyBpbiAgdGhlIG1h bmlmb2xkIGNvcnBvcmF0ZSBuZXR3b3JrcyBJIGhlYXIgaXQgZnJvbSwgIGJ1dCBoYXZlIG5v dCBjb21lIHVwIHdpdGggYW55dGhpbmcgdmVyeSBjb252aW5jaW5nICAgeWV0LiAgDQoNCiAg SSBoYXZlIG5vdCBydW4gaW50byBMSVNQIHlldCwgc28gY2Fubm90IGNvbW1lbnQgb24gcmVs YXRlZCBpc3N1ZXMuIA0KDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhpcyByZW5kaXRpb24hDQoN Ck1pa2UNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmVkIEJha2Vy IChmcmVkKQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMzEsIDIwMTUgMTozNiBBTQ0KVG86IElQ djYgT3BzIFdHDQpTdWJqZWN0OiBbdjZvcHNdIElQdjQgdHJhamVjdG9yeQ0KDQpJbiB0aGUg Y291cnNlIG9mIHRoZSBHb29nbGUgRG9jIOKAnHRvd2FyZHMgSVB2NCBhcyBhIHNlcnZpY2Xi gJ0gZGlzY3Vzc2lvbiwgQnJpYW4gQ2FycGVudGVyIHdyb3RlDQoNCj4gU2NvcGUgcXVlc3Rp b246IGRvIHdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggZWRnZSBuZXR3b3JrcyBmcm9tIFRpZXIg MyBwcm92aWRlciBuZXR3b3Jrcz8gQXJlIHdlIG1ha2luZyB0aGUgYXNzdW1wdGlvbiB0aGF0 IHRyYW5zaXQgYW5kIGNvcmUgY2FycmllcnMgcmVtYWluIGR1YWwtc3RhY2s/IExpc3Rpbmcg TElTUCBzdWdnZXN0cyB0aGF0IHdlIG1pZ2h0IG5vdCBiZSBtYWtpbmcgdGhhdCBhc3N1bXB0 aW9uIGV4YWN0bHkuDQoNCkxldCBtZSBnaXZlIHlvdSBteSB0aG91Z2h0IHByb2Nlc3MuIEhh cHB5IHRvIGJlIHRvbGQgSSBhbSB3cm9uZy4NCg0KQXMgSSByZWFkIFJGQyA0MjEzLCB0aGUg dHJhbnNpdGlvbiBwcm9jZXNzIHdhcyBlbnZpc2lvbmVkIGFzIHRha2luZyB0aHJlZSBzdGVw czoNCg0KMSkgSVB2NC1vbmx5DQoyKSBJUHY0K0lQdjYgRHVhbCBTdGFjaw0KMykgSVB2Ni1v bmx5DQoNCkhhZCB0aGUgdHJhbnNpdGlvbiBzdGFydGVkIGZpdmUgb3IgdGVuIHllYXJzIGFn bywgdGhhdCBtaWdodCBoYXZlIGJlZW4gcmVhc29uYWJsZS4gV2hlcmUgdGhpbmdzIHN0YW5k LCB0aG91Z2gsIEkgZG9u4oCZdCB0aGluayBpdCBpcy4gRnJvbSBteSBwZXJzcGVjdGl2ZSwg dGhlIHByb2Nlc3Mgb3ZlciBzb21lIGFtb3VudCBvZiB0aW1lIGludG8gdGhlIGZ1dHVyZSAo YW1vdW50IG9mIHRpbWUgaXMgYW55Ym9keeKAmXMgZ3Vlc3MpIHdpbGwgdGFrZSBzaXggc3Rl cHM6DQoNCjEpIElQdjQtb25seSBuZXR3b3JrDQoyKSBJUHY0IHdpdGggYml0cyBvZiBJUHY2 IGhlcmUgYW5kIHRoZXJlLCBpbiBzb21lIGNvbWJpbmF0aW9uIG9mIG92ZXJsYXkgYW5kIG5h dGl2ZQ0KMykgSVB2NCtJUHY2IChuYXRpdmUpIGR1YWwgc3RhY2sgbmV0d29yaw0KNCkgSVB2 NitJUHY0IG5vbi1uYXRpdmUsIHRyYW5zbGF0ZWQgb3Igb3ZlcmxheSAoZS5nLiwgYXMgYSBz ZXJ2aWNlKQ0KNSkgSVB2NiB3aXRoIGxpdHRsZSBiaXRzIG9mIElQdjQgaGVyZSBhbmQgdGhl cmU7IHlvdXIgcHJpbnRlciBtaWdodCBiZSBhbiBleGFtcGxlDQo2KSBJUHY2LW9ubHkNCg0K SW4gc3RlcHMgMSBhbmQgMiwgaXQgaXMgYW4gSVB2NCBuZXR3b3JrLCBwb3NzaWJseSB3aXRo IHNvbWUgdG95cyBpbiBpdCBwbGF5aW5nIElQdjYuIFdlIG1pZ2h0IGhhdmUgdG95cyBwbGF5 aW5nIEFwcGxlVGFsayBhbmQgREVDTmV0IHRvby4gSVB2NCBpcyB0aGUgd29ya2hvcnNlLCBh bmQgdG95cyBpcyB0b3lzLg0KDQpJbiBzdGVwIDMsIGV2ZXJ5IGhvc3QgaW4gdGhlIG5ldHdv cmsgaGFzIGFuIElQdjQgYWRkcmVzcyBhbmQgYW4gSVB2NiBhZGRyZXNzLCBvciBjb25zdHJ1 Y3RpdmVseSBjb3VsZCBoYXZlIGlmIGl0IHdhbnRzIG9uZSwgYW5kIGV2ZXJ5IHJvdXRlciBp cyBjYXJyeWluZyBJUHY0IHJvdXRpbmcgYXMgd2VsbCBhcyBJUHY2IHJvdXRpbmcuIEl04oCZ cyBsaWtlbHkgbXVsdGlwbGV4aW5nIElQdjQgYWRkcmVzc2VzLCBhbmQgSVB2NCBpcyBpbmNy ZWFzaW5nbHkgYnJva2VuLiBCdXQgdGhlIGJpZyBxdWVzdGlvbiBpcyB3aGF0IGFwcGxpY2F0 aW9ucyBhbmQgcHJvdmlkZXJzIHN1cHBvcnQgSVB2NjsgYXMgbG9uZyBhcyBhIGJpZyBvbmUg KFNreXBlPykgaXMgbm90IG1ha2luZyB0aGUgdHJhbnNpdGlvbiwgcGVvcGxlIGhhdmUgYSBi dXNpbmVzcyByZWFzb24gdG8ga2VlcCBJUHY0IGdvaW5nLiBBcyBhcHBsaWNhdGlvbnMgYmVj b21lIGR1YWwgc3RhY2ssIHRyYWZmaWMgbGV2ZWxzIGFwcHJvYWNoIGEgNTAvNTAgZGlzdHJp YnV0aW9uLCBiYXJyaW5nIHNvbWUgc3BlY2lmaWMgcmVhc29uIHRoZXkgd291bGQgYmUgZm9y Y2VkIHRvIElQdjQgb3IgSVB2Ni4NCg0KUmlnaHQgbm93LCBtb3N0IG5ldHdvcmtzIGFyZSBz dGlsbCBpbiBzdGVwIDEsIGFuZCB0aG9zZSB0aGF0IGhhdmUgYSBjbHVlIGFyZSBzb21ld2hl cmUgYmV0d2VlbiBzdGVwIDIgYW5kIHN0ZXAgMy4gQnV0IHNvbWUgYXJlIG1vdmluZywgb3Ig YXQgbGVhc3QgZXhwZXJpbWVudGluZywgd2l0aCBzdGVwIDQuDQoNCnN0ZXBzIDQtNiBhcmUg ZnVuZGFtZW50YWxseSBhYm91dCBhbiBJUHY2IG5ldHdvcmsuDQoNCkluIHN0ZXAgNCwgdGhl IG5ldHdvcmsgaXMgb3B0aW1pemluZyBjb25maWd1cmF0aW9ucyBhbmQgY29zdHMgYnkgbWFr aW5nIElQdjQgYSB0cmFuc2xhdGlvbiBvciBhbiBvdmVybGF5LCBidXQgSVB2NCByZW1haW5z IGFuIGltcG9ydGFudCBhc3BlY3Qgb2YgdGhlIG5ldHdvcmsuIE9idmlvdXMgZXhhbXBsZXMg aW5jbHVkZSBhbnl0aGluZyBsaXN0ZWQuIElQdjQgbWlnaHQgcmVhY2ggdGhlIGhvc3Qgb25l IHdheSBvciBhbm90aGVyLCBvciBiZSB0cmFuc2xhdGVkIHNvbWUgZGlzdGFuY2UgYXdheSwg YnV0IGEgY2xpZW50IHVzaW5nIElQdjQgY2FuIHJlYWNoIGFuIElQdjQtb25seSBzZXJ2ZXIs IGFuZCBpdCBjYW4gcmVwbHksIGFuZCBwYXJ0IG9mIHRoZSBwYXRoIGluIGJldHdlZW4gaXMg SVB2Ni1vbmx5Lg0KDQpJbiBzdGVwIDUsIElQdjQgaGFzIHRha2VuIGEgcGxhY2UgY29tcGFy YWJsZSB0byBBcHBsZVRhbGs7IHllcywgdGhlcmXigJlzIHNvbWUgdGhlcmUsIGJ1dCB3aGVy ZSwgcHJlY2lzZWx5PyBBbmQgaW4gc3RlcCA2LCB3ZSBoYXZlIGZpbmFsbHkgdHVybmVkIElQ djQgb2ZmIGVudGlyZWx5LCBhbmQgd2l0aCBpdCBwcm9iYWJseSBCaXN5bmMgYW5kIFguMjUu DQoNCg0KTm93LCB3aGF0IGFzc3VtcHRpb25zIGFtIEkgbWFraW5nPyBJIGJlbGlldmUgdGhh dCBhbiBJUHY0IHBhY2tldCBjYW4gbWFrZSBpdCBlbmQgdG8gZW5kIHVudGlsIHN0ZXAgNTsg aXQgbWlnaHQgc3BlbmQgcGFydCBvZiB0aGF0IGFzIGEgdHJhbnNsYXRlZCBJUHY2IHBhY2tl dCBvciBpbiBhIHR1bm5lbCBvZiBzb21lIGtpbmQsIGJ1dCBpdCBjYW4gZ2V0IHRoZXJlLiBB cyBvZiBzdGVwIDUsIHRoYXQgaXMgbm8gbG9uZ2VyIHRoZSBjYXNlLiBFeGFjdGx5IGhvdyB0 aGF0IGhhcHBlbnMgaXMgTm90IE15IERlcGFydG1lbnQuIE5vdGUgdGhhdCBtYW55IGNvcmUg bmV0d29ya3MgZG9u4oCZdCBkZXNjcmliZSB0aGVtc2VsdmVzIGFzIElQdjQsIElQdjYsIG9y IGR1YWwgc3RhY2sgbmV0d29ya3M7IHRoZXkgZGVzY3JpYmUgdGhlbXNlbHZlcyBhcyBNUExT IG5ldHdvcmtzIHRoYXQgY2FycnkgSVAgYXMgYSBwYXlsb2FkLg0KDQoNCkxpc3RpbmcgTElT UC4uLiB0byBtZSwgTElTUCBpcyB5ZXQgYW5vdGhlciBlbmNhcHN1bGF0aW9uLCBhIHR1bm5l bCBicm9rZXIsIGFuZCBvbmUgdGhhdCBpcyBwYXJ0aWN1bGFybHkgY29tcGxleC4gSXQgY2Fu IGNhcnJ5IElQdjYgYWNyb3NzIGFuIElQdjQgbmV0d29yayBvciBJUHY0IG92ZXIgYW4gSVB2 NiBuZXR3b3JrLiBTb21lb25lIHN1Z2dlc3RlZCBpdCBzaG91bGQgYmUgb24gdGhlIGxpc3Qs IGFuZCBpdOKAmXMgb24gdGhlIGxpc3QuIE9uZSB0aGluZyBJIGFjdHVhbGx5IGV4cGVjdCBp cyB0aGF0IHRoZSBsaXN0IG9mIHRlY2hub2xvZ2llcyB3ZSBtaWdodCBpbnZpdGUgZGVwbG95 bWVudCByZXBvcnRzIHJlZ2FyZGluZyBpcyBsb25nZXIgdGhhbiB0aGUgbGlzdCBvZiB0ZWNo bm9sb2dpZXMgcGVvcGxlIGFjdHVhbGx5IHVzZS4gV2UgbWlnaHQgbGVhcm4gc29tZXRoaW5n IGZyb20gdGhhdC4NCg0KDQpJcyBhbnlvbmXigJlzIGhlYWQgZXhwbG9kaW5nIHlldD8NCgoK VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaGln aGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGRpcmVj dGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhl cmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9y IGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVwaG9uZSwg b2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNz YWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGll bGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBu b25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhl IEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo= From nobody Tue Mar 31 09:15:31 2015 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 C80161A0039 for ; Tue, 31 Mar 2015 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fgB8i4Z3BkhI for ; Tue, 31 Mar 2015 09:15:27 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B9E1A0027 for ; Tue, 31 Mar 2015 09:15:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2VGFQ55015833; Tue, 31 Mar 2015 11:15:26 -0500 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2VGFIpl015758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 31 Mar 2015 11:15:18 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.251]) with mapi id 14.03.0210.002; Tue, 31 Mar 2015 09:15:17 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" , IPv6 Ops WG Thread-Topic: IPv4 trajectory Thread-Index: AQHQa3SKOP355mCtYUCyFmxhLNVm0J02w4XQ Date: Tue, 31 Mar 2015 16:15:17 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E2E853@XCH-BLV-504.nw.nos.boeing.com> References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> In-Reply-To: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] IPv4 trajectory 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, 31 Mar 2015 16:15:29 -0000 SGkgRnJlZCwNCg0KPiBMaXN0aW5nIExJU1AuLi4gdG8gbWUsIExJU1AgaXMgeWV0IGFub3RoZXIg ZW5jYXBzdWxhdGlvbiwgYSB0dW5uZWwgYnJva2VyLCBhbmQgb25lIHRoYXQgaXMgcGFydGljdWxh cmx5IGNvbXBsZXguIEl0IGNhbiBjYXJyeSBJUHY2IGFjcm9zcyBhbg0KPiBJUHY0IG5ldHdvcmsg b3IgSVB2NCBvdmVyIGFuIElQdjYgbmV0d29yay4gU29tZW9uZSBzdWdnZXN0ZWQgaXQgc2hvdWxk IGJlIG9uIHRoZSBsaXN0LCBhbmQgaXTigJlzIG9uIHRoZSBsaXN0LiBPbmUgdGhpbmcgSSBhY3R1 YWxseSBleHBlY3QNCj4gaXMgdGhhdCB0aGUgbGlzdCBvZiB0ZWNobm9sb2dpZXMgd2UgbWlnaHQg aW52aXRlIGRlcGxveW1lbnQgcmVwb3J0cyByZWdhcmRpbmcgaXMgbG9uZ2VyIHRoYW4gdGhlIGxp c3Qgb2YgdGVjaG5vbG9naWVzIHBlb3BsZSBhY3R1YWxseSB1c2UuDQo+IFdlIG1pZ2h0IGxlYXJu IHNvbWV0aGluZyBmcm9tIHRoYXQuDQoNClBsZWFzZSBhbHNvIGxpc3QgQUVSTy4gSXQgc3VwcG9y dHMgSVB2eC1pbi1JUHZ5IHR1bm5lbGluZyB3aXRoIG1vYmlsaXR5IG1hbmFnZW1lbnQsDQphbmQg aXMgdmVyeSBzaW1wbGU6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXRlbXBsaW4tYWVyb2xpbmsvDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWlu Zy5jb20NCg== From nobody Tue Mar 31 11:12:14 2015 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 098AB1A885D for ; Tue, 31 Mar 2015 11:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 In4QrEijTy28 for ; Tue, 31 Mar 2015 11:12:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C96C1A6EDE for ; Tue, 31 Mar 2015 11:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2699; q=dns/txt; s=iport; t=1427825530; x=1429035130; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HcARF/e1V4g6Qi3njHSeHLCOJGR7uVtLRdBbD45deF4=; b=QRrVQzSr5EOxO3KkAdteRfzv3vf5LCmIOCPCMDnIZoxpUwuyFKHZCDbT L03/tlm1lYUqcSY9c4x7gjGW1L5OAdU4qDoZH5AmO01Stqm6i/6OmVXmM aIBvE3GhiSBizQv/EE/WFwSBP1BMX9mqJbbemKEIHUyMBIc3BwNuaLlaZ U=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BkBQAf4hpV/5JdJa1cgwaBLgWDD8hfAoFETAEBAQEBAX2EFAEBAQMBI1YFCwIBCBgqAgIyJQIEDgUOEIgJCLUCmREBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiymEeAeCaC+BFgWQYoFsgTKEV4IAgS6TDSKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,502,1422921600"; d="asc'?scan'208";a="137007164" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 31 Mar 2015 18:12:09 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2VIC9pt026534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 18:12:09 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.67]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 13:12:09 -0500 From: "Fred Baker (fred)" To: "Ackermann, Michael" Thread-Topic: IPv4 trajectory Thread-Index: AQHQa94zOP355mCtYUCyFmxhLNVm0A== Date: Tue, 31 Mar 2015 18:12:08 +0000 Message-ID: <4B46B05C-FDC6-48BE-9965-84A4F4E49805@cisco.com> References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <4FC37E442D05A748896589E468752CAA0CD95876@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CD95876@PWN401EA160.ent.corp.bcbsm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_FA444A16-81EC-4FD5-BDE7-FA532C84F482"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 31 Mar 2015 18:12:12 -0000 --Apple-Mail=_FA444A16-81EC-4FD5-BDE7-FA532C84F482 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 31, 2015, at 8:08 AM, Ackermann, Michael = wrote: >=20 > * To get from step 5 to 6, there will be a lot of internal IPv4 = addresses that seemingly have NO REASON TO CONVERT to IPv6. I would = like to reverse this thinking in the manifold corporate networks I hear = it from, but have not come up with anything very convincing yet. To be perfectly honest, I don=E2=80=99t expect those to ever convert. = Sooner or later, their equipment will be replaced, and when it is, the = person installing it will be faced with the question of what = communication technology to use. I expect those choices to be what makes = the step. The comment about =E2=80=9Cand along with it, biSync and X.25=E2=80=9D = was not an idle one. We=E2=80=99re still waiting for the last bisync = terminal to die, and X.25 has a constituency in the telephone world. The other thing I notice, though, is that we don=E2=80=99t have people = jumping through hoops to keep those things going. As long as they cause = less trouble than they contribute value, value wins. The day the value = gasps for breath, so will they. I=E2=80=99m not even especially concerned about getting from step 4 to = step 5. I suspect that economics will get applications to the native = network; the only question is =E2=80=9Cwhen=E2=80=9D. If A works better = than B and is less cost to maintain, A will eventually win out. My only real concern is getting from some variant of step 2b or 3 to 4. = At least in part, my reason for describing =E2=80=9Cstep 4=E2=80=9D = experiences is to point out that there are those who are going there, = and to provide =E2=80=9Cno BS=E2=80=9D analyses of that. --Apple-Mail=_FA444A16-81EC-4FD5-BDE7-FA532C84F482 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 iQEVAwUBVRrXU59ieig10VPpAQLCaAf/Wm+Pk+YKz1hqZk/ixG3Tm6urOeiE6SoZ SuRePiNB+xOLZ6B+++2+0TDSA45T+TvtcS7VrvR3BXmpIFW1D6sY8A3x4XX+iaFs +9YPy4yKJ3080NxK5FNOKCYgSo9lEWngdR60GmVqD24g4/enSaoNCkmoh8zmMogf uYjMyYE4Bbi+7T7LNoR7fsMwlAA2VBaktzmTNBDms48DHaS+Km16I0mSdLM42e8t SSTY2SGQGnw5lg1mwIpk62HSO4FhSWPmtOLzqHXZ7qkoNBlz6HNeABGB0A1yFuZR igPAAD/33FBcFbb7vNIGrfZhRPhIFaCdbN49K6zcx6tcpMPdxbohog== =lHnH -----END PGP SIGNATURE----- --Apple-Mail=_FA444A16-81EC-4FD5-BDE7-FA532C84F482-- From nobody Tue Mar 31 12:10:49 2015 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 8B3A11A92BB for ; Tue, 31 Mar 2015 12:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 hC-tPdDcipXJ for ; Tue, 31 Mar 2015 12:10:46 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::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 0ED5B1A92B8 for ; Tue, 31 Mar 2015 12:10:46 -0700 (PDT) Received: by pdrw1 with SMTP id w1so21444995pdr.0 for ; Tue, 31 Mar 2015 12:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dCU4p8zJ/LShlJxQZA+1Qkl1fAtacdWmGh/QJKmJjbc=; b=DO6+sCptFrqW5lujJiXR/E6Nw64KsKCXPiId2azfsB9GjqOAsLdy6TqLJ5dD9CLsOI q20qmxdFvMofqbvpgYhMIqnfs4ZzdPBDdCPAhTFrV6ffvECWSi3JRyxFFgJVNv5ifsQs l6444IlSm6o55fzZdC3IOLpSfVV3ilyTqHLe4TT/ekCZogWbSbua33MMis/OE1N8Csh5 1rd9ARr8rS/FVW3Ug3udvsodynAC3s5Kf3r/+5OPnWNkkH6Pj3FkDFRbT3LVMzja5LkZ wATIogfTc/mVUEYlSDUD3SVMN0XnS+4z90PCkmayjHH8fpY+Df53NpMcI+cDbAxzaFMu vnjQ== X-Received: by 10.66.221.34 with SMTP id qb2mr70889438pac.42.1427829045748; Tue, 31 Mar 2015 12:10:45 -0700 (PDT) Received: from ?IPv6:2406:e007:6307:1:28cc:dc4c:9703:6781? ([2406:e007:6307:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id yt8sm14096146pab.22.2015.03.31.12.10.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 12:10:44 -0700 (PDT) Message-ID: <551AF135.3060602@gmail.com> Date: Wed, 01 Apr 2015 08:10:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Lee Howard , "Fred Baker (fred)" , IPv6 Ops WG References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv4 trajectory 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, 31 Mar 2015 19:10:47 -0000 On 01/04/2015 02:49, Lee Howard wrote: > > > On 3/31/15, 1:35 AM, "Fred Baker (fred)" wrote: ... >> 3) IPv4+IPv6 (native) dual stack network ... > Fewer and fewer networks will be doing step 3. If they aren't close to > rolling out, they simply won't have the IPv4 address space to do native > dual-stack. Clearly this is true. The original dual-stack model assumed that everybody would be able to deploy IPng before IPv4 exhaustion. However, I also wonder whether the transit and core operators, who carry globally-addressed IPv4 traffic around for other networks, will eventually move away from pure ships-in-the-night dual stack operation. For example, will they eventually find it inconvenient to use IPv4 for "control plane" purposes, and so use IPv6 for all network management? In that case they will also be operating IPv4 only as a service. Brian From nobody Tue Mar 31 16:48:35 2015 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 338AE1B2B74 for ; Tue, 31 Mar 2015 16:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MMgx5nmV1m26 for ; Tue, 31 Mar 2015 16:48:33 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6A01B2B7E for ; Tue, 31 Mar 2015 16:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2219; q=dns/txt; s=iport; t=1427845565; x=1429055165; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HohcIAW5PKOyCW2HuKYb9H5LEWtZqeaHwDyN6z8uVa8=; b=R87sNl2C069+AxfdV75dvQP6SlDSG1baAIwnikI1fzPtGBUeYZqp1WHI V6Kj3vrsbB2c0/xFQx7/ihdqgghe/TSsWgqZNSmdlLkdLLnktDF0EXad4 0dcPj/pBx3w3QvwzG4W6n2rXXpXlNl85q48JBMrBqgHlIP5BFtpcXcJUb Y=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBQDYMBtV/51dJa1cgwaBLgWDD8hlAoE4TAEBAQEBAX2EFAEBAQMBI0QSBQsCAQgYKgICIRElAgQOBQ6IDQMJCLRvk0gNhVABAQEBAQEBAQEBAQEBAQEBAQEBAQEXiymCR4IxB4JoL4EWBZBigWyBMoUKgU2BHYxzgmODSCKDbm8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="asc'?scan'208";a="137153802" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 31 Mar 2015 23:46:04 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2VNk3hR031102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 23:46:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.67]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 18:46:03 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] IPv4 trajectory Thread-Index: AQHQbAzYG5JVINnTs0uV0Ah8LpbStw== Date: Tue, 31 Mar 2015 23:46:02 +0000 Message-ID: References: <551AF135.3060602@gmail.com> In-Reply-To: <551AF135.3060602@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_866AEE8A-F6E6-491A-8281-CEE25D3EA513"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 31 Mar 2015 23:48:34 -0000 --Apple-Mail=_866AEE8A-F6E6-491A-8281-CEE25D3EA513 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 31, 2015, at 12:10 PM, Brian E Carpenter = wrote: >=20 > However, I also wonder whether the transit and core operators, who = carry > globally-addressed IPv4 traffic around for other networks, will = eventually > move away from pure ships-in-the-night dual stack operation. For = example, > will they eventually find it inconvenient to use IPv4 for "control = plane" > purposes, and so use IPv6 for all network management? In that case = they > will also be operating IPv4 only as a service. That=E2=80=99s a question you would have to ask them. I don=E2=80=99t = know. But I=E2=80=99m not sure you=E2=80=99re using the same definition I am = for IPv4 as a service. If I understand your penultimate sentences, in a = network that carries multiple data types (I don=E2=80=99t know, Netware, = CLNS, IPv4, IPv6, whatever) and uses exactly one of them to manage the = network, the one is fundamental and the others are =E2=80=9Ca = service=E2=80=9D. The definition I=E2=80=99m using is in the data plane. Does the network = carry IPv4 as IPv4, or IPv4 as some variation on IPv6? If it carries = IPv4 translated to or encapsulated in IPv6, IPv4 is (according to me) a = service. --Apple-Mail=_866AEE8A-F6E6-491A-8281-CEE25D3EA513 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 iQEVAwUBVRss0Z9ieig10VPpAQKj8QgAmC4y5ofKuV0xVwdmi1PlA1PJJFEzje+Z RMsNwde8Pr1SAbf1yTj5mVzWJ6IuFu1JdCxTm5d2srQAdugKwYt2GchJi5qSQ0CF /A9sQumeBl0tb+TMNVHzzfypkOTTnEQ7QkQx3s/xtG82zCGH+77ipEzSfQidCIFK NA4OQW41UICPQ+cW7iaJQBtt/94IRd1vi6Rp+MVLF/nJcBp3CPeF+k1u+y+Xj8Uz RefErFQLebGshLzlYSYCDlxuZ52mkHIg4z/pfIw4VKwMbg5a1Dz20In/P7kV48OW vqoFy/oJVg5mLjdSdwH0r5zU9x7Nlj1Y9Br8HHVfNcGUdoVT7bOWGA== =SU3V -----END PGP SIGNATURE----- --Apple-Mail=_866AEE8A-F6E6-491A-8281-CEE25D3EA513-- From nobody Tue Mar 31 16:48:52 2015 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 6376B1B2B7D for ; Tue, 31 Mar 2015 16:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 N0ECOnQv29_h for ; Tue, 31 Mar 2015 16:48:50 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E25B1B2B88 for ; Tue, 31 Mar 2015 16:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1352; q=dns/txt; s=iport; t=1427845606; x=1429055206; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=79P8L9wILOUwMTmZ31hEb2LhyASoOap1GWaLMFPnx+k=; b=QpjNLlhJBtszTIu+L9uEmwHZ/f8tpXJyMLOCraVUjkaXayJuxdHF24WT lh47Mbj0uRl1MBimjF2Q5N6SI+56yjFbCP5QzT+QRljF/qm36cPUoJIQj 06L5Mv3uQipdCx5bQw+C7E4bYETMKbhKXXePqgm2yyIf0N1SseCfrLRDk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CCBADBMBtV/4wNJK1cgwaBLgWDD8EcBodDAhyBHDgUAQEBAQEBAXyEFAEBAQMBIxEzEgULAgEIGAICJgICAh8RFRACBA4FiBsDCQi0bpNIDYVQAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhigiCR4F+MweCaC+BFgEEkGKIKIFNgR2Mc4Jjg0gig25vAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="137052086" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 31 Mar 2015 23:46:45 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2VNkjIL013405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 23:46:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.67]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 18:46:45 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] IPv4 trajectory Thread-Index: AQHQbAzxG5JVINnTs0uV0Ah8LpbStw== Date: Tue, 31 Mar 2015 23:46:44 +0000 Message-ID: References: <551AF135.3060602@gmail.com> In-Reply-To: <551AF135.3060602@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="utf-8" Content-ID: <4439D3CEF6D0514FA167A8977609F91E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 31 Mar 2015 23:48:51 -0000 DQo+IE9uIE1hciAzMSwgMjAxNSwgYXQgMTI6MTAgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSG93ZXZlciwgSSBhbHNvIHdv bmRlciB3aGV0aGVyIHRoZSB0cmFuc2l0IGFuZCBjb3JlIG9wZXJhdG9ycywgd2hvIGNhcnJ5DQo+ IGdsb2JhbGx5LWFkZHJlc3NlZCBJUHY0IHRyYWZmaWMgYXJvdW5kIGZvciBvdGhlciBuZXR3b3Jr cywgd2lsbCBldmVudHVhbGx5DQo+IG1vdmUgYXdheSBmcm9tIHB1cmUgc2hpcHMtaW4tdGhlLW5p Z2h0IGR1YWwgc3RhY2sgb3BlcmF0aW9uLiBGb3IgZXhhbXBsZSwNCj4gd2lsbCB0aGV5IGV2ZW50 dWFsbHkgZmluZCBpdCBpbmNvbnZlbmllbnQgdG8gdXNlIElQdjQgZm9yICJjb250cm9sIHBsYW5l Ig0KPiBwdXJwb3NlcywgYW5kIHNvIHVzZSBJUHY2IGZvciBhbGwgbmV0d29yayBtYW5hZ2VtZW50 PyBJbiB0aGF0IGNhc2UgdGhleQ0KPiB3aWxsIGFsc28gYmUgb3BlcmF0aW5nIElQdjQgb25seSBh cyBhIHNlcnZpY2UuDQoNClRoYXTigJlzIGEgcXVlc3Rpb24geW91IHdvdWxkIGhhdmUgdG8gYXNr IHRoZW0uIEkgZG9u4oCZdCBrbm93Lg0KDQpCdXQgSeKAmW0gbm90IHN1cmUgeW914oCZcmUgdXNp bmcgdGhlIHNhbWUgZGVmaW5pdGlvbiBJIGFtIGZvciBJUHY0IGFzIGEgc2VydmljZS4gSWYgSSB1 bmRlcnN0YW5kIHlvdXIgcGVudWx0aW1hdGUgc2VudGVuY2VzLCBpbiBhIG5ldHdvcmsgdGhhdCBj YXJyaWVzIG11bHRpcGxlIGRhdGEgdHlwZXMgKEkgZG9u4oCZdCBrbm93LCBOZXR3YXJlLCBDTE5T LCBJUHY0LCBJUHY2LCB3aGF0ZXZlcikgYW5kIHVzZXMgZXhhY3RseSBvbmUgb2YgdGhlbSB0byBt YW5hZ2UgdGhlIG5ldHdvcmssIHRoZSBvbmUgaXMgZnVuZGFtZW50YWwgYW5kIHRoZSBvdGhlcnMg YXJlIOKAnGEgc2VydmljZeKAnS4NCg0KVGhlIGRlZmluaXRpb24gSeKAmW0gdXNpbmcgaXMgaW4g dGhlIGRhdGEgcGxhbmUuIA== From nobody Tue Mar 31 17:11:51 2015 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 D66581B2B7F for ; Tue, 31 Mar 2015 17:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 1m26mWEWKgX0 for ; Tue, 31 Mar 2015 17:11:40 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::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 928C01B2B81 for ; Tue, 31 Mar 2015 17:11:38 -0700 (PDT) Received: by pdrw1 with SMTP id w1so28159729pdr.0 for ; Tue, 31 Mar 2015 17:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PyIjBHVnfxahaVn72PIaXAEC8G4AnWC32/OzAlf4GZE=; b=Cm1BMXznxBuoO3C2hYvi+YXw7OMjqhnzeCYs9CP1FtumdTFj5cMHO2nEShN8E+WMyl wrXOpbKJLxkUcWaDmG3pZmNJmkH6u0DUs/xjLveyyVRtBWeUge6mAd9XLMBCkoopA08d 8HjFrOHyi9gskieI8nseBrEu+D3sb7D5bLNk8xtiySCytOB+BpJu/yLZXzjRCfA6Qae8 aUc+iOuy1cqFV+looYsVLtbiK94h7FsRHF4FAK8QTS81RsJZ4ej9Q2yjgPdsecN9pWc7 Fzn+DudSYV2/nBUd3HoAjNY1OAE+sBTVsHb7ueyTLY7TdEezddnJQW0AsCYdbMYKdDke XjTA== X-Received: by 10.70.91.201 with SMTP id cg9mr20310487pdb.105.1427847098102; Tue, 31 Mar 2015 17:11:38 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id db10sm102204pdb.86.2015.03.31.17.11.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 17:11:36 -0700 (PDT) Message-ID: <551B37B9.4090400@gmail.com> Date: Wed, 01 Apr 2015 13:11:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <551AF135.3060602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 01 Apr 2015 00:11:46 -0000 On 01/04/2015 12:46, Fred Baker (fred) wrote: >=20 >> On Mar 31, 2015, at 12:10 PM, Brian E Carpenter wrote: >> >> However, I also wonder whether the transit and core operators, who car= ry >> globally-addressed IPv4 traffic around for other networks, will eventu= ally >> move away from pure ships-in-the-night dual stack operation. For examp= le, >> will they eventually find it inconvenient to use IPv4 for "control pla= ne" >> purposes, and so use IPv6 for all network management? In that case the= y >> will also be operating IPv4 only as a service. >=20 > That=E2=80=99s a question you would have to ask them. I don=E2=80=99t k= now. >=20 > But I=E2=80=99m not sure you=E2=80=99re using the same definition I am = for IPv4 as a service. If I understand your penultimate sentences, in a n= etwork that carries multiple data types (I don=E2=80=99t know, Netware, C= LNS, IPv4, IPv6, whatever) and uses exactly one of them to manage the net= work, the one is fundamental and the others are =E2=80=9Ca service=E2=80=9D= =2E >=20 > The definition I=E2=80=99m using is in the data plane. Does the network= carry IPv4 as IPv4, or IPv4 as some variation on IPv6? If it carries IPv= 4 translated to or encapsulated in IPv6, IPv4 is (according to me) a serv= ice. In fact, I agree. So the sequence I'm thinking of for a transit or DFZ carrier is something like this: 1. (now) Run dual stack with ships-in-the-night routing, but configuration and management is via IPv4. 2. (soon) Ditto, but some config & management moves to IPv6. 3. Ditto, but all config & management is via IPv6. 4. Observe that IPv4 has become secondary. 5. Therefore, migrate IPv4 support to run over IPv6. This is different (and simpler) than subscriber-facing carriers, because they will have to navigate all kinds of other issues like CGN and MAP on the client side. I'm not saying this is profound; just that it is a different trajectory from the ones we mainly discuss. Brian From nobody Tue Mar 31 17:33:07 2015 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 CBCEE1B2B8A for ; Tue, 31 Mar 2015 17:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 f4z2L5Cm2VP3 for ; Tue, 31 Mar 2015 17:33:04 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671291B2B86 for ; Tue, 31 Mar 2015 17:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1887; q=dns/txt; s=iport; t=1427848384; x=1429057984; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p32dymR9ydGjFg/j9cpBp5ubH3dbSnsJvNLqoDiJpRc=; b=XdD/ANFnbVzyvElkdrTeaII7LZyp+OwrcbC0TRenYKHo95KDPsv2VxxF Ww98VtqSV+qg5UbRpuELP6QkH1vs8mpzJ9u+QFhuBKP8s9QwqayZUQDIc KIFUB18oq6eTMSmIxhR0Y+Jn05jTVGZaWp9DHZKSf3V3WHuY0pEMePz3S A=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBQCAPBtV/49dJa1cgwaBLgWDD8hlAoE6TAEBAQEBAX2EFAEBAQMBI0QSBQsCAQgYKgICIRElAgQOBQ6IDQMJCLR0k0oNhVABAQEBAQEBAQEBAQEBAQEBAQEBAQEXiymCR4IxB4JoL4EWBZBigWyBMoUKgU2OEIYrIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="asc'?scan'208";a="137166464" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 01 Apr 2015 00:32:50 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t310Wo7U020853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 00:32:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.67]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 19:32:49 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] IPv4 trajectory Thread-Index: AQHQbBNhG5JVINnTs0uV0Ah8LpbStw== Date: Wed, 1 Apr 2015 00:32:48 +0000 Message-ID: References: <551AF135.3060602@gmail.com> <551B37B9.4090400@gmail.com> In-Reply-To: <551B37B9.4090400@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_30F9BD19-5BED-4D7F-8D64-452522CB3162"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 01 Apr 2015 00:33:05 -0000 --Apple-Mail=_30F9BD19-5BED-4D7F-8D64-452522CB3162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 31, 2015, at 5:11 PM, Brian E Carpenter = wrote: >=20 > 5. Therefore, migrate IPv4 support to run over IPv6. Again, if you want the carrier=E2=80=99s logic, ask the carrier. But to = me, that doesn=E2=80=99t follow. Not all core carriers, but a significant number of them, don=E2=80=99t = think of themselves as carrying IPv4 or IPv6 per se. They think of = themselves as MPLS houses, using jumboframes so that the addition of = that header to whatever their payload happens to be (aka IPv4 or IPv6) = doesn=E2=80=99t have an MTU problem. Whatever comes in, they throw it = into the right tunnel (aka LSP) to get it to the right egress, MPLS gets = it there, and it goes out the other door. You=E2=80=99re arguing about what kind of tunnel they should use. = They=E2=80=99re quite happy with the one they have, and it=E2=80=99s = neither IPv4 nor IPv6. --Apple-Mail=_30F9BD19-5BED-4D7F-8D64-452522CB3162 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 iQEVAwUBVRs8r59ieig10VPpAQJ6Igf/UONMCPUPjiAaicLGVYNtszieb8yXvLtQ b7AnY0gsPXMVdjwkQMX0kqoSP8gKZVsYG9tB+i5ed+QJnOSlTdzLVW2MmJaWrLkn HKt3TvPJzeonW2uGhKhXxJXsPWZjaRZpdLxtxGGlWwqtf5dgVLaU/BIEvnnP2t9+ neBIdB9UBbiwx2dU+9TlYkKH/qiv8Rl1B4ktRh9dYUSogrKkqdNpGL4I0veFpIV9 4C9bhVcnGcBGsVLgPUbSGkV/K8vp465j964/TIKLhM/H1Ex+YJnbFQtrtDEU7151 Ic8up3Y6bp+jn/HzBZlPrZOhC4V3AJkweE4KRdzZkDHY9D3TeLPzEA== =PjhK -----END PGP SIGNATURE----- --Apple-Mail=_30F9BD19-5BED-4D7F-8D64-452522CB3162-- From nobody Tue Mar 31 18:11:39 2015 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 8C4C51B2B8D for ; Tue, 31 Mar 2015 18:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 agz_p6HtWm-x for ; Tue, 31 Mar 2015 18:11:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF5C1B2A15 for ; Tue, 31 Mar 2015 18:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10817; q=dns/txt; s=iport; t=1427850695; x=1429060295; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ugeRvYZqvwe+Z8e2S+XFlKUsWMJ4YfTDYHY+sKvV1aI=; b=dLg79c1+PutrS07LcqEc1tW9IbCe/yANOlnVdg2IVmK702MuIQNwkEj2 5iwuaWgptLkgrPmCH7Br4sWMqwFFmgFSdZjqxXm3/ogmn8jSlO43CH9XB pYUPeOYycib+SuSqyuNVFcV6Kfvtx7FKAbjI9iqma7MJyYuCj73sxfEwU Y=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBQD7RBtV/4kNJK1cgwZSXAWDD8J3hXECgTxMAQEBAQEBfYQUAQEBAwEjVgULAgEIEgYnAwICIREUAw4CBA4FDogNAwkIDbRak00NhVABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIspgkeCLQQHgmgvgRYFkGKBbIEyVIQ2gU2OEIYrIoICHIFQb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="asc'?scan'208,217";a="408232628" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 01 Apr 2015 01:11:33 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t311BXXZ007876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 01:11:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.67]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 20:11:33 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: [v6ops] Discussion: IPv4 as a Service Thread-Index: AQHQa/EGHqmXZ5D2QE2Ivb4KAHb4sJ03crEAgAA60AA= Date: Wed, 1 Apr 2015 01:11:32 +0000 Message-ID: References: <8EF27210-0C56-4F6D-81FD-B27EE34ED444@cisco.com> <95C21895-305F-46BD-A571-925FBD838EEA@cisco.com> <940432F8-44CD-43E7-B570-D3CAA07C4710@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_AA61D9A1-C1C6-4DE9-BC94-58E955D96CFF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Discussion: IPv4 as a Service 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, 01 Apr 2015 01:11:37 -0000 --Apple-Mail=_AA61D9A1-C1C6-4DE9-BC94-58E955D96CFF Content-Type: multipart/alternative; boundary="Apple-Mail=_535E0FFA-1E90-4C9A-9467-3BB58ED08E50" --Apple-Mail=_535E0FFA-1E90-4C9A-9467-3BB58ED08E50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since they might be among the early folks I would ask to write = something, I asked Xing Li, Akira, and Suprita to comment specifically = on the outline: =E2=80=9Cif you were to write such a document, how would = this outline work for you=E2=80=9D. Suprita replied as follows. I have changed the proposed outline in a = manner similar to her suggestion. > On Mar 31, 2015, at 2:41 PM, suprita wrote: >=20 > I tried to first re-write the "Outlined hierarchy" used and then make = any modification to it, as per ease of answering them. > I did not have to do many changes to the one already used by you, with = minor adjustments in naming convention and placements.. >=20 > Experience Gathering : Heading >=20 > General/Overview > Major Motivation(s) > v4 as-a-service Requirements > Exactly which v4 Service Types > Architecture and Methodology > Major Design Considerations > Regulatory Considerations > Security Considerations > Operational Considerations > End-User Experience Considerations > Observations and Experiences > Effects on End-User > Effects on Internal Staff > Planning & Design > Implementation > Operations > Effects on Business > Summary: Post-mortem Report > Deviations from RFC's/Drafts/Standards > Worked Well > Did not work well >=20 >=20 > On Wed, Apr 1, 2015 at 1:56 AM, suprita > wrote: > Dear Fred, >=20 > I am yet to apply newly learnt skill from you of applying filters for = the directly addressed e-mails :). > I will sure go through the doc in detail and comment. >=20 > Thank you, > Suprita >=20 > On Tue, Mar 31, 2015 at 2:04 AM, Fred Baker (fred) > wrote: >=20 > > On Mar 30, 2015, at 12:50 PM, Fred Baker > wrote: > > > > Over the weekend, we crowd-sourced a number of pretty good = questions. I took the liberty, this morning, of reorganizing the text a = bit. The "list of technologies" and "list of questions" remain, but I = have added "possible (classes of) documents to be developed" and a first = cut at a proposed outline, with the questions from above pulled in to = make it clear what I might hope the section might comment on. > > > > Collecting comments and thoughts. I guarantee there is something we = haven=E2=80=99t thought of (as I was reorganizing, several points popped = out, and I=E2=80=99m sure I=E2=80=99m not that smart). > > > >> = https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwoUWdz6psyEb4= 56c3A/edit?usp=3Dsharing = >=20 > The first thing I am wondering about is whether the proposed outline = =E2=80=9Cworks=E2=80=9D. Would you be willing to spend an hour thinking = through the outline and wondering how you would respond to it for = Reliance? What questions are missing? Would another organization work = better? >=20 >=20 --Apple-Mail=_535E0FFA-1E90-4C9A-9467-3BB58ED08E50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since they might be among the early folks I would ask to = write something, I asked Xing Li, Akira, and Suprita to comment = specifically on the outline: =E2=80=9Cif you were to write such a = document, how would this outline work for you=E2=80=9D.
Suprita replied as follows. I have = changed the proposed outline in a manner similar to her = suggestion.

On Mar 31, 2015, at 2:41 PM, = suprita <suprita.nitw@gmail.com> wrote:

I tried to first re-write the = "Outlined hierarchy" used  and then make any modification to it, as = per ease of answering them. 
I did not have to do = many changes to the one already used by you, with minor adjustments in = naming convention and placements..

Experience Gathering : = Heading

General/Overview
Major Motivation(s)
v4 = as-a-service Requirements
Exactly which v4 Service = Types
Architecture and Methodology
Major = Design Considerations
Regulatory = Considerations
Security Considerations
= Operational Considerations
End-User Experience = Considerations
Observations and = Experiences
Effects on End-User
Effects = on Internal Staff
Planning & = Design
= Implementation
Operations
Effects = on Business
Summary: Post-mortem = Report
= Deviations from RFC's/Drafts/Standards
Worked Well
Did not = work well


On Wed, = Apr 1, 2015 at 1:56 AM, suprita <suprita.nitw@gmail.com> wrote:
Dear Fred,

I am yet to apply newly learnt skill from you of applying = filters for the directly addressed e-mails :).
I = will sure go through the doc in detail and comment. 

Thank you,
Suprita

On Tue, = Mar 31, 2015 at 2:04 AM, Fred Baker (fred) <fred@cisco.com> wrote:

> On Mar 30, 2015, at 12:50 PM, Fred Baker <fred@cisco.com> wrote:
>
> Over the weekend, we crowd-sourced a number of pretty good = questions. I took the liberty, this morning, of reorganizing the text a = bit. The "list of technologies" and "list of questions" remain, but I = have added "possible (classes of) documents to be developed" and a first = cut at a proposed outline, with the questions from above pulled in to = make it clear what I might hope the section might comment on.
>
> Collecting comments and thoughts. I guarantee there is something we = haven=E2=80=99t thought of (as I was reorganizing, several points popped = out, and I=E2=80=99m sure I=E2=80=99m not that smart).
>
>> https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwo= UWdz6psyEb456c3A/edit?usp=3Dsharing

The first thing I am wondering about is whether the proposed = outline =E2=80=9Cworks=E2=80=9D. Would you be willing to spend an hour = thinking through the outline and wondering how you would respond to it = for Reliance? What questions are missing? Would another organization = work better?



= --Apple-Mail=_535E0FFA-1E90-4C9A-9467-3BB58ED08E50-- --Apple-Mail=_AA61D9A1-C1C6-4DE9-BC94-58E955D96CFF 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 iQEVAwUBVRtFwp9ieig10VPpAQL8LAf/V5Bf9f2ap9B8Behi9kUOSfCSfNgprm9J gLVBYeiQHY2aboIdAsvTKtc3b/8Vm5LkGrczy2xVzcNfsSJ03qE5KZ1jGASRd/mL OvVR+gZmtWdAZdf85Ym0Ut1ZbCXZFBF20sEldEMV1e4HovPCmOieZqHvF4EZ+VSZ cQx6iok0NeRkEkU9sbxQdpcp4KKtLO+ajqQSA6zSCzWvwPXjvthNZWEV5W+gv/0c Cz2MbiCz7Tp6ZEVGPU1LWdmSBMEqz7/sn8V2Bu1FA1JcBidscjB/Qq7ouGNI+4Tl A9oIIX+qmd+I3NQ0HjFMqqCvaUmJPIqP8z7Vn66SP1a40FqtcKaxMQ== =MK+k -----END PGP SIGNATURE----- --Apple-Mail=_AA61D9A1-C1C6-4DE9-BC94-58E955D96CFF-- From nobody Tue Mar 31 18:12:56 2015 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 99FB61B2A01 for ; Tue, 31 Mar 2015 18:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 i-w8pZVUuqQp for ; Tue, 31 Mar 2015 18:12:54 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::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 987621B2BC6 for ; Tue, 31 Mar 2015 18:12:47 -0700 (PDT) Received: by pddn5 with SMTP id n5so37808646pdd.2 for ; Tue, 31 Mar 2015 18:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Waelq1v+u9bCvPuax6EytIVpH57/AxrF/f5l3Ks6b3I=; b=kUL9Df2BP4gI1fZ1jIMDKZ4w4e/2sgeQp6BAhQXgB0QPmHR+dqyWXWxTmskm8eyUwf KqKUmLo/GPDX7q00NcJPDu3R/7lMLd3tO56Hp+RE7EzxMQC0bKbO+0zg7E7TFWxPZhE9 RDVlKxsk6BKhHiqezraJtg/npu5+TWa0E+t/R0yVMWqLXDcsM9/WizzVW8bZax2fN7I9 vvp6JZbIoiNkWDp1tMp/Mxd28sd4c/FYQZBlQX2cToHeMhmTZnNmZnV3jiqATjZpQjjt dUojFoLPrn8PhyJytLDumTknaLs25X9RTpkb+uOt1v1tDe4gzBBc82ZZzb5lYOGHBqH/ KfgA== X-Received: by 10.68.200.169 with SMTP id jt9mr73431859pbc.164.1427850767326; Tue, 31 Mar 2015 18:12:47 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id zq6sm196466pac.11.2015.03.31.18.12.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 18:12:46 -0700 (PDT) Message-ID: <551B460E.7040207@gmail.com> Date: Wed, 01 Apr 2015 14:12:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <551AF135.3060602@gmail.com> <551B37B9.4090400@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 01 Apr 2015 01:12:55 -0000 On 01/04/2015 13:32, Fred Baker (fred) wrote: >=20 >> On Mar 31, 2015, at 5:11 PM, Brian E Carpenter wrote: >> >> 5. Therefore, migrate IPv4 support to run over IPv6. >=20 > Again, if you want the carrier=E2=80=99s logic, ask the carrier. But to= me, that doesn=E2=80=99t follow. >=20 > Not all core carriers, but a significant number of them, don=E2=80=99t = think of themselves as carrying IPv4 or IPv6 per se. They think of themse= lves as MPLS houses, using jumboframes so that the addition of that heade= r to whatever their payload happens to be (aka IPv4 or IPv6) doesn=E2=80=99= t have an MTU problem. Whatever comes in, they throw it into the right tu= nnel (aka LSP) to get it to the right egress, MPLS gets it there, and it = goes out the other door. >=20 > You=E2=80=99re arguing about what kind of tunnel they should use. They=E2= =80=99re quite happy with the one they have, and it=E2=80=99s neither IPv= 4 nor IPv6. Makes sense. But in that case, ships-in-the-night is the final state for such providers, as far as IPv4 goes; I have no problem with that. Brian From nobody Tue Mar 31 20:01:29 2015 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 9E3D71A1EEC for ; Tue, 31 Mar 2015 20:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 62mx6jd5y3JX for ; Tue, 31 Mar 2015 20:01:26 -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 387A91A1EEA for ; Tue, 31 Mar 2015 20:01:26 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:6086:c2de:6da8:922f]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3131IlZ004782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 03:01:19 GMT (envelope-from joelja@bogus.com) To: Brian E Carpenter , "Fred Baker (fred)" references: <551AF135.3060602@gmail.com> <551B37B9.4090400@gmail.com> <551B460E.7040207@gmail.com> From: joel jaeggli message-id: <551B5F7D.1080402@bogus.com> Date: Tue, 31 Mar 2015 20:01:17 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0 mime-version: 1.0 in-reply-to: <551B460E.7040207@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mHGDDqawsfbh8eBO0rPvWHjvdbIpmomtI" Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 01 Apr 2015 03:01:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mHGDDqawsfbh8eBO0rPvWHjvdbIpmomtI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/31/15 6:12 PM, Brian E Carpenter wrote: > On 01/04/2015 13:32, Fred Baker (fred) wrote: >> >>> On Mar 31, 2015, at 5:11 PM, Brian E Carpenter wrote: >>> >>> 5. Therefore, migrate IPv4 support to run over IPv6. >> >> Again, if you want the carrier=E2=80=99s logic, ask the carrier. But t= o me, that doesn=E2=80=99t follow. >> >> Not all core carriers, but a significant number of them, don=E2=80=99= t think of themselves as carrying IPv4 or IPv6 per se. They think of them= selves as MPLS houses, using jumboframes so that the addition of that hea= der to whatever their payload happens to be (aka IPv4 or IPv6) doesn=E2=80= =99t have an MTU problem. Whatever comes in, they throw it into the right= tunnel (aka LSP) to get it to the right egress, MPLS gets it there, and = it goes out the other door. >> >> You=E2=80=99re arguing about what kind of tunnel they should use. They= =E2=80=99re quite happy with the one they have, and it=E2=80=99s neither = IPv4 nor IPv6. >=20 > Makes sense. But in that case, ships-in-the-night is the final state > for such providers, as far as IPv4 goes; I have no problem with that. they do ships in the night for ipv4. the p-router portion of the network is protocol agnostic with repect to encapsulated data, modula practical problems like figuring out how to make it hash across trunks. > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --mHGDDqawsfbh8eBO0rPvWHjvdbIpmomtI 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUbX34ACgkQ8AA1q7Z/VrK8XwCfRooxu2tNZ16jViSjZFEyzb/r WbIAn0FLyNEPW8YbOjgJXvt/XpAVgE3K =mcxI -----END PGP SIGNATURE----- --mHGDDqawsfbh8eBO0rPvWHjvdbIpmomtI-- From nobody Tue Mar 31 20:06:12 2015 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 9B5B21A1EF9 for ; Tue, 31 Mar 2015 20:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 wzSh4Dnhy6oq for ; Tue, 31 Mar 2015 20:06:09 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450: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 1F6BB1A1EF5 for ; Tue, 31 Mar 2015 20:06:09 -0700 (PDT) Received: by wixo5 with SMTP id o5so20357339wix.1 for ; Tue, 31 Mar 2015 20:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ufZvil0IVB9XLGN7IFR4jZ7LL8XdskcWaOeVY5Uh2Mk=; b=acbAx94urN70QssyzmTvf7T0qcfbmQmIKRNGNUYefE3kZ1jSWQfjAJWId+ZcTHYcvI 2ERXhu4FYsCoNjcFybnpMvYmVyOEw73H3bC0oBHFQlMq8rORXU9xN97J1XhuL2L+aQbu BNEPirr233wyEzseiAdmcIJA+64arhNoi6vzPfQ2xiladIZQOwUS27q7gCKDp+w3RS39 bvDbZhSTRosLvKvfGn6qs9/oKVghTTkiIIckWOHmwqWHV+eeRPag/jD2VUbU8U8KRAqp Y/mBAPavQeX9/ywm5t24ijeYUPBVNz2nA9UwagfjVb9eoUzH3RxyrYkd5CQu9ACXL5t7 UDYg== MIME-Version: 1.0 X-Received: by 10.180.8.69 with SMTP id p5mr10711631wia.69.1427857567698; Tue, 31 Mar 2015 20:06:07 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Tue, 31 Mar 2015 20:06:07 -0700 (PDT) In-Reply-To: References: <551AF135.3060602@gmail.com> <551B37B9.4090400@gmail.com> Date: Tue, 31 Mar 2015 20:06:07 -0700 Message-ID: From: Ca By To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=f46d044283b61cd4d70512a0ff55 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory 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, 01 Apr 2015 03:06:10 -0000 --f46d044283b61cd4d70512a0ff55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, March 31, 2015, Fred Baker (fred) wrote: > > > On Mar 31, 2015, at 5:11 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > 5. Therefore, migrate IPv4 support to run over IPv6. > > Again, if you want the carrier=E2=80=99s logic, ask the carrier. But to m= e, that > doesn=E2=80=99t follow. > > Not all core carriers, but a significant number of them, don=E2=80=99t th= ink of > themselves as carrying IPv4 or IPv6 per se. They think of themselves as > MPLS houses, using jumboframes so that the addition of that header to > whatever their payload happens to be (aka IPv4 or IPv6) doesn=E2=80=99t h= ave an MTU > problem. Whatever comes in, they throw it into the right tunnel (aka LSP) > to get it to the right egress, MPLS gets it there, and it goes out the > other door. > > You=E2=80=99re arguing about what kind of tunnel they should use. They=E2= =80=99re quite > happy with the one they have, and it=E2=80=99s neither IPv4 nor IPv6. > I am not a dfz network operator, but my network has an ipv4 control plane that is rfc 1918 and only visible to the control plane, for the most part. My guess is that most dfz providers are not properly dual-stack, they are using 6pe or 6vpe. The forwaring plane is mpls. Full stop. There is no pressure to ever change the composition of the backbone since the backbone itself is not scaling quickly in terms of ip address usage. It is only the edges that scale and sees address pressure: eyeballs, sensor / things , cdn, compute .... So there is no forcing function turning ipv4 off... Except percentage of 'high value' ipv4 traffic will go down, but dfz routes will go up. So, this will create an interesting conflict as dfz ipv4 routes go up, costs go up to support + 1m routes, ddos junk traffic goes up ...ultimately in 5 years the ipv4 dfz will be mostly ddos related udp with 1m+ routes while the ipv6 dfz relatively well aggregated and ddos free (no win xp, no super legacy cpe, ...) Knocking on wood the ipv6 stays as clean as it is today. But, the rate of decay of 'high value' ipv4 traffic is extreme. Watch this space. IPv4 is becoming worse than the back row on $airline CB --f46d044283b61cd4d70512a0ff55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, March 31, 2015, Fred Baker (fred) <fred@cisco.com> wrote:

> On Mar 31, 2015, at 5:11 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> 5. Therefore, migrate IPv4 support to run over IPv6.

Again, if you want the carrier=E2=80=99s logic, ask the carrier. But to me,= that doesn=E2=80=99t follow.

Not all core carriers, but a significant number of them, don=E2=80=99t thin= k of themselves as carrying IPv4 or IPv6 per se. They think of themselves a= s MPLS houses, using jumboframes so that the addition of that header to wha= tever their payload happens to be (aka IPv4 or IPv6) doesn=E2=80=99t have a= n MTU problem. Whatever comes in, they throw it into the right tunnel (aka = LSP) to get it to the right egress, MPLS gets it there, and it goes out the= other door.

You=E2=80=99re arguing about what kind of tunnel they should use. They=E2= =80=99re quite happy with the one they have, and it=E2=80=99s neither IPv4 = nor IPv6.

I am not a dfz network operator, but my ne= twork has an ipv4 control plane that is rfc 1918 and only visible to the co= ntrol plane, for the most part.=C2=A0=C2=A0My guess is that most dfz provid= ers are not properly dual-stack, they are using 6pe or 6vpe. =C2=A0

The forwaring plane is mpls. Full stop.=C2=A0
<= br>
There is no pressure to ever change the composition of the ba= ckbone since the backbone itself is not scaling quickly in terms of ip addr= ess usage. =C2=A0

It is only the edges that scale = and sees=C2=A0address pressure: eyeballs, sensor / things , cdn, compute ..= ..

So there is no forcing function turning ipv4 off...= =C2=A0

Except percentage of 'high value'=C2=A0ip= v4 traffic=C2=A0will go down, but dfz routes will go up. So, this will crea= te an interesting conflict as dfz ipv4 routes go up, costs go up to support= + 1m=C2=A0routes,=C2=A0ddos junk traffic goes up ...ultimately in 5 years = the ipv4 dfz will be mostly ddos related udp with 1m+ routes while the ipv6= dfz relatively well aggregated and ddos free (no win xp, no super legacy c= pe, ...)

Knocking on wood the ipv6 stays as clean = as it is today.=C2=A0 But, the rate of decay of 'high value' ipv4 t= raffic is extreme. Watch this space.=C2=A0 IPv4 is becoming worse than the = back row on $airline

CB



--f46d044283b61cd4d70512a0ff55--